Spec-Zone .ru
спецификации, руководства, описания, API
|
1.4.2 Исправления ошибок
1.4.1 Исправления ошибок
Новая Подсистема Фокуса
Устаревшие Методы Фокуса
ActionEvents (и Другие События) Метки времени Потребности
Бездисплейная Поддержка
API Центрирования окна, Необходимый для Многоэкранной Поддержки
Новый Полноэкранный Монопольный API Режима
Синхронизация Из Ошибки Диапазона От Видеодрайвера Под Windows NT Неукрашенные Фреймы
Поддержка Колеса мыши
Программируемое Изменение масштаба Frame
s
Динамическое Расположение Во время Изменяет размеры
Доступ к Компонентным Спискам Слушателя
Изменения, чтобы Перетащить и Отбросить
64-разрядное Соответствие на Солярисе
Непоследовательное Предупреждение DLL
Удаление DrawingSurface
API
Новые Ключевые Модификаторы InputEvent
Изменение в Выпадающем Поведении для Меню Выбора
Компонент выбора Теперь Повинуется менеджеру по Расположению Констрэйнтсу
TextArea
будет иногда выводить на экран только вертикальную полосу прокрутки, даже при том, что SCROLLBARS_BOTH
поле устанавливается в true
.
Runnable
на выпуске 1.3.1 и 1.4.
Отчет bugtraq, который соответствует этому изменению:
Новая подсистема фокуса заменяет предыдущую архитектуру фокуса и адресует много связанных с фокусом ошибок, вызванных несогласованностями платформы, и несовместимостями между компонентами Swing и AWT. См. новую Спецификацию Модели Фокуса для получения дальнейшей информации.
См. javadoc здесь.
Бездисплейная ПоддержкаОтчет bugtraq, который соответствует этому изменению:
Много сред, таких как мэйнфреймовые машины и выделенные серверы, не поддерживают дисплей, клавиатуру, или мышь. Бездисплейная поддержка включается новым GraphicsEnvironment
методы isHeadless
и isHeadlessInstance
. Эти методы указывают, могут ли дисплей, клавиатура, и мышь поддерживаться в графической среде.
Изменения API для бездисплейного включают:
java.awt.HeadlessException
, представляется. Это получается из UnsupportedOperationException
, который происходит из RuntimeException
, так, чтобы существующие реализации методов, которые выдают новое исключение, не потребовали изменений подписи.java.awt.GraphicsEnvironment
. public static boolean isHeadless() public boolean isHeadlessInstance()
Applet
и все тяжелые компоненты (*) изменяются на бросок HeadlessException
если дисплей, клавиатура, и мышь не поддерживаются реализацией инструментария. Весь javadoc наклеивает всех конструкторов, изменяются, чтобы отразить это RuntimeException
.Robot
конструктор бросает AWTException
если дисплей, клавиатура, и мышь не поддерживаются реализацией инструментария.Toolkit
и GraphicsEnvironment
, за исключением шрифтов, обработка изображений, и печать, изменяются на бросок HeadlessException
если дисплей, клавиатура, и мышь не поддерживаются. Весь javadoc наклеивает эти методы, изменяются, чтобы отразить это RuntimeException
.HeadlessException
.HeadlessException
бросается если и только если isHeadless
возвращает true, и что все комментарии javadoc должны определить это.(*)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Если это свойство не определяется и дисплей, клавиатура, и мышь не поддерживается, то бездисплейная реализация используется по умолчанию.
Исходный код должен проверить на бездисплейный, так, чтобы исключение могло быть поймано корректно. Например, см. следующую предбездисплейную реализацию class 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, который соответствует этому изменению:
Новый полноэкранный монопольный API режима поддерживает высокопроизводительную графику, приостанавливая систему управления окнами так, чтобы рисунок мог быть сделан непосредственно на экран. Полноэкранный режим, который полностью отличается от простого взятия AWT Frame
, Window
, или Dialog
и расширение этого, чтобы соответствовать экрану, графический режим, посредством чего приложение берет на себя все управление над содержанием видеопамяти. Приложение говорит видеокарту, что потянуть, как потянуть это, и когда потянуть это. Этот режим не всегда доступен. На некоторых операционных системах это не может быть реализовано вообще. На других операционных системах это может только быть доступно, если возможность поддерживается видеокартой. Однако, этот режим является критическим для производительности и является необходимым для того, чтобы включить аппаратному зеркальному отражению страницы на Windows.
Для учебного руководства, объясняющего, как использовать полный экран монопольный режим API с несколькими примерами кода, см.
Изменения API:
java.awt.DisplayMode
, представляется.java.awt.GraphicsDevice
:
public void setFullScreenWindow(Window w) public Window getFullScreenWindow() public boolean isDisplayChangeSupported() public void setDisplayMode(DisplayMode dm) public DisplayMode getDisplayMode() public DisplayMode[] getDisplayModes()
java.awt.image.BufferStrategy
.java.awt.BufferCapabilities
может использоваться, создавая буферную стратегию. Аналогично, новый class java.awt.ImageCapabilities
доступно, чтобы определить возможности изображения определенной конфигурации.Canvas
или a Window
. Есть две буферных стратегии, которые поддерживаются как защищенные внутренние классы: java.awt.Component.FlipBufferStrategy
и java.awt.Component.BltBufferStrategy
. Один из этих двух внутренних классов используется на Canvas
или Window
когда createBufferStrategy
метод вызывают, в зависимости от BufferCapabilities
объект, предоставленный, создавая стратегию (если любой). Использовать буферную стратегию определенным компонентом, getBufferStrategy
метод используется.Отчет bugtraq, который соответствует этому изменению:
Если у Вас есть Dell Optiplex GX110, используя Контроллер Графики Intel 810 под Windows NT, можно вытащить "синхронизацию из диапазона" сообщение от видеодрайвера, если Вы изменяете режим отображения не раз и используете высокое разрешение дисплея. Есть очевидно ошибка в (DirectX) видеодрайвер, который вызывает это. Есть несколько обходных решений к этой проблеме:
-Dsun.java2d.noddraw=true
в командной строке.1152 X 864 8 85 1152 X 864 16 85 1152 X 864 24 85 1280 X 1024 8 70,72,75,85 1280 X 1024 16 70,72,75,85 1280 X 1024 24 70,75,85 Bad Color (Unsatisfactory appearance in terms of color) 1024 X 768 8 60,70,72,75,85
Отчет bugtraq, который соответствует этому изменению:
Поскольку определенные приложения, не имеющие собственных художественных оформлений фрейма, имеет смысл. Например, приложения, которые будут натыкаться на многие платформы и которые требуют, чтобы стиль был тем же самым, или когда программист не хочет конечного пользователя, приходящего в соприкосновение с собственной операционной системой.
Этот выпуск позволяет приложению 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, который соответствует этому изменению:
Колесо мыши, с колесиком прокрутки вместо средней кнопки мыши, включается с новой встроенной поддержкой Java прокрутки через колесо мыши. java.awt.event.MouseWheelEvent
class включает поддержке без шва прокрутки колеса мыши в приложениях Java без перекомпиляции необходимого. Кроме того, новое java.awt.event.MouseWheelListener
интерфейс позволяет настройку поведения колеса мыши.
Отметьте, для тех, которые используют колесо мыши на Linux, см. здесь.
Component
чем может быть выведен на экран сразу, так, что ползунок прокрутки не занимает всю полосу прокрутки.setWheelScrollEnabled(false)
.TextArea
, Choice
, FileDialog
, и List
. Такие компоненты позволят своим собственным коллегам обрабатывать прокрутку колеса.Component
s то, которые не наследовали собственного поведения колеса мыши, распространит события колеса мыши Container
иерархия до a Container
с MouseWheelEvent
s включал, находится. Это обычно a ScrollPane
. События колеса мыши поставляются Component
с MouseWheelEvent
s включал.MouseWheelListener
s, чтобы настроить, что происходит, когда колесо мыши перемещается, в то время как мышь по a Component
. В случае Component
s, у которых уже есть собственная обработка событий колеса мыши, клиенты могут использовать событие колеса мыши, чтобы избежать собственной обработки.java.awt.ScrollPane
изменяется, чтобы иметь MouseWheelEvent
s включал по умолчанию. Когда a ScrollPane
получает a MouseWheelEvent
, это должным образом прокрутит свой содержавший Component
. Эта функциональность может быть отключена с новым setWheelScrollingEnabled
метод.Легкая Поддержка:
MouseWheelListener
.MouseWheelListener
s может быть добавлен к любому JComponent
для пользовательской обработки событий.javax.swing.JScrollPane
изменяется, чтобы должным образом прокрутить его просматриваемый компонент. Как java.awt.ScrollPane
, это может быть отключено, используя setWheelScrollingEnabled
.В дополнение к новому class и новому интерфейсу, ранее упомянутому, есть некоторые другие изменения к API, чтобы поддерживать колесо мыши.
java.awt.AWTEvent
:
public final static long MOUSE_WHEEL_EVENT_MASK;
java.awt.AWTEventMulticaster
:
public void mouseWheelMoved(MouseWheelEvent e) public static MouseWheelListener add(MouseWheelListener a, MouseWheelListener b) public static MouseWheelListener remove(MouseWheelListener l, MouseWheelListener oldl)
java.awt.Component
:
public synchronized void addMouseWheelListener(MouseWheelListener l) public synchronized void removeMouseWheelListener(MouseWheelListener l)
java.awt.ScrollPane
:
public void setWheelScrollingEnabled(boolean handleWheel) public boolean isWheelScrollingEnabled()
java.awt.Robot
:
public synchronized void mouseWheel(int wheelAmt)
Для Linux, чтобы распознать Ваше колесо мыши, две модификации к /etc/X11/XF86Config
файл требуется. Под разделом "Указателя":
Добавьте строку:
ZAxisMapping 4 5
Измените протокол на: "imps/2" (это изменится в зависимости от Вашей определенной мыши колеса).
Программируемое Изменение масштаба Frame
s
Отчет bugtraq, который соответствует этому изменению:
Ранее не было никакого способа масштабировать (или максимизировать) 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, который соответствует этому изменению:
Ранее, динамическое изменение размеров окна не поддерживалось на всех платформах. Например, на Windows NT, с телом изменяют размеры на, изменяя размеры окна, повторно вычисленного расположение только, когда перетаскивание было закончено. Это было фиксировано в этом выпуске с добавлением нового настольного свойства awt.dynamicLayoutSupported
. Когда динамическое расположение включается, a Container
непрерывно размечает его компоненты, как это изменяет размеры. Если отключено, расположение будет проверено после того, как изменение размеров закончилось.
API изменяется на java.awt.Toolkit
.
public void setDynamicLayout(boolean dynamic) protected boolean isDynamicLayoutSet() public boolean isDynamicLayoutActive()
Доступ к Компонентным Спискам Слушателя
Отчет bugtraq, который соответствует этому изменению:
Ранее все состояние в компоненте AWT, который мог быть записан, могло также быть считано. Например, в компонентном API нет никаких свойств только для записи. Слушатели события были известным исключением. Слушателями события AWT управляют согласно соглашениям JavaBeansTM с парой методов: addXXXListener
и removeXXXListener
для слушателя, который реализует XXXEventListener
интерфейс.
Никакой доступ не был обеспечен для списков слушателя непосредственно. Поля, которые содержат списки слушателя, являются частным пакетом, и никакой метод не был то, при условии, что возвраты содержание слушателя перечисляют. Это вызвало некоторые проблемы для Swing и других клиентов AWT.
Чтобы смягчить проблему в Java 2 SDK, v1.3 выпуск, мы добавили a getListeners
метод к Component
и к классам Swing, которые определили списки слушателя. getListeners
метод использует class, чтобы определить определенный список слушателя. Например получить всех слушателей, добавленных с addFocusListener
, можно было бы записать: getListeners(FocusListener.class)
.
Этот определенный подход к представлению списков слушателя был проявлен, чтобы минимизировать полное изменение к общедоступному API AWT/Swing. Это не было предназначено, чтобы быть соглашением для всего JavaBeans, и это не обрабатывало PropertyChangeListener
s - который может быть добавлен к единственному свойству, как в addPropertyChangeListener("myProperty", myListener)
. Для этого выпуска мы разработали более полное решение доступа к слушателям события. Два концептуальных изменения:
getFooListeners
метод к добавить/удалить соглашению в AWT и классах Swing.PropertyChangeListener
s и VetoableChangeListener
s, включая тех, которые слушают единственное свойство, используя новое java.util.EventListenerProxy
class.Есть новое java.awt.event.AWTEventListenerProxy
class.
API Изменяется на java.awt.Toolkit
:
public PropertyChangeListener[] getPropertyChangeListeners() public synchronized PropertyChangeListener[] getPropertyChangeListeners(String propertyName) public AWTEventListener[] getAWTEventListeners() public AWTEventListener[] getAWTEventListeners(long eventMask)
Изменения, чтобы Перетащить и Отбросить
Отчеты bugtraq, который соответствует этому изменению:
В Солярисе и выпусках Linux Java 2 Standard Edition, SDK 1.3, несколько из тяжеловеса AWT Component
s показанное значение по умолчанию перетаскивают поведение через среднюю кнопку мыши, даже если приложение не идентифицировало их Components
как DragSource
s через java.awt.dnd API
. Они Component
s были реализованы, используя коллеги Мотива, и Мотив обеспечивает, средняя кнопка перетаскивают поведение для этих коллег по умолчанию.
Из-за проекта AWT, и из-за ошибок в библиотеке Мотива, это поведение значения по умолчанию было источником многочисленных проблем устойчивости. Вместо того, чтобы продолжать рисковать устойчивостью AWT и Перетаскивать & Отбрасывание для нишевой функции, мы хотели отключать эту опцию явно в наших реализациях.
Разработчики могут все еще идентифицировать их Component
s как DragSource
s в их приложениях, используя java.awt.dnd API
. Это и функционально и поддерживается. Этот подход превосходит положение на поведение Мотива значения по умолчанию в любом случае, потому что это включает, перетаскивают поддержку их Component
s на всех платформах, не только Солярисе и Linux.
64-разрядное Соответствие на Машинах Соляриса
Отчет bugtraq, который соответствует этому изменению:
64-разрядные приложения Соляриса используют 64 бита, чтобы адресовать память вместо 32. Это позволяет большие приложения, обеспечивая намного большее пространство виртуальной памяти. Для этого выпуска AWT был принесен до 64-разрядного соответствия. Для получения дополнительной информации см. здесь.
Непоследовательное Предупреждение DLLОтчет bugtraq, который соответствует этому изменению:
Если Вы установили английский VC ++ 6.0 на машину, которой также устанавливали азиатский Windows NT, можно встретиться со странными артефактами, представляя азиатский текст в TextArea
компонент. Можно также видеть эту проблему, если Вы установили Microsoft Exchange или Microsoft Office 97 на машину рабочий азиатский Windows NT 4.0. Хотя об этой проблеме сообщили на японской версии Windows NT, это, вероятно, произойдет на других нелатинских версиях NT также, таких как китайский или корейский язык.
Проблема была вызвана когда установка тех программ, замененных азиат Riched32.dll с английской версией. Проблема может быть исправлена, заменяя Riched32.dll азиатской версией.
Удаление API Поверхности РисункаОтчет bugtraq, который соответствует этому изменению:
sun.awt.DrawingSurface
API был удален. Это никогда не было обнародовано, но некоторые разработчики использовали это. Функциональность была заменена JAWT. Для получения дополнительной информации см. Собственное описание Интерфейса AWT.
Отчет bugtraq, который соответствует этому изменению:
Xinerama-осведомленные приложения, работающие на многоголовых системах, вызвали проблемы, которые привели ко множеству отчетов об ошибках. Некоторые многоголовые среды используют мониторы с небольшими или никакими границами, которые могут бодаться против друг друга так, что, получающийся эффект является одним гигантским дисплеем. В этом случае "должным образом" центрируемое окно может охватить многократные экраны. Другие многоголовые среды используют регулярные мониторы CRT с несколькими дюймами упаковки между фактическими областями дисплея. В этом случае окно, охватывающее многократные экраны, производит эффект дезориентации, особенно если окно не может быть перетащено на один монитор или другой (экран входа в систему Соляриса, например). Вкратце не было никакого способа сказать, где центрировать окно в среде Xinerama.
Чтобы рассмотреть эту проблему, X групп добавили API, который позволяет пользователям Xinerama определять, где они хотят, чтобы "центрируемые" окна центрировались, и позволяет разработчикам Xinerama-осведомленных приложений кодировать соответственно.
До этого выпуска способ центрировать окно состоял в том, чтобы центрировать это в пределах границ значения по умолчанию GraphicsDevice
, как это:
bounds = getDefaultScreenDevice().getDefaultConfiguration().getBounds(); frame.setLocation(bounds / 2 - size of window / 2);Этот код центрировал бы окна "правильно" на системах Xinerama, где окна должны центрироваться ко всему координатному пространству Xinerama.
С этого выпуска отправьте
Выполнять это, getCenterPoint
метод был добавлен к GraphicsEnvironment
.
Этот метод работает следующим образом над различными платформами:
getCenterPoint
возвращает координаты центра основного дисплея.getCenterPoint
возвращает центральную точку основного дисплея.getCenterPoint
отражает их значение. Иначе, это возвращает точку в центре виртуального координатного пространства. (Практически, это будет почти всегда устанавливаться - CDE устанавливает это по умолчанию.)С JDK 1.4, корректный код для того, чтобы центрироваться:
frame.setLocation(getCenterPoint() - size of window / 2);
Другой метод, добавленный к GraphicsEnvironment
getMaximumWindowBounds
. Оба getCenterPoint
и getMaximumWindowBounds
бросок a HeadlessException
когда в Бездисплейном режиме.
Отчеты bugtraq, который соответствует этому изменению:
Ранее, InputEvent
у модификаторов были те же самые значения для клавиатуры и кнопок мыши. В определенных ситуациях не было никакого способа различить, какой был нажат или когда больше чем один был сохранен одновременно. Включенные случаи этих ситуаций, когда больше чем одна кнопка мыши снижалась одновременно, или когда модифицирующая клавиша использовалась, чтобы изменить событие от нажатия мыши.
Чтобы адресовать этот недостаток, следующие константы были добавлены к InputEvent
:
SHIFT_DOWN_MASK
CTRL_DOWN_MASK
META_DOWN_MASK
ALT_DOWN_MASK
ALT_GRAPH_DOWN_MASK
BUTTON1_DOWN_MASK
BUTTON2_DOWN_MASK
BUTTON3_DOWN_MASK
Следующие методы были добавлены к InputEvent
:
Спецификация class для MouseEvent
был обновлен. Следующие константы были также добавлены к MouseEvent
:
Эти методы в MouseEvent
были добавлены:
MouseEvent(Component source, int id, long when, int modifiers, int x, int y, int clickCount, boolean popupTrigger, int button)
getButton
getMouseModifiersText
DragSourceDragEvent
имеет новый метод
getGestureModifiersEx
.
Отчет bugtraq, который соответствует этому изменению:
Choice
поведение выпадающего меню изменилось от JDK 1.3.1 к 1.4. В 1.3.1, Вы могли щелкнуть где угодно по панели выбора, и меню будет выпадающий. В 1.4, следует щелкнуть по селектору стрелки на правой стороне Choice
панель. Щелчок где-либо еще по Choice
панель не имеет никакого эффекта. Кроме того, символ на Choice
панель изменилась от панели до комбинации стрелки/панели. Наконец, если выпадающее меню расширяется за пределами родителя, щелкая по той области, приложение внизу приносится к переднему плану. Это происходит на Солярисе, не Windows.
Отчет bugtraq, который соответствует этому изменению:
В выпусках до 1.4, AWT Choice
виджет, иногда проигнорированный размер, которым менеджер по расположению сказал этому быть. С этого выпуска это теперь повинуется менеджеру по расположению ограничения.
Отчет bugtraq, который соответствует этому изменению:
Новая подсистема фокуса, представленная в этом выпуске, представляла новую архитектуру и новую терминологию для того, чтобы обработать клавиатурный фокус в сложном AWT и приложениях Swing. До этого проекта многие из связанных с фокусом API были непоследовательны в использовании и termonology, были ненадлежащим образом задокументированы, и приведены плохо разработанный UIs. Теперь, когда новая архитектура на месте, самый вопиющий из этих API был осужден.
Следующие константы и методы были осуждены:
javax.swing.FocusManager.FOCUS_MANAGER_CLASS_PROPERTY
javax.swing.FocusManager.disableSwingFocusManager()
javax.swing.FocusManager.isFocusManagerEnabled()
javax.swing.JComponent.requestDefaultFocus()
javax.swing.JComponent.isManagingFocus()
javax.swing.JComponent.setNextFocusableComponent(Component)
javax.swing.JComponent.getNextFocusableComponent()
java.awt.Component.isFocusTraversable()
java.awt.Component.hasFocus()
javax.swing.SwingUtilities.findFocusOwner(Component)
Отчет bugtraq, который соответствует этому изменению:
Новая архитектура фокуса включает механизм ввода с опережением, который гарантирует что последующий KeyEvent
s, которые следуют за a KeyEvent
это инициирует передачу фокуса, не поставляются, пока передача не завершается. Проект для этой функции основан на метках времени UTC различных событий. События с метками времени позже чем то из инициирующего события ставятся в очередь разрешение на ожидании передачи; события с более ранними метками времени не.
Чтобы реализовать эту опцию, код фокуса отслеживает метку времени события, в настоящий момент обрабатываемого. Если изменение фокуса инициируется во время этой обработки, метка времени доступна для использования. Однако, если у текущего события нет метки времени, то время существующей системы используется. Это время обычно слишком далеко перед временем, когда событие фактически имело место, чтобы иметь любое реальное применение. В результате сбои механизма ввода с опережением, и KeyEvent
s поставляются прежде, чем передача фокуса завершается.
Наиболее распространенный случай, где мы встретились с этой проблемой, был с ActionEvent
s. ActionEvent
s являются высоким уровнем, семантические события, сгенерированные в ответ на базовый InputEvent
s. В то время как InputEvent
у s были метки времени, связанные с ними, ActionEvent
s не сделал. ActionEvent
API был поэтому расширен, чтобы разместить метку времени, и реализация была обновлена так, чтобы ActionEvent
's метка времени равно тому из ее базовых InputEvent
.
Следующие методы были добавлены к ActionEvent
:
Следующий ActionEvent
методы были изменены:
ActionEvent(Object source, int id, String command)
ActionEvent(Object source, int id, String command, int modifiers)
getWhen
метод был добавлен к InvocationEvent
.
InvocationEvent
конструкторы
InvocationEvent(Object, Runnable)
и
InvocationEvent(Object, Runnable, Object, boolean)
были изменены.
Новый конструктор
InputMethodEvent(Component, int, long, AttributedCharacterIterator, int, TextHitInfo, TextHitInfo)
был добавлен к InputMethodEvent
, так же как getWhen
метод.
Следующий InputMethodEvent
конструкторы были изменены:
InputMethodEvent(Component, int, AttributedCharacterIterator, int, TextHitInfo, TextHitInfo)
InputMethodEvent(Component, int, TextHitInfo, TextHitInfo)
.Наконец, следующие методы были добавлены к EventQueue
: