Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Задание 1 часть_В1-В34.docx
Скачиваний:
1
Добавлен:
19.09.2019
Размер:
3.05 Mб
Скачать
  1. Отформатировать текст по стп мгупи. Оформить рисунки и программный кода

Глава 7. Искусство расположения

Как вы уже могли убедиться из предыдущих примеров, добавление компонентов на форму в Java происходит достаточно необычно. Мы использовали метод add(), и, как по волшебству, на форме появлялись наши компоненты — кнопки, надписи, текстовые поля. Это может показаться странным, потому что для создания интерфейса необходимо точно указывать размер компонента и его расположение на экране — причем часто для этого ис­пользуются так называемые «абсолютные» координаты, полностью зависящие от разре­шающей способности экрана и его размеров. Чтобы облегчить работу с такими интерфей­сами, для их создания в подавляющем большинстве сред разработки используются визу­альные средства, «строители GUI». Процесс происходит следующим образом. Вы создаете новую главную форму — обычно окно с рамкой или диалоговое окно — и располагаете на ней необходимые вам компоненты, задавая для них подходящие размеры и позиции. После этого ваша форма запоминается в файлах ресурсов, которые при компиляции программы присоединяются к программе и загружаются при ее запуске. Все очень быстро и удобно.

Однако оказывается, что использование такой же схемы в Java является не лучшей идеей. Ведь здесь дела обстоят несколько иначе — не стоит забывать, что программа на Java «пишется один раз, а выполняется везде». Если уж мы собираемся писать коммерче­ское приложение, опирающееся на все возможности и всю мощь этого языка и его би­блиотек, то, конечно, мы не упустим шанса написать программу, поддерживающую все широко распространенные операционные системы, при этом абсолютно ее не изменяя. Преимущества Java перед другими языками, средами и подходами здесь неоспоримы. Но в таком случае придется как-то учесть все различия между этими операционными системами и используемыми в них виртуальными машинами Java — представьте себе, чторазрешение экрана в одной системе превосходит разрешение других систем в не­сколько раз, а значит, меняются размеры всех объектов, выводимых на экран. Практи­чески во всех операционных системах компоненты имеют свои особенности, и кнопка, прекрасно подходящая по размерам для Windows, в другой операционной системе мо­жет оказаться слишком большой или слишком маленькой. Или, например, у некоторого пользователя со слабым зрением все шрифты специально увеличены в два раза — в про­грамме, использующей абсолютные размеры и написанной для другой системы, он во­обще ничего не увидит. Поэтому обычные подходы (явное указание координат компо­нента и его размеров) в Java не оправданы.

Язык Java недаром носит титул переносимого между платформами — со всеми раз­личиями операционных систем прекрасно справится виртуальная машина Java. Однако остается вопрос правильного расположения компонентов на форме — здесь необходима гибкость и независимость от конкретных размеров. Все это обеспечивает менеджер рас- яоложения (layoutmanager), который играет очень важную роль в разработке пользова­тельского интерфейса. Менеджер расположения — это некая программная служба1, ас­социированная с формой (в Java обычно говорят с контейнером) и определяющая, каким образом на ней будут располагаться компоненты. Независимо от платформы, виртуаль­ной машины, разрешения и размеров экрана менеджер расположения гарантирует, что

' На языке шаблонов проектирования менеджер расположения можно описать как стратегию— алгоритм расположения компонентов, реализованный во внешнем классе, этот алгоритм можно легко и быстро подключить и при необходимости сменить.

компоненты будут иметь предпочтительный или близкий к нему размер и располагаться в том порядке, который был указан программистом присоздании программы.

Надо сказать, что в Swing менеджер расположения играет еще большую роль, чем обычно. Он позволяет не только сгладить различия между операционными система­ми, но и дает возможность менять с легкостью внешний вид приложения, не заботясь

о том, как при этом изменяются размеры и расположение компонентов. На самом деле, различные внешние виды приложений придают компонентам различные размеры, и ес­ли вы не будете использовать менеджер расположения для вашего интерфейса, переход от одного внешнего вида к другому может стать непосильной задачей.

В этой главе мы узнаем, как функционируют менеджеры расположения и что являет­ся самым важным при работе с ними. После этого мы познакомимся со стандартными менеджерами расположения, которые в большинстве своем очень просты. Иногда это­го достаточно, но, как правило, сложные интерфейсы требуют применения универсаль­ных менеджеров, и больше всего внимания мы уделим расположению BoxLayout, кото­рое, хотя и является относительно простым, остается прекрасным «оружием» создате­ля пользовательского интерфейса, и гибкому табличному расположению GridBagLayout, а также его конкурентам.

В примере создаются две панели с вертикальным и горизонтальным блочным рас­положением. Для этого используется класс BoxLayoutUtils, описанный в предыдущем раз­деле. Между компонентами помещены распорки различных размеров, созданные клас­сом Box— для создания вертикальных распорок предназначен метод createVerticalStrut(int), в качестве параметра которого указывается размер распорки в пикселах. Аналогично работает метод createHorizontalStrut(int), создающий горизонтальную распорку. Также ни­кто не запрещает использовать распорки перед всей группой компонентов или после нее, чтобы отодвинуть их от границ окна.

Кстати, если перед вызовом метода setVisible() вы вызовете метод раск(), придающий окну и всем содержащимся в нем компонентам оптимальный размер (оптимальный раз­мер компонентов, как вы помните, возвращает метод getPreferredSize()), то увидите, что заполнителей будто и след простыл. Так оно и должно быть — когда места в контейнере хватает ровным счетом для того, что разместить все видимые компоненты и распорки, то заполнитель ведет себя очень скромно — его минимальный и предпочтительный раз­меры становятся нулевыми.

ВНИМАНИЕ

Заполнители блочного расположения работают, потому что имеют неограни­ченный максимальный размер. Когда в контейнере с блочным расположением имеется избыточное пространство, оно делится поровну между компонента­ми, которые еще могут «расти», то есть не достигли максимального размера. Некоторые компоненты, например панели прокрутки с таблицами, также мо­гут расти, и надо учитывать, что свободное пространство поделится поровну между ними и «заполнителями». Когда в контейнере не остается компонен­тов, способных расти, все оставшееся пространство размещается после ком­понентов, снизу или справа, в зависимости от выбранной оси BoxLayout.

После запуска программы с примером у вас, возможно, возник еще один вопрос. По­чему панели располагаются так необычно относительно друг друга? Вертикальный ряд кнопок находится не у левой границы окна, как в предыдущих примерах, а как-то не очень понятно, ближе к его середине. Дело в том, что для полного контроля за действия­ми менеджера расположения в классе Componentпредусмотрено еще два параметра, за­дающие выравнивание по осям X и Y, и менеджер BoxLayoutих активно использует. Как направить эти параметры себе на пользу, мы узнаем в следующем разделе.

Наконец, в «шкатулке» у класса Boxостался еще одно средство задания расстояний — фиксированные области. Назначение их нетрудно понять из названия — это обычные компоненты, только невидимые, и их размер вы задаете сами. Казалось бы, польза от них не так уж велика, в подавляющем большинстве случаев вполне достаточно распорок и заполнителей, однако вскоре мы увидим что все не так просто. А сейчас мы рассмо­трим пример с фиксированными областями:

// BoxRigidAreas.java

// Пример использования фиксированных областей import javax.swing.*;

import com.porty.swing.BoxLayoutUtils; import java.awt.*;

запускать программу с примером — вертикальная панель снова уплывает куда-то к се­редине окна. Вскоре мы возьмем эту ситуацию под контроль, и любое расположение будет у нас в руках.

  1. Отформатировать таблицу по СТП МГУПИ

  1. Отформатировать текст по СТП МГУПИ, ввести формулы с помощью инструмента MSEquation

В итоге получим систему уравнений (9), у которой выше главной диагонали ненулевые элементы могут находиться только в первых I строках и столбцах. Решаем систему из первых I уравнений системы (9) относительно I неизвест-

Если ядро К(х, s) и правая часть /(s) — аналитические функции, то иногда целесообразнее использовать идею широко известного метода Батчера решения дифференциальных уравнений. В этом случае получится система уравнений с полностью заполненной матрицей, но при этом погрешность решения убывает

Вариант № 8