Графические интерфейсы пользователя Java

Чаще всего окно JWindow используют как splash окно, появляющееся на экране на время загрузки основного окна приложения.

Окно JWindow может быть связано с уже существующим, «родительским» фрейм окном.

Окно JWindow содержит непосредственно всего один компонент – корневую панель JRootPane, получить которую можно методом getRootPane.

Также с помощью методов getContentPane, getLayeredPane и getGlassPane можно получить доступ к панели содержимого, слоеной панели и к прозрачной панели.

По умолчанию для панели содержимого установлена компоновка BorderLayout.

На этом примере видно, что компонент JWindow не добавляется в родительский компонент JFrame, а создается как независимое окно.

Связывание окна JWindow с родительским фреймом дает возможность передать ему фокус ввода и, например, вводить текст в поле ввода, находящееся в окне, передав затем введенный текст родительскому окну.

И окно JWindow будет всегда располагается сверху родительского окна.

Event Dispatching Thread

Наверняка многие из вас сталкивались с ситуацией, когда нажатие кнопки, запуск команды или еще какое действие вызывает зависание всего интерфейса пользователя.

Причина этого кроется в том, что интерфейс основан на событиях.

Нажатие клавиши, движение мыши, и так далее – всё это ни что иное как события.

Они помещаются в одну очередь и обрабатываются одним потоком – Event Dispatching Thread, сокращенно EDT.

И все эти события обрабатываются одним потоком – EDT.

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

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

В течение этого времени поток, в котором обрабатывалось нажатие кнопки, будет просто блокирован.

А в этом же потоке обрабатываются и события мыши – то есть нажать кнопку «Отмена» и прервать выполнение запроса не получится: сгенерированные события встанут в очередь и будут обработаны только после того, как EDT будет разблокирован.

Решение этой проблемы в том, чтобы запускать все длительные операции в отдельном потоке.

Но тут возникает другая проблема.

Дело в том, что практически все компоненты Swing – НЕ потоко безопасны.

Что означает, что методы Swing компонентов должны вызываться в потоке EDT.

Следующий пример демонстрирует, когда код работает в потоке EDT.

Метод isEventDispatchThread класса SwingUtilities возвращает true, если текущий поток является потоком диспетчеризации событий AWT event dispatching thread.

Когда запускает метод main, текущий поток не является потоком EDT.

Когда выполняется обработчик событий нажатия кнопки, текущий поток является потоком EDT.

Таким образом, код в методе main создает графический интерфейс и отдельный поток EDT, в котором выполняются методы Swing компонентов.

И ваш метод main может быть занят другой задачей, такой как вычисление PI до 40 000 знаков после запятой.

И пользователю не нужно дождаться завершения метода main до того, как они смогут взаимодействовать с графическим интерфейсом.

Потому что библиотека AWT реализует свой собственный поток EDT для обработки взаимодействия с графическим интерфейсом.

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

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

Если он выглядит как щелчок поверх компонента, он вызывает обработчик щелчка мыши для этого компонента.

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

Например, если вы нажимаете на JButton, поток AWT передает щелчок мыши компоненту JButton, который интерпретирует его как «нажатие кнопки» и запускает собственное событие, которое будет передано в вызванный метод actionPerformed любого слушателя.

Поток AWT также обрабатывает перерисовку вашего графического интерфейса.

Каждый раз, когда вы вызываете repaint, в очередь событий помещается запрос «refresh».

Всякий раз, когда поток AWT видит запрос «refresh», он вызывает соответствующие методы для компоновки графического интерфейса и рисования любых компонентов, требующих рисования.

AWT-поток может фактически реализоваться несколькими потоками, которые координируют усилия, чтобы следить за щелчками мыши, нажатиями клавиш, запросами перерисовки и т. д.

Однако вы можете рассматривать это как один «поток AWT».

Компоненты AWT являются потокобезопасными, так как если вы вызываете метод setText компонента Label, он синхронизируется так, что отображаемый текст не может отображаться с частично старым значением и частично новым значением.

Однако компоненты Swing не являются потокобезопасными для большей эффективности.

Из-за этого вы должны убедиться, что любые изменения компонентов Swing, которые могут повлиять на их отображение, выполняются в потоке событий AWT EDT.

Один и тот же поток должен обновлять, то есть изменять поля, и отображать компонент.