Spec-Zone .ru
спецификации, руководства, описания, API
Содержание документации

Улучшения AWT в Java™ 2 SDK, v1.4

1.4.2 Исправления ошибок
1.4.1 Исправления ошибок
Новая Подсистема Фокуса
Устаревшие Методы Фокуса
ActionEvents (и Другие События) Нуждаются в Метках времени
Бездисплейная Поддержка
API Центрирования окна, Необходимый для Многоэкранной Поддержки
Новый Полноэкранный Монопольный API Режима
Синхронизация Из Ошибки Диапазона От Видеодрайвера Под Windows NT Неукрашенные Фреймы
Поддержка Колеса мыши
Программируемое Изменение масштаба Frames
Динамическое Расположение Во время Изменяет размеры
Доступ к Компонентным Спискам Слушателя
Изменения, чтобы Перетащить и Отбросить
64-разрядное Соответствие на Солярисе
Непоследовательное Предупреждение DLL
Удаление DrawingSurface API
Новые Ключевые Модификаторы InputEvent
Изменение в Выпадающем Поведении для Меню Выбора
Компонент выбора Теперь Повинуется менеджеру по Расположению Констрэйнтсу

1.4.2 Исправления ошибок

4648702: На Microsoft Windows 2000 и Windows XP, a TextArea будет иногда выводить на экран только вертикальную полосу прокрутки, даже при том, что SCROLLBARS_BOTH поле устанавливается в true.

4636311: Модальные диалоговые окна могут зависнуть когда выполнено от a Runnable на выпуске 1.3.1 и 1.4.

4385243: Неспособный ввести текст в локалях Microsoft Windows, у которых нет кодовой страницы ANSI (такой как хинди).

1.4.1 Исправления ошибок

4690831: Игровые апплеты не в состоянии перекрасить должным образом с Internet Explorer.

4627627: Ключи обхода фокуса, перемещенные от awt.properties до Привилегированного API.

4636548/ 4639735: Катастрофический отказ выпуска 1.4, когда экранная заставка на Microsoft Windows 2000 активируется.

4379138: Проблемы на Linux с ключевыми событиями для некоторых мертвых клавиш.

4627542: Приложения Swing не поддерживают международные клавиатуры под Linux.

4395157: Под Linux на 1.3, не может ввести "%" в апплетах.

4669873: Ошибка перетаскивания и отбрасывания, сообщила относительно беты загрузочного лотка под Microsoft Windows, заставила приложение кратко замораживаться во время DnD и исправляется в заключительном выпуске 1.4.1.

Новая Подсистема Фокуса

Отчет bugtraq, который соответствует этому изменению: 4290675.

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

См. javadoc здесь.

Бездисплейная Поддержка

Отчет bugtraq, который соответствует этому изменению: 4281163.

Много сред, таких как мэйнфреймовые машины и выделенные серверы, не поддерживают дисплей, клавиатуру, или мышь. Бездисплейная поддержка включается новым GraphicsEnvironment методы isHeadless и isHeadlessInstance. Эти методы указывают, могут ли дисплей, клавиатура, и мышь поддерживаться в графической среде.

Изменения API для бездисплейного включают:

(*)Applet, Button, Checkbox, Choice, FileDialog, Label, List, Menu, MenuBar, MenuComponent, MenuItem, PopupMenu, Scrollbar, ScrollPane, TextArea, TextComponent, Frame, Window, Dialog, JApplet, JFrame, JWindow, JDialog, и TextField. Canvas и Panel не должны выдать это исключение, так как им можно дать пустые коллеги и обработаны как легкие веса.

Чтобы выполнить нашу среду с бездисплейной реализацией, следовать свойство может быть определено в java командная строка:

  -Djava.awt.headless=true
Если это свойство не определяется и дисплей, клавиатура, и мышь не поддерживается, то бездисплейная реализация используется по умолчанию.

Исходный код должен проверить на бездисплейный, так, чтобы исключение могло быть поймано корректно. Например, см. следующую предбездисплейную реализацию класса Foo:

class Foo {
  static Choice c = new Choice();  // could throw HeadlessException
}
Новая и улучшенная реализация Foo должен быть помещен в статический блок: 
class Foo {
  static Choice c;
  static {
    try {
      c = new Choice();
    catch (HeadlessException e) {
        ...
    }
  }
}

Новый Полноэкранный Монопольный API Режима

Отчет bugtraq, который соответствует этому изменению: 4189326.

Новый полноэкранный монопольный API режима поддерживает высокопроизводительную графику, приостанавливая систему управления окнами так, чтобы рисунок мог быть сделан непосредственно на экран. Полноэкранный режим, который полностью отличается от простого взятия AWT Frame, Window, или Dialog и расширение этого, чтобы соответствовать экрану, графический режим, посредством чего приложение берет на себя все управление над содержанием видео памяти. Приложение говорит графическую карту, что потянуть, как потянуть это, и когда потянуть это. Этот режим не всегда доступен. На некоторых операционных системах это не может быть реализовано вообще. На других операционных системах это может только быть доступно, если возможность поддерживается графической картой. Однако, этот режим является критическим для производительности и является необходимым для того, чтобы включить аппаратному зеркальному отражению страницы на Windows.

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

Изменения API:

Синхронизация Из Ошибки Диапазона От Видеодрайвера Под Windows NT

Отчет bugtraq, который соответствует этому изменению: 4452207.

Если у Вас есть Dell Optiplex GX110, используя Контроллер Графики Intel 810 под Windows NT, можно вытащить "синхронизацию из диапазона" сообщение от видеодрайвера, если Вы изменяете режим отображения не раз и используете высокое разрешение дисплея. Есть очевидно ошибка в (DirectX) видеодрайвер, который вызывает это. Есть несколько обходных решений к этой проблеме:

Неукрашенные Фреймы

Отчет bugtraq, который соответствует этому изменению: 4038769.

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

Этот выпуск позволяет приложению Java выключать создание художественных оформлений фрейма; никакая собственная строка заголовка, системное меню, граница, или другие собственные зависимые от операционной системы экранные компоненты не появляются, когда этот режим включается. AWT и компоненты Swing работают прозрачно.

Изменения к java.awt.Frame:

    public void setUndecorated(boolean undecorated)

    public boolean isUndecorated()

Изменения к java.awt.Dialog:

    public void setUndecorated(boolean undecorated)

    public boolean isUndecorated()

Поддержка Колеса мыши

Отчет bugtraq, который соответствует этому изменению: 4289845.

Колесо мыши, с колесиком прокрутки вместо средней кнопки мыши, включается с новой встроенной поддержкой Java прокрутки через колесо мыши. java.awt.event.MouseWheelEvent класс включает поддержке без шва прокрутки колеса мыши в приложениях Java без перекомпиляции необходимого. Кроме того, новое java.awt.event.MouseWheelListener интерфейс позволяет настройку поведения колеса мыши.

Отметьте, для тех, которые используют колесо мыши на Linux, см. здесь.

Программируемое Изменение масштаба Frames

Отчет bugtraq, который соответствует этому изменению: 4071554.

Ранее не было никакого способа масштабировать (или максимизировать) a Frame программно. Эта опция была добавлена к этому выпуску.

Новый интерфейс java.awt.event.WindowStateListener представляется.

Изменения к java.awt.Frame:

    public static final int MAXIMIZED_HORIZ;

    public static final int MAXIMIZED_VERT;

    public static final int MAXIMIZED_BOTH;

    public synchronized void setMaximizedBounds(Rectangle bounds)

    public Rectangle getMaximizedBounds()

    public synchronized void setExtendedState(int state)

    public synchronized int getExtendedState()

Изменения к java.awt.event.WindowEvent:

    public static final int WINDOW_STATE_CHANGED;

    public WindowEvent(Window source, int id, Window opposite, int oldState, int newState)

    public WindowEvent(Window source, int id, int oldState, int newState)

    public int getOldState()

    public int getNewState()

Изменения к java.awt.AWTEvent:

    public final static long WINDOW_STATE_EVENT_MASK;

Изменения к java.awt.Toolkit:

    public boolean isFrameStateSupported(int state) throws HeadlessException

Изменения к java.awt.Window:

    public synchronized void addWindowStateListener(WindowStateListener l)

    public synchronized void removeWindowStateListener(WindowStateListener l)

    public synchronized WindowStateListener[] getWindowStateListeners()

    protected void processWindowStateEvent(WindowEvent e)

Изменение к java.awt.event.WindowAdapter:

    public void windowStateChanged(WindowEvent e)

Изменения к java.awt.AWTEventMulticaster:

    public static WindowStateListener add(WindowStateListener a, WindowStateListener b)

    public static WindowStateListener remove(WindowStateListener l, WindowStateListener oldl)

Динамическое Расположение Во время Изменяет размеры

Отчет bugtraq, который соответствует этому изменению: 4077991.

Ранее, динамическое изменение размеров окна не поддерживалось на всех платформах. Например, на Windows NT, с телом изменяют размеры на, изменяя размеры окна, повторно вычисленного расположение только, когда перетаскивание было закончено. Это было фиксировано в этом выпуске с добавлением нового настольного свойства awt.dynamicLayoutSupported. Когда динамическое расположение включается, a Container непрерывно размечает его компоненты, как это изменяет размеры. Если отключено, расположение будет проверено после того, как изменение размеров закончилось.

API изменяется на java.awt.Toolkit.

    public void setDynamicLayout(boolean dynamic)

    protected boolean isDynamicLayoutSet()

    public boolean isDynamicLayoutActive()

Доступ к Компонентным Спискам Слушателя

Отчет bugtraq, который соответствует этому изменению: 4290704.

Ранее все состояние в компоненте AWT, который мог быть записан, могло также быть считано. Например, в компонентном API нет никаких свойств только для записи. Слушатели события были известным исключением. Слушателями события AWT управляют согласно соглашениям JavaBeansTM с парой методов: addXXXListener и removeXXXListener для слушателя, который реализует XXXEventListener интерфейс.

Никакой доступ не был обеспечен для списков слушателя непосредственно. Поля, которые содержат списки слушателя, являются частным пакетом, и никакой метод не был то, при условии, что возвраты содержание слушателя перечисляют. Это вызвало некоторые проблемы для Swing и других клиентов AWT.

Чтобы смягчить проблему в Java 2 SDK, v1.3 выпуск, мы добавили a getListeners метод к Component и к классам Swing, которые определили списки слушателя. getListeners метод использует класс, чтобы определить определенный список слушателя. Например получить всех слушателей, добавленных с addFocusListener, можно было бы записать: getListeners(FocusListener.class).

Этот определенный подход к представлению списков слушателя был проявлен, чтобы минимизировать полное изменение к общедоступному API AWT/Swing. Это не было предназначено, чтобы быть соглашением для всего JavaBeans, и это не обрабатывало PropertyChangeListeners - который может быть добавлен к единственному свойству, как в addPropertyChangeListener("myProperty", myListener). Для этого выпуска мы разработали больше полного решения доступа к слушателям события. Два концептуальных изменения:

Есть новое java.awt.event.AWTEventListenerProxy класс.

API Изменяется на java.awt.Toolkit:

    public PropertyChangeListener[] getPropertyChangeListeners()

    public synchronized PropertyChangeListener[] getPropertyChangeListeners(String propertyName)

    public AWTEventListener[] getAWTEventListeners()

    public AWTEventListener[] getAWTEventListeners(long eventMask)

Изменения, чтобы Перетащить и Отбросить

Отчеты bugtraq, который соответствует этому изменению: 4407057 и 4426750.

В Солярисе и выпусках Linux Java 2 Standard Edition, SDK 1.3, несколько из тяжеловеса AWT Components показанное значение по умолчанию перетаскивают поведение через среднюю кнопку мыши, даже если приложение не идентифицировало их Components как DragSources через java.awt.dnd API. Они Components были реализованы, используя коллеги Мотива, и Мотив обеспечивает, средняя кнопка перетаскивают поведение для этих коллег по умолчанию.

Из-за проекта AWT, и из-за ошибок в библиотеке Мотива, это поведение по умолчанию было источником многочисленных проблем устойчивости. Вместо того, чтобы продолжать рисковать устойчивостью AWT и Перетаскивать & Отбрасывание для нишевой функции, мы хотели отключать эту опцию явно в наших реализациях.

Разработчики могут все еще идентифицировать их Components как DragSources в их приложениях, используя java.awt.dnd API. Это и функционально и поддерживается. Этот подход превосходит полагающийся на поведение Мотива по умолчанию в любом случае, потому что это включает, перетаскивают поддержку их Components на всех платформах, не только Солярисе и Linux.

64-разрядное Соответствие на Машинах Соляриса

Отчет bugtraq, который соответствует этому изменению: 4295833.

64-разрядные приложения Соляриса используют 64 бита, чтобы адресовать память вместо 32. Это позволяет большие приложения, обеспечивая намного большее пространство виртуальной памяти. Для этого выпуска AWT был принесен до 64-разрядного соответствия. Для получения дополнительной информации см. здесь.

Непоследовательное Предупреждение DLL

Отчет bugtraq, который соответствует этому изменению: 4414004.

Если Вы установили английский VC ++ 6.0 на машину, которой также устанавливали азиатский Windows NT, можно встретиться со странными артефактами, представляя азиатский текст в TextArea компонент. Можно также видеть эту проблему, если Вы установили Microsoft Exchange или Microsoft Office 97 на машину рабочий азиатский Windows NT 4.0. Хотя об этой проблеме сообщили на японской версии Windows NT, это, вероятно, произойдет на других нелатинских версиях NT также, таких как китайский или корейский язык.

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

Удаление API Поверхности Рисунка

Отчет bugtraq, который соответствует этому изменению: 4293646.

sun.awt.DrawingSurface API был удален. Это никогда не было обнародовано, но некоторые разработчики использовали это. Функциональность была заменена JAWT. Для получения дополнительной информации см. Собственное Интерфейсное описание AWT.

API Центрирования окна, Необходимый для Многоэкранной Поддержки

Отчет bugtraq, который соответствует этому изменению: 4463949.

Xinerama-осведомленные приложения, работающие на многоголовых системах, вызвали проблемы, которые привели ко множеству отчетов об ошибках. Некоторые многоголовые среды используют мониторы с небольшими или никакими границами, которые могут бодаться против друг друга так, что, получающийся эффект является одним гигантским дисплеем. В этом случае "должным образом" центрируемое окно может охватить многократные экраны. Другие многоголовые среды используют регулярные мониторы CRT с несколькими дюймами упаковки между фактическими областями дисплея. В этом случае окно, охватывающее многократные экраны, производит эффект дезориентации, особенно если окно не может быть перетащено на один монитор или другой (экран входа в систему Соляриса, например). Вкратце не было никакого способа сказать, где центрировать окно в среде Xinerama.

Чтобы рассмотреть эту проблему, X групп добавили API, который позволяет пользователям Xinerama определять, где они хотят, чтобы "центрируемые" окна центрировались, и позволяет разработчикам Xinerama-осведомленных приложений кодировать соответственно.

До этого выпуска способ центрировать окно состоял в том, чтобы центрировать это в пределах границ значения по умолчанию GraphicsDevice, как это:

    bounds = getDefaultScreenDevice().getDefaultConfiguration().getBounds();
    frame.setLocation(bounds / 2 - size of window / 2);
Этот код центрировал бы окна "правильно" на системах Xinerama, где окна должны центрироваться ко всему координатному пространству Xinerama.

С этого выпуска отправьте 4356756 - фиксируют JDKs, будет центрировать окна "правильно" на системах Xinerama, где окна должны центрироваться в пределах первого дисплея.

Выполнять это, getCenterPoint метод был добавлен к GraphicsEnvironment .

Этот метод работает следующим образом над различными платформами:

С JDK 1.4, корректный код для того, чтобы центрироваться:

    frame.setLocation(getCenterPoint() - size of window / 2);

Другой метод, добавленный к GraphicsEnvironment getMaximumWindowBounds. Оба getCenterPoint и getMaximumWindowBounds бросок a HeadlessException когда в Бездисплейном режиме.

Новые Ключевые Модификаторы InputEvent

Отчеты bugtraq, который соответствует этому изменению: 4387938 и 4421515.

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

Чтобы адресовать этот недостаток, следующие константы были добавлены к InputEvent:

Следующие методы были добавлены к InputEvent:

Спецификация класса для MouseEvent был обновлен. Следующие константы были также добавлены к MouseEvent:

Эти методы в MouseEvent были добавлены:

DragSourceDragEvent имеет новый метод getGestureModifiersEx.

Изменение в Выпадающем Поведении для Меню Выбора

Отчет bugtraq, который соответствует этому изменению: 4462677.

Choice поведение выпадающего меню изменилось от JDK 1.3.1 к 1.4. В 1.3.1, Вы могли щелкнуть где угодно по панели выбора, и меню будет выпадающий. В 1.4, следует щелкнуть по селектору стрелки на правой стороне Choice панель. Щелчок где-либо еще по Choice панель не имеет никакого эффекта. Кроме того, символ на Choice панель изменилась от панели до комбинации стрелки/панели. Наконец, если выпадающее меню расширяется за пределами родителя, щелкая по той области, приложение внизу приносится к переднему плану. Это происходит на Солярисе, не Windows.

Компонент выбора Теперь Повинуется менеджеру по Расположению Констрэйнтсу

Отчет bugtraq, который соответствует этому изменению: 4288285.

В выпусках до 1.4, AWT Choice виджет, иногда проигнорированный размер, которым менеджер по расположению сказал этому быть. С этого выпуска это теперь повинуется менеджеру по расположению ограничения.

Устаревшие Методы Фокуса

Отчет bugtraq, который соответствует этому изменению: 4476300.

Новая подсистема фокуса, представленная в этом выпуске, представляла новую архитектуру и новую терминологию для того, чтобы обработать клавиатурный фокус в сложном AWT и приложениях Swing. До этого проекта многие из связанных с фокусом API были непоследовательны в использовании и termonology, были ненадлежащим образом задокументированы, и приведены плохо разработанный UIs. Теперь, когда новая архитектура на месте, самый вопиющий из этих API был осужден.

Следующие константы и методы были осуждены:

ActionEvents (и Другие События) Нуждаются в Метках времени

Отчет bugtraq, который соответствует этому изменению: 4434193.

Новая архитектура фокуса включает механизм ввода с опережением, который гарантирует что последующий KeyEvents, которые следуют за a KeyEvent это инициирует передачу фокуса, не поставляются, пока передача не завершается. Проект для этой функции основан на метках времени UTC различных событий. События с метками времени позже чем то из инициирующего события ставятся в очередь разрешение на ожидании передачи; события с более ранними метками времени не.

Чтобы реализовать эту опцию, код фокуса отслеживает метку времени события, в настоящий момент обрабатываемого. Если изменение фокуса инициируется во время этой обработки, метка времени доступна для использования. Однако, если у текущего события нет метки времени, то время существующей системы используется. Это время обычно слишком далеко перед временем, когда событие фактически имело место, чтобы иметь любое реальное применение. В результате сбои механизма ввода с опережением, и KeyEvents поставляются прежде, чем передача фокуса завершается.

Наиболее распространенный случай, где мы встретились с этой проблемой, был с ActionEvents. ActionEvents являются высокоуровневыми, семантическими событиями, сгенерированными в ответ на базовый InputEvents. В то время как InputEvents связали метки времени с ними, ActionEvents не сделал. ActionEvent API был поэтому расширен, чтобы разместить метку времени, и реализация была обновлена так, чтобы ActionEvent's метка времени равно тому из ее базовых InputEvent.

Следующие методы были добавлены к ActionEvent:

Следующий ActionEvent методы были изменены:

getWhen метод был добавлен к InvocationEvent.

InvocationEvent конструкторы InvocationEvent(Object, Runnable) и InvocationEvent(Object, Runnable, Object, boolean) были изменены.

Новый конструктор InputMethodEvent(Component, int, long, AttributedCharacterIterator, int, TextHitInfo, TextHitInfo) был добавлен к InputMethodEvent, так же как getWhen метод.

Следующий InputMethodEvent конструкторы были изменены:

Наконец, следующие методы были добавлены к EventQueue:

Oracle и/или его филиалы Авторское право © 1993, 2011, Oracle и/или его филиалы. Все права защищены.
Свяжитесь с Нами