Spec-Zone .ru
спецификации, руководства, описания, API
|
Этот документ содержит информацию, относящуюся ко всем 1.4.* выпускам. Для получения информации определенный для 1.4.1 и 1.4.2, см. Изменения Swing Начиная с Java 2 SDK, Standard Edition, v 1.4.
Определенные функции, обычно, которые оказывают большое влияние на Swing, были экстенсивно описаны в отдельных документах. Ссылка на эти документы:
JTabbedPane
с вкладками с возможностью прокруткиJSpinner
JFormattedTextField
Popup
и PopupFactory
Каждый раздел содержит изменения для ряда связанных классов. Большинство разделов фокусируется на классах, которые являются частью единственного компонента Swing как JEditorPane
или JTable
. Каждое изменение API связывается со ссылкой к отчету относительно
Box
JButton
JComboBox
JFileChooser
JInternalFrame
JList
JOptionPane
JPopupMenu
JPanel
JRootPane
JScrollBar
JScrollPane
JTabbedPane
JTable
JTextComponent
JTree
RepaintManager
SpringLayout
Отчет bugtraq, который соответствует этому изменению:
Исторически, суперкласс для Box
был Component
. С тех пор Box
не убывал от JComponent
, Вы не могли использовать это как нормальный компонент Swing, например, Вы не могли установить границы, или проблему revalidate
. Не только это, но и изменяющаяся видимость, или другие similiar визуальные свойства, на стандартном компоненте Swing обычно инициировали a repaint
или revalidate
, но Box
не соответствовал этому поведению. С этого выпуска, Box
и Box.Filler
теперь убывайте от JComponent
суперкласс и поэтому ведет себя больше как стандартные компоненты Swing.
Отчет bugtraq, который соответствует этому изменению:
BoxLayout
не рассматривал ComponentOrientation
из Container
это размечает. Другие менеджеры по расположению AWT были заставлены сделать это когда ComponentOrientation
опция была добавлена в JDK 1.2. Добавление этой опции к BoxLayout
делает это полезным для программ та поддержка локали Ближнего Востока. Поскольку BoxLayout
также используется внутренне другими компонентами Swing, такой как JOptionPane
, JToolBar
и JMenuBar
, добавление этой опции также необходимо для этих компонентов, чтобы поддерживать ComponentOrientation
.
Поддерживать эту функциональность, константы LINE_AXIS
и PAGE_AXIS
, и конструктор,
BoxLayout(Container, int)
, были добавлены к BoxLayout
.
Были также изменения к нескольким методам в SizeRequirements
:
calculateTiledPositions(int,SizeRequirements,SizeRequirements[],int[],int[],boolean)
calculateTiledPositions(int,SizeRequirements,SizeRequirements[],int[],int[])
calculateAlignedPositions(int,SizeRequirements,SizeRequirements[],int[],int[],boolean)
calculateAlignedPositions(int,SizeRequirements,SizeRequirements[],int[],int[])
Отчет bugtraq, который соответствует этому изменению:
С этой ошибкой, представленной в 1.4.0, кнопка значения по умолчанию не всегда следовала за фокусом. Это было фиксировано в 1.4.1.
Отчет bugtraq, который соответствует этому изменению:
AbstractButton
и JLabel
оба позволяют разработчику устанавливать символ, названный мнемосхемой, которая может использоваться, чтобы выполнить действие когда введено в клавиатуре. javadoc для этих методов утверждает, что первое нечувствительное к регистру возникновение символа украшается. В то время как это подходит большинству разработчиков, часто времена должно быть выделено, различное возникновение символа. Например: в Блокноте акселератора для Сохраняет Как, но второе украшенного. Разработчики нуждаются в способе быть в состоянии определить это.
Это решается с новым
AbstractButton.setDisplayedMnemonicIndex
и
JLabel.setDisplayedMnemonicIndex
методы. Как только Вы определили мнемосхему, через setMnemonic
или setDisplayedMnemonic
методы, можно тогда изменить символ, который выделяется через setDisplayedMnemonicIndex
метод. Там также новы
AbstractButton.getDisplayedMnemonicIndex
и JLabel.getDisplayedMnemonicIndex
методы. Наконец,
drawStringUnderlineCharAt
был добавлен к javax.swing.plaf.basic.BasicGraphicsUtils
.
Отчет bugtraq, который соответствует этому изменению:
Ранее, AbstractButton
методы
configurePropertiesFromAction(Action)
и configurePropertiesFromAction(Action, String[])
не соблюдал ACTION_COMMAND_KEY
свойство. Это теперь адресовалось. Это влияет на javadoc для configurePropertiesFromAction
методы в следующих подклассах AbstractButton
:
JButton.configurePropertiesFromAction(Action)
JMenu.configurePropertiesFromAction(Action)
JCheckBox.configurePropertiesFromAction(Action)
JRadioButton.configurePropertiesFromAction(Action)
Отчет bugtraq, который соответствует этому изменению:
Много разработчиков запросили поддержку слушателей быть уведомленной, когда выпадающее меню поля комбинированного списка раскрывается, отклоняется, или отменяется. Приложения могли использовать этих слушателей, чтобы лениво заполнить модель поля комбинированного списка с элементами.
Эта функция не была обеспечена в более ранних версиях Swing, потому что были некоторые, вероятно академические, беспокойство по поводу поддержки слушателя для функции (выпадающее меню), который не могли бы обеспечить некоторые реализации стили. Весь взгляд и чувства, которые поставляются с Java, и всеми теми, с которыми мы столкнулись, действительно использует выпадающее меню, чтобы показать все элементы поля комбинированного списка. Некоторые разработчики обратились к непереносимым взломам, чтобы получить уведомления об изменении состояния меню.
Для этого выпуска мы добавили a PopupMenuListener
к JComboBox
. Пока базовый стиль поддерживает меню элемента, этот слушатель может использоваться, чтобы выполнить действия прежде и после того, как меню поля комбинированного списка появляется. Несколько новые JComboBox
методы были обязаны поддерживать эту функцию:
public void addPopupMenuListener(PopupMenuListener l) public void removePopupMenuListener(PopupMenuListener l) public void firePopupMenuWillBecomeVisible() public void firePopupMenuWillBecomeInvisible() public void firePopupMenuCanceled()
Отчет bugtraq, который соответствует этому изменению:
JComboBox
ранее сконфигурированный средство рендеринга для каждого элемента это вывело на экран. Для больших списков это могло занять долгое время. Вместо этого разработчики, необходимые возможность определить прототип, который соответствуют все ячейки, так, чтобы прототип был только проверен однажды вместо каждой ячейки. Для этого выпуска,
getPrototypeDisplayValue
и
setPrototypeDisplayValue
были добавлены к JComboBox
.
Отчет bugtraq, который соответствует этому изменению,
Ранее, общедоступный API для JComboBox
и его делегаты UI содержали javadoc, который описал детали его реализации. Перефакторинг и устранение ошибки в течение его истории сделали это javadoc устаревший. javadoc был проверен и пересмотрен так, чтобы он описал поведение метода, а не деталей реализации. Кроме того, некоторые из javadoc для "защищенных" методов и полей, которые должны были действительно быть частными, были удалены так, чтобы переопределение или вызов этих методов не были поощрены.
Документ был изменен для JComboBox
, ComboBoxModel
, MutableComboBoxModel
, javax.swing.plaf.basic.BasicComboBoxUI
, javax.swing.plaf.basic.ComboPopup
, и javax.swing.plaf.basic.BasicComboPopup
.
Отчет bugtraq, который соответствует этому изменению,
Хотя Swing JFileChooser
близко напоминает Microsoft Windows общее диалоговое окно файла под стилем Windows, есть несколько недостатков, для которых мы получили жалобы. В частности руководство по эстетике Microsoft Windows упоминает следующее:
Если невозможно использовать [общее] Открытое и Сохранить Как диалоговые окна, следует включить следующие функции в свое открытое и сохранить диалоговые окна, чтобы гарантировать, что они являются непротиворечивыми с оболочкой, аксессуарами Windows, и другими приложениями:
Первые четыре точки не возможны в Swing без дополнительной поддержки API от AWT. Общее диалоговое окно файла AWT является также в настоящий момент недопустимым решением по следующим причинам:
Новая функциональность выполняется, добавляя следующие открытые методы для javax.swing.filechooser.FileSystemView
class, обеспечивая файл и информацию о каталоге вне контекста File
class:
public boolean isTraversable(File f) public String getSystemDisplayName(File f) public String getSystemTypeDescription public Icon getSystemIcon(File f) public boolean isParent(File folder, File file) public File getChild(File parent, String filename) public boolean isFileSystem(File f) public boolean isFileSystemRoot(File dir) public boolean isDrive(File dir) public boolean isFloppyDrive(File dir) public boolean isComputerNode(File dir) public File createFileSystemRoot(File f) public File[] getRoots()
isTraversable
метод был удален из javax.swing.plaf.basic.BasicFileChooserUI.BasicFileView
так, чтобы реализация суперкласса использовалась.
createListSelectionListener
был добавлен к javax.swing.plaf.metal.MetalFileChooserUI
.
Кроме того, javax.swing.plaf.basic.BasicDirectoryModel
имеет следующие изменения:
public void intervalAdded(ListDataEvent e) public void intervalRemoved(ListDataEvent e) public void renameFile(File oldFile, File newFile)
Отчет bugtraq, который соответствует этому изменению,
Смотрите и чувства нуждаются в возможности определить текст, текст подсказки, и мнемосхему для кнопки, используемой, чтобы открыть каталог в JFileChooser
.
Чтобы поддерживать это, несколько констант и методов были добавлены к plaf.basic.BasicFileChooserUI
:
protected int directoryOpenButtonMnemonic = 0; protected String directoryOpenButtonText = null protected String directoryOpenButtonToolTipText = null protected boolean isDirectorySelected() protected void setDirectorySelected(boolean b) protected File getDirectory() protected void setDirectory(File f)
Отчет bugtraq, который соответствует этому изменению,
Многократный выбор файла был добавлен к JFileChooser
в этих 1.4 выпусках, но javadoc для
setMultiSelectionEnabled
не был обновлен до этих 1.4.1 выпусков.
Отчет bugtraq, который соответствует этому изменению,
Ранее, title внутренней рамки не был бы отсечен, если бы это было слишком длинно. Это привело бы к отображению title по частям значков, также никакая визуальная обратная связь пользователю, что title был отсечен. Решить это,
BasicInternalFrameTitlePane.getTitle
был добавлен.
Отчет bugtraq, который соответствует этому изменению:
Чтобы реализовать это правильно, мы должны были создать class, com.sun.java.swing.plaf.windows.WindowsInternalFrameTitlePane
, который расширялся
javax.swing.plaf.basic.BasicInternalFrameTitlePane
, но переопределял подпрограмму краски, чтобы представить градиент когда приспособлено. Лучший способ получить повторное использование кода состоял в том, чтобы вспыхнуть часть метода краски, который красит только фон и переопределение только этим в WindowsInternalFrameTitlePane
. Метод
paintTitleBackground
был добавлен к javax.swing.plaf.basic.BasicInternalFrameTitlePane
.
Отчет bugtraq, который соответствует этому изменению:
В предыдущих выпусках это не было возможно для ImageView
( View
ответственный за рендеринг изображений в a JEditorPane
) показать текст подсказки, потому что не было никакого пути к a View
влиять на текст подсказки, который выводится на экран для a JTextComponent
. В этом выпуске, если JTextComponent
не имеет подсказки, тогда представление под мышью просят обеспечить тот. Если это View
соответствует элементу HTML с атрибутом ALT, тогда текст подсказки является значением того атрибута.
Позволять View
s, чтобы влиять на текст подсказки, много методов были необходимы.
getToolTipText
был добавлен к javax.swing.plaf.TextUI
так, чтобы было возможно получить текст подсказки для определенного расположения. JTextComponent
's
getToolTipText
метод тогда вперед к TextUI
, принятие подсказки не было установлено на JTextComponent
.
getToolTipText
был также добавлен к javax.swing.text.View
. Реализация по умолчанию View.getToolTipText
передаст запрос к View
's дочерний элемент в данном расположении. Облегчить определять дочерний элемент в определенном расположении,
getViewIndex
был добавлен к View
.
View
реализация вызывает getViewIndex
и затем getToolTipText
на дочернем элементе View
. ImageView
тогда переопределения
getToolTipText
и возвращает значение из атрибута ALT AttributeSet
.
Отчет bugtraq, который соответствует этому изменению:
Пакет частный class javax.swing.text.html.ImageView
теперь общедоступно так, чтобы это могло быть расширено.
Отчет bugtraq, который соответствует этому изменению:
Пакет HTML представляет способ для разработчиков определить, когда мышь отодвигается ссылка через HyperlinkEvent
и HyperlinkListener
классы. Часто разработчики времен нуждаются в способе извлечь информацию из документа когда HyperlinkListener
уведомляется. Не было ранее никакого способа для разработчика определить позицию в документе a HyperlinkEvent
представляет. Исправить это конструктор
HyperlinkEvent(Object, EventType, URL, String, Element)
и метод
getSourceElement
были добавлены к HyperlinkEvent
.
HTMLFrameHyperlinkEvent
расширяется HyperlinkEvent
, который уже определяет метод
getSourceElement
. Так как суперкласс теперь определяет этот метод, getSourceElement
javadoc был удален из HTMLFrameHyperlinkEvent
(метод теперь наследован):
Отчет bugtraq, который соответствует этому изменению:
Семантика синтаксического анализатора HTML ( javax.swing.text.html.parser.Parser
) немного изменили на лучшее соответствие тот из браузера (NetscapeTM и Internet Explorer). В то время как никакой API не был изменен, те, которые используют синтаксический анализатор, могут заметить незначительные различия в создании отчетов пробела. Вот то, как вещи изменились: если strict
(переменная экземпляра javax.swing.text.html.parser.Parser
) == false
(значение по умолчанию), переменная экземпляра используется, чтобы попытаться подражать поведению Netscape и Проводника.
Проблематичные сценарии:
'<b>blah <i> <strike> foo'
который может быть обработан как:
'<b>blah <i><strike>foo'
так же как:
'<p><a href="xx"> <em>Using</em></a></p>'
который, кажется, обрабатывается как:
'<p><a href="xx"><em>Using</em></a></p>'
Когда с тегом, который повреждает поток, или запаздывающий пробел, встречаются, переменная экземпляра устанавливается в истину. С тех пор весь пробел игнорируется. Переменная экземпляра задерживается ко лжи в первый раз, когда с не пробельным символом встречаются.
Отчет bugtraq, который соответствует этому изменению:
Поддержка HTML, оказанная в J2SE™, правильно никогда не поддерживала выписывание элементов формы. Это было должно, в значительной степени, к способу, которым были смоделированы формы. Чтобы лучше соответствовать объектную модель документа (см. attributeSet
изо всех дочерних элементов символа. С этого выпуска элемент создается, чтобы представить форму, лучше соответствуя тот из файла HTML непосредственно. Это учитывает лучшее моделирование формы, так же как непротиворечивую запись формы.
Это влияет на разработчиков, которые полагались на формы, обрабатываемые свободно. Как пример, мы ранее обработали бы следующий недопустимый HTML:
<table> <form> </table> </form>
как:
<form> <table> </table> </form>
С этим выпуском мы вместо этого обрабатываем это как:
<table> <form> </form> </table>
javax.swing.text.DefaultHighlighter
Класс Теперь Final
Отчет bugtraq, который соответствует этому изменению:
До этого выпуска, статического поля
DefaultPainter
из javax.swing.text.DefaultHighlighter
не было заключительным. Это было потенциальной проблемой безопасности. Для этого выпуска это теперь Final
.
Отчет bugtraq, который соответствует этому изменению:
До этого выпуска,
PlainDocument(AbstractDocument.Content)
конструктор был защищен. Это означало, что разработчики, желающие использовать конструктора, должны были разделить на подклассы. Этот конструктор был предназначен, чтобы быть общедоступным, и теперь общедоступен в этом выпуске.
Отчет bugtraq, который соответствует этому изменению:
JEditorPane.scrollToReference
не был защищен ни на каком серьезном основании. Этот метод предназначается, чтобы быть полезным, не имея необходимость разделять на подклассы, как таковой, он был обнародован в этом выпуске.
Отчет bugtraq, который соответствует этому изменению:
Для того, чтобы эффективно получить доступ к контенту текстового документа, Document
определяет метод
getText(int, int, Segment)
. К сожалению, не было никакого пути к вызывающей стороне, чтобы определить, мог ли бы получатель эффективно удовлетворить запрос. Например, GapContent
мог эффективно реализовать запрос, пока запрос не охватывал последнее отредактированное пятно документа (разрыв). Облегчать эффективный доступ контента, методов
setPartialReturn
и isPartialReturn
были добавлены к Segment
. Текущая семантика Document.getText
все еще содержите, но для более эффективного использования вызывающие стороны должны вызвать segment.setPartialReturn(true)
и быть подготовленным возвратить часть документа за один раз.
Отчет bugtraq, который соответствует этому изменению:
Вспомогательные технологии для инвалидов требуют программируемого доступа к содержанию JEditorPane
использование API Доступности. Ранее, единственный доступ был к гипертекстовым ссылкам. Это изменение API, обеспеченное доступность для всех компонентов HTML, используя API Доступности.
javax.swing.text.html.HTMLEditorKit
теперь реализации javax.accessibility.Accessible
.
JEditorPane
теперь реализации getAccessibleContext()
.
Отчет bugtraq, который соответствует этому изменению:
Как часть replace
метод был добавлен к AbstractDocument
. Чтобы позволить этому методу вызывать
remove
и
insertString
(единственные методы, определенные в интерфейсе для того, чтобы видоизменить a Document
), ограничения, на когда writeLock
может быть вызван были ослаблены. Это позволяет replace
быть совместимым со старыми версиями AbstractDocument
то единственное переопределение remove
и insertString
.
Отчет bugtraq, который соответствует этому изменению:
До этого выпуска, если программы, которым желают, чтобы вывести на экран простое входное диалоговое окно, содержащее текстовое поле со строкой значения по умолчанию, они должны были вызвать комплекс JOptionPane.showInputDialog
метод, который требует семи параметров. Два новых метода,
showInputDialog(Object, Object)
, и
showInputDialog(Component, Object, Object)
, сделайте более удобным создать и вывести на экран простые входные диалоговые окна.
Отчет bugtraq, который соответствует этому изменению:
JOptionPane
должен был поддерживать справа налево расположение. Это было исправлением ошибки, и никакой фактический API не требовался, однако, спецификация class для JOptionPane
и javax.swing.plaf.basic.BasicOptionPane
были обновлены.
Отчет bugtraq, который соответствует этому изменению:
С выпуска 1.4.0, JOptionPane
изменяется, чтобы использовать диалоговые окна неизменяемого размера. В результате диалоговые окна выводятся на экран многими JOptionPane
методы немного изменились. Первые два изменения являются требуемыми:
С этого выпуска, показывая a JPopupMenu
причины фокусируются, чтобы передать родителю JRootPane
. Это было сделано так, чтобы JPopupMenu
s поддерживал бы обход клавиатуры focusLost
уведомление Вы проверяете временное свойство FocusEvent
и, если true
, ничего не сделайте. В ситуациях, где Вы не хотите JPopupMenu
чтобы захватить фокус, нет, к сожалению, никакого способа отключить это в текущем выпуске. В выпуске 1.4.1 решение передать фокус основано на focusability JPopupMenu
. Отнеситесь, чтобы прослушивать
Отчет bugtraq, который соответствует этому изменению:
Ранее, JPopupMenu
не поддерживал привязки клавиш. Клавиши со стрелками, мнемоника, клавиша Enter, и escape не работали с a JPopupMenu
если это не использовалось в качестве части составного компонента (как a JMenu
или a JComboBox
).
Это поведение может быть прослежено до факта это JPopupMenu
не всегда получал фокус, и не мог поэтому добраться KeyEvents
. Это было ранее не возможно для инструментариев легкого веса, таково как Swing, которое запросило фокус и указало, что изменение фокуса было временным. Новая архитектура фокуса, решенная эта проблема, и Swing, может теперь запросить временное изменение фокуса. Исправление этой ошибки потребовало создания JPopupMenu
получите фокус так, чтобы привязки клавиш могли быть обработаны. Потребители, которые ранее не ожидали изменений фокуса, должны обновить свой код, чтобы проверить временное свойство FocusEvent
s.
Отчет bugtraq, который соответствует этому изменению:
Когда новый бездисплейный режим был представлен, JPopupMenu.setVisible(true)
был реализован, чтобы бросить NullPointerException
когда вызвано в бездисплейном режиме. Это было теперь фиксировано, чтобы бросить HeadlessException
вместо этого, чтобы указать, что эта работа не может быть выполнена в бездисплейном режиме.
Отчет bugtraq, который соответствует этому изменению:
setUI
/getUI
методы не были реализованы для JPanel
, даже при том, что его стиль определяется сменным стилем (plaf). См. javax.swing.plaf.basic.BasicPanelUI.java
, например.
Новая спецификация фокуса утверждает, что запросы фокуса на компонентах, которые не показывают, перестанут работать. У этого могут быть тонкие побочные эффекты. Один такой побочный эффект состоит в том что, запрашивая фокус от a ChangeListener
связанный с a JTabbedPane
может перестать работать. Одновременно, ChangeListener
уведомляется, что компонент не в настоящий момент видим и поэтому сбои запроса фокуса в той же самой ситуации, что это, вероятно, работало при предыдущем выпуске. Если Вы сталкиваетесь с этой ситуацией с JTabbedPane
предлагается, чтобы Вы сделали компонент видимым прежде, чем запросить фокус. Другие ситуации могут потребовать разных подходов.
Отчет bugtraq, который соответствует этому изменению:
До этого изменения не было никакого пути к клиентским программам, чтобы преобразовать координатное расположение в определенную вкладку в tabbedpane. Это мешало реализовывать обработку специального мероприятия на a JTabbedPane
(как раскрытие меню по вкладке).
Метод indexAtLocation был добавлен к JTabbedPane
.
Отчет bugtraq, который соответствует этому изменению:
Области a JTabbedPane
ранее не учитывал мнемонику. Облегчить это, методы
getDisplayedMnemonicIndexAt
и
setDisplayedMnemonicIndexAt
были добавлены.
Отчет bugtraq, который соответствует этому изменению:
JTabbedPane
class является контейнером, у которого есть много методов, которые берут целое число, индексируют в качестве параметра. К сожалению, эти методы были весьма непоследовательны со своим подходом к выдаче исключений (некоторые методы, check/throw, некоторые не делают). Дополнительно, javadoc был по ошибке - он утверждал что IllegalParameterException
был брошен когда фактически ArrayIndexOutOfBoundsException
был брошен (базовым Vector
).
Любой метод, который берет индексирование, которое должно быть в допустимом диапазоне от 0 до tabCount-1 теперь документы, которые это бросает IndexOutOfBoundsException
(отметьте: базовый код продолжает бросать ArrayIndexOutOfBoundsException
по причинам совместимости).
Следующее изменение документа:
* @exception IndexOutOfBoundsException if index is out of range * (index < 0 || index >= tab count)будет применен к следующему
JTabbedPane
методы: public String getTitleAt(int index) public Icon getIconAt(int index) public Icon getDisabledIconAt(int index) public String getToolTipTextAt(int index) public Color getBackgroundAt(int index) public Color getForegroundAt(int index) public boolean isEnabledAt(int index) public Component getComponentAt(int index) public int getDisplayedMnemonicIndexAt(int index) public Rectangle getBoundsAt(int index) public void setTitleAt(int index, String title) public void setIconAt(int index, Icon icon) public void setDisabledIconAt(int index, Icon icon) public void setToolTipTextAt(int index, String toolTipText) public void setForegroundAt(int index, Color foreground) public void setBackgroundAt(int index, Color background) public void setEnabledAt(int index, boolean enabled) public void setComponentAt(int index, Component component) public void setDisplayedMnemonicIndexAt(int tabIndex, int mnemonicIndex)
Та же самая обработка исключений будет добавлена к следующим методам, которые ранее ничего не сделали:
public void setSelectedIndex(int index) public void remove(int index)
Отчет bugtraq, который соответствует этому изменению:
В JDK 1.3, moveRow
метод в DefaultTableModel
был задокументирован таким способом, в котором это ясно не определяло ли строка startIndex
или строка в endIndex
строка закончилась бы в toIndex
. Выводом из примеров кажется что startIndex
должен закончиться в toIndex
опуская строки и endIndex
должен закончиться в toIndex
когда движущиеся строки вверх.
Однако реализация
moveRow
имел ошибку так, что всякий раз, когда число перемещаемых строк было больше чем одним - строки закончатся несколько произвольных позициях и даже не были бы непрерывны после перемещения. Ошибка 4144295 отметила, что реализация даже не выполняла пример в своей спецификации: moveRow(1, 3, 5)
пример, практически оставленный вектор в следующем состоянии:
a|C|e|B|D|f|g|h|i|j|kНовая реализация делает наблюдение, что эта работа является простым вращением элементов между границами, которые могут быть вычислены от вводов.
Так как предыдущая реализация не работала, мы воспользовались возможностью, чтобы упростить определение тому где startIndex
всегда перемещается в toIndex
, со всеми другими элементами, появляющимися после toIndex
в том же самом порядке, которым они были первоначально. Отметьте, что это выполняет ту же самую работу как предыдущая реализация в единственном случае, где это работало - когда единственная строка перемещалась.
Новая реализация не выдает исключение когда endIndex
меньше чем startIndex
- это не делает ничего вместо этого удовлетворявшего подразумеваемый контракт, чтобы переместить все строки, r
, где startIndex <= r <= endIndex
.
Отчет bugtraq, который соответствует этому изменению:
Приложение Excel автоматически дает фокус базовым редакторам, когда пользователь нажимает алфавитно-цифровую клавишу. Мы получили более чем 200 голосов JDC, запрашивающих, чтобы мы предложили это поведение в JTable
. В то время как мы не можем изменить поведение значения по умолчанию по причинам назад совместимости, в этом выпуске мы добавили новое свойство, surrendersFocusOnKeystroke
, адресовать этот запрос. Новые методы
setSurrendersFocusOnKeystroke
и
getSurrendersFocusOnKeystrok
поддерживайте эту функцию. Поведение значения по умолчанию остается неизменным.
Отчет bugtraq, который соответствует этому изменению:
Методы
DefaultTableModel.addColumn(Object)
и
DefaultTableModel.addColumn(Object, Vector)
ранее не позволял null
для name
параметр - они бросили IllegalArgumentException
. Поскольку возможно установить имя столбца в null
через другие средства (использующий конструкторов, или непосредственно управляющий полем), addColumn
методы теперь также позволяют a null
значение.
Отчет bugtraq, который соответствует этому изменению:
DefaultTreeModel
теперь позволяет a null
корневой узел. Ранее, javadoc для TreeModel
определенный это a null
корень был допустим, но DefaultTreeModel
не позволил бы тот. DefaultTreeModel
теперь позволяет установку a null
корень, так же как a null
корень в конструкторе. javadoc для
setRoot
был пересмотрен, чтобы отразить изменение.
Отчет bugtraq, который соответствует этому изменению:
Часто пользователи времен хотят переместиться к ячейкам в a JTree
использование алфавитно-цифровых ключей. Облегчить это, названный метод
getNextMatch
был добавлен к JTree
. BasicTreeUI
установки a KeyListener
это вызывает этот метод, поскольку ключи вводятся на клавиатуре.
Отчет bugtraq, который соответствует этому изменению:
Разработчики часто полагаются toString
метод для полезной отладочной информации. К сожалению, ListDataEvent
's toString
метод действительно не обеспечивал ничто полезное. Для этого выпуска это было изменено, чтобы возвратить что-то полезное.
Отчет bugtraq, который соответствует этому изменению:
Часто пользователи времен хотят переместиться к ячейкам в a JList
использование алфавитно-цифровых ключей. Облегчить это,
getNextMatch
был добавлен к JList
. BasicListUI
тогда установит a KeyListener
это вызовет этот метод, поскольку ключи вводятся, чтобы обновить выбор.
Отчет bugtraq, который соответствует этому изменению:
JList
ранее только позволенная разметка его ячеек вертикально, который является:
1 2 3 4
Многочисленные пользователи попросили возможность разметить список горизонтально, что-то как:
1 3 2 4или
1 2 3 4
Чтобы достигнуть этого, три константы добавляются к JList
, VERTICAL
, VERTICAL_WRAP
, и HORIZONTAL_WRAP
. Методы getLayoutOrientation
и setLayoutOrientation
также добавляются к JList
. javadoc для JList
методы
getScrollableTracksViewportHeight
,
getScrollableTracksViewportWidth
,
getScrollableBlockIncrement
, и
getPreferredScrollableViewportSize
обновляются соответственно. Аналогично, javadoc для
getPreferredSize
в javax.swing.plaf.basic.BasicListUI
обновляется.
Две настройки по умолчанию изменились в Металлическом стили:
JLabel
изменился от темно-синего до черного.DefaultListCellRenderer
изменился от нормального до полужирного.Отчет bugtraq, который соответствует этому изменению:
Вызывая этот метод значение по умолчанию PreviewPanel не был удален из colorChooser, хотя новая панель была добавлена. Это привело к странным артефактам. Это было фиксировано в выпуске 1.4.2.
Отчет bugtraq, который соответствует этому изменению:
Эта ошибка когда встречено в 1.4.0, вызвал мертвую блокировку, которая подвесит все приложение. Это было фиксировано в 1.4.1.
С выпуска 1.4.1,
setDefaultCloseOperation
метод в JFrame
май теперь бросает SecurityException
.
Отчеты bugtraq, которые соответствуют этому изменению:
До этого выпуска, DefaultMetalTheme
проигнорированный информация о размере шрифта от рабочего стола Windows. С выпуска 1.4.1, DefaultMetalTheme
может использовать размеры шрифта, определенные в рабочем столе Windows. Это может быть отключено, используя системное свойство swing.useSystemFontSettings
. Дополнительная часть этой ошибки - то, что наш стиль Windows поднимал неправильные шрифты для горстки компонентов; это было фиксировано.
Отчет bugtraq, который соответствует этому изменению:
На Microsoft Windows, с WindowsLookAndFeel
, в определенных локалях мы только соблюдаем размер шрифта от рабочего стола. Это адресовалось в 1.4.1.
Отчет bugtraq, который соответствует этому изменению:
Некоторые реализации стили могут проигнорировать определенные свойства, которые влияют на стиль. С этим выпуском документация для определенных методов была изменена, чтобы указать, что эти свойства могут быть проигнорированы некоторым взглядом и чувствами. Кроме того, спецификация class для UIManager
и документация для javax.swing.plaf.metal
пакет был изменен, чтобы определить, что стиль Java является стилем значения по умолчанию. Эта модификация влияет только на документацию.
Методы, на которые влияют:
javax.swing.AbstractButton
javax.swing.JButton
javax.swing.JCheckBox
javax.swing.JColorChooser
javax.swing.JComboBox
javax.swing.JFileChooser
javax.swing.JInternalFrame
javax.swing.JList
javax.swing.JPopupMenu
javax.swing.JProgressBar
javax.swing.JSplitPane
javax.swing.JTable
javax.swing.text.JTextComponent
javax.swing.JToolBar
javax.swing.JTree
Отчет bugtraq, который соответствует этому изменению:
SwingConstants
определяет константы, которые используются всюду по Swing. Общая работа UI должна определить местоположение следующего/предыдущего элемента в последовательности; как таковой, SwingConstants
теперь определяет константы для NEXT
и PREVIOUS
.
Отчет bugtraq, который соответствует этому изменению:
У Swing есть тщательно продуманная инфраструктура, чтобы поддерживать связывающиеся действия с определенными нажатиями клавиш. Это означает, что, когда пользователь вводит символ, действие выполняется. Обработка этих событий инициирована изнутри
JComponent.processKeyEvent
(processKeyEvent
переопределяется от java.awt.Component
). Поскольку обработка этих действий происходит в пределах JComponent
, не было ранее никакого способа для разработчиков обработать привязку изнутри не -JComponent
подклассы, которые получают фокус. Облегчить это, a
processKeyBindings
метод был добавлен к SwingUtilities
.
Отчет bugtraq, который соответствует этому изменению:
Отметьте: из-за горстки ошибок в звуковом пакете мы принимаем значение по умолчанию к игре никаких звуков. Если требуется включить звуки, можно сделать следующее:
UIManager.put("AuditoryCues.playList", UIManager.get("AuditoryCues.allAuditoryCues"));
Ранее, компоненты Swing не обеспечивали ту же самую слуховую обратную связь как собственные компоненты на многих платформах. MALF2, ряд модификаций к PLAFs Swing, прежде всего предназначается для использования в качестве неречевого пользовательского механизма обратной связи аудио только для вывода. Проект MALF2 важен с точки зрения Swing/JFC и цели платформы Java трудной интеграции пользовательского интерфейса с базовой платформой. Проект MALF2 гарантирует, что опыт пользователя с собственным приложением и приложением Swing/JFC идентичен относительно слуховой пользовательской обратной связи.
Реализация центрируется вокруг добавляющего API к BasicLookAndFeel
поддерживать загрузку ActionMap
содержа Action
s та игра звуки. Различный BasicComponentUI
реализации тогда вызывают actionPerformed
на Action
в подходящее время, чтобы играть звук. Например, BasicMenuItemUI
использование
doClick
выполнять действие. В то время как BasicLookAndFeel
игры звучат как использование API Звука Java, подклассы могут использовать альтернативный метод. Например, WindowsLookAndFeel
отображает Строки на Runnable
s посредством
Toolkit.getDefaultToolkit().getDesktopProperty()
, предоставлять интеграции звуки, обеспеченные Windows.
ActionMap
через содержа звуки можно получить доступ
BasicLookAndFeel.getAudioActionMap
. Когда getAudioActionMap
сначала вызывается, это выполняет следующее:
auditoryCues.cueList
( Object[]
) используется, чтобы определить список звуков, чтобы загрузиться.createAudioAction
получить Action
ответственный за игру звука.Object
переданный в
BasicLookAndFeel.createAudioAction
используется, чтобы искать путь к звуковому файлу от таблицы значений по умолчанию, которая может быть загружена Звуком Java.BasicComponentUI
s классы хочет играть звук, он вызывает
BasicLookAndFeel.playSound
, передача в Action
.BasicLookAndFeel.playSound
вызывает actionPerformed
на Action
если имя Action
содержится в записи значений по умолчанию AuditoryCues.playList
.Эта архитектура позволяет разработчику многочисленные способы настроить звуки, которые играются:
JComponent
может управляться, изменяясь Action
в ActionMap
связанный с JComponent
, eg: ActionMap map = menuItem.getActionMap(); map.put("MenuItem.commandSound", differentActionToPlaySound);
Component
s определенного типа может быть изменен, управляя таблицей значений по умолчанию, eg: UIManager.put("MenuItem.commandSound", "pathToNewSoundFild");
BasicLookAndFeel
методы, чтобы загрузить звуки альтернативным способом, или возможно играть звуки по-другому.Альтернативно, набором звуков, которые будут играться, можно управлять посредством записи значений по умолчанию AuditoryCues.playList
. Это Object
массив содержит ключи в таблице значений по умолчанию, указывающей который звуки играть. MetalLookAndFeel
определяет это, чтобы быть:
new Object[] {"OptionPane.errorSound",
"OptionPane.informationSound",
"OptionPane.questionSound",
"OptionPane.warningSound" }
Это имеет эффект включения только звуков это JOptionPane
поддерживает. Отчет bugtraq, который соответствует этому изменению:
Новая архитектура фокуса, представленная через RFE Component
методы requestFocus(boolean)
или
requestFocusInWindow(boolean)
. Эти два метода защищаются, поскольку они не предназначаются для общего использования, но только для конструкторов легких инструментариев, таких как Swing. Swing проектируется таким способом, которые кодируют в различных пакетах, должен временно запросить фокус; как таковой, родительский class всех Компонентов Swing, JComponent
, потребности представить requestFocus(boolean)
и
requestFocusInWindow
как общественность.
Отчет bugtraq, который соответствует этому изменению:
С объемом компонентного уделения внимания Swing их ComponentOrientation
свойство, мы теперь нуждаемся в двух функциях, чтобы облегчить управлять ComponentOrientation
настройки всей иерархии компонентов. Должно быть легко установить все иерархии компонентов к непротиворечивому ComponentOrientation
установка использования нового SwingUtilities
метод applyComponentOrientation(Component c, ComponentOrientation o)
.
Отчет bugtraq, который соответствует этому изменению:
Как часть обновления стили Windows, метод был добавлен к LookAndFeel
,
getDesktopPropertyValue
, облегчить настольные свойства доступа.
Это было фактически добавлено как часть обновления к JProgressBar
поддерживать неопределенное состояние. Отчет bugtraq, который соответствует этому изменению:
Новый метод
calculateInnerArea(Component, Rectangle)
был добавлен к SwingUtilities
.
Отчет bugtraq, который соответствует этому изменению:
Мыши колеса, с колесиком прокрутки как средняя кнопка мыши, все более и более популярны. Это предложение предусматривает встроенную поддержку Java прокрутки через колесо мыши, так же как нового слушателя события колеса, таким образом, разработчики могут настроить поведение колеса мыши.
Новый class, MouseWheelListener
, и новый интерфейс, MouseWheelEvent
, были добавлены. Константа, MOUSE_WHEEL_EVENT_MASK
был добавлен к AWTEvent
. AWTEventMulticaster
имеет три новых метода:
mouseWheelMoved
,
add
, и
remove
. Component
имеет два новых метода:
addMouseWheelListener
, и
removeMouseWheelListener
. ScrollPane
также имеет два новых метода:
setWheelScrollingEnabled
и isWheelScrollingEnabled
. Наконец, Robot
имеет новый метод mouseWheel
.
Отчет bugtraq, который соответствует этому изменению:
Swing поддерживает опцию регистрации привязок клавиш на JComponent
s. В предыдущих выпусках это было необходимо для высокоуровневых компонентов Swing ( JFrame
, JDialog
, и JApplet
) переопределять processKeyEvent
(определенный в java.awt.Component
) активировать эту привязку, если фокус был когда-либо на одном из этих высокоуровневых компонентов. С добавлением java.awt.KeyEventPostProcessor
и Swing, использующий в своих интересах это (
Отчет bugtraq, который соответствует этому изменению:
Хотя бездисплейный режим был добавлен к этому выпуску, два JWindow
конструкторы не указывали на это HeadlessException
может быть брошен. Это было фиксировано в документе для
Window(Window, GraphicsConfiguration)
и
JWindow(GraphicsConfiguration)
.
Отчет bugtraq, который соответствует этому изменению:
Мы недавно нашли входную ошибку верификатора, которая вызывала проблемы для некоторых из наших пользователей. Под 1.4, shouldYieldFocus
метод не позволяет побочные эффекты, такие как раскрытие OptionPane
.
У нас действительно есть следующее обходное решение:
public boolean shouldYieldFocus(JComponent input) { if (verify(input)) { return true; } // According to the documentation, should yield focus is allowed to cause // side effects. So temporarily remove the input verifier on the text // field. input.setInputVerifier(null); System.out.println("Removed input verifier"); // Pop up the message dialog. String message = "Roll over the 'JButton1' with mouse pointer " + "after closing this dialog.\nIt sometimes behaves correctly " + "for the first time\n but repeating action brings incorrect " + "behaviour of button."; JOptionPane.showMessageDialog(null, message , "invalid value", JOptionPane.WARNING_MESSAGE); System.out.println("Showed message."); // Reinstall the input verifier. input.setInputVerifier(this); System.out.println("Reinstalled input verifier"); // Tell whomever called us that we don't want to yield focus. return false; }
Отчет bugtraq, который соответствует этому изменению:
Классы в javax.swing.plaf.multi
используются, чтобы мультиплексировать между многократным взглядом и чувствами. Это обычно используется вспомогательными технологиями, которые используют вспомогательный стиль, чтобы обеспечить дополнительную информацию, такую как слуховая информация. Нет в настоящий момент никакой реализации во много для RootPaneUI
который делает использование вспомогательного стили проблематичным.
Новый class javax.swing.plaf.multi.MultiRootPaneUI
был добавлен.
Отчет bugtraq, который соответствует этому изменению:
AWT недавно обеспеченный API так, что Window
s может быть неукрашен. Таким образом, когда неукрашено истина, Window
не будет представлять виджетов для того, чтобы закрыть, переместить, или изменить размеры. Также, Swing позволил стили представить художественные оформления для Windows.
Эта функция прежде всего поддерживается в javax.swing.JRootPane
, но мы поощряем разработчиков использовать переключатели, обеспеченные в javax.swing.JFrame
и javax.swing.JDialog
.
Следующие изменения были произведены в JRootPane
:
public static final int NONE; public static final int FRAME; public static final int PLAIN_DIALOG; public static final int INFORMATION_DIALOG; public static final int ERROR_DIALOG; public static final int COLOR_CHOOSER_DIALOG; public static final int FILE_CHOOSER_DIALOG; public static final int QUESTION_DIALOG; public static final int WARNING_DIALOG; public void setWindowDecorationStyle(int style) public int getWindowDecorationStyle()
Не весь взгляд и чувства поддерживают стиль художественного оформления окна; метод
getSupportsWindowDecorations
был добавлен к javax.swing.LookAndFeel
обеспечить путь к взгляду и чувствам, чтобы указать, поддерживают ли они это поведение.
Методы,
isDefaultLookAndFeelDecorated()
, и setDefaultLookAndFeelDecorated были добавлены к JFrame
.
Методы,
isDefaultLookAndFeelDecorated()
, и setDefaultLookAndFeelDecorated были также добавлены к JDialog
.
Отчет bugtraq, который соответствует этому изменению:
JScrollBar
ранее не переопределял
setUI
метод. Для этого выпуска это было изменено, чтобы соответствовать этому поведению.
Это было реализовано как часть поддержки колеса мыши. Этот раздел только документирует изменения к JScrollPane
, поскольку детали других изменений обращаются к этому разделу. Отчет bugtraq, который соответствует этому изменению:
Методы
isWheelScrollingEnabled
и
setWheelScrollingEnabled
были добавлены к JScrollPane
.
Новый защищенный внутренний class,
MouseWheelHandler
, был добавлен к javax.swing.plaf.basic.BasicScrollPaneUI
. Соответствующий метод в этом внутреннем class
mouseWheelMoved
. Наконец, новый метод
createMouseWheelListener
был добавлен к BasicScrollPaneUI
.
Отчет bugtraq, который соответствует этому изменению:
Java 2-D команда реализовал новое VolatileImage
механизм, у которого есть возможность использовать в своих интересах аппаратное ускорение для Image
графика и операции копирования битового массива на экран.
По умолчанию Swing использует двойную буферизацию, чтобы нарисовать содержание компонентов GUI (представляя во внеэкранном изображении и затем копируя то изображение в экран) и был изменен, чтобы использовать в своих интересах новое VolatileImage
поддержка.
Двойной буфер, что использование Swing, чтобы сделать рисование получается из RepaintManager
при использовании метода
getOffscreenBuffer
. С тех пор a VolatileImage
объект требует специальной обработки (чтобы протестировать на условия отказа), мы не могли просто изменить этот метод, чтобы возвратить a VolatileImage
с тех пор может быть существующий код там, который вызывает этот метод и не реализует эту дополнительную обработку. Поэтому, мы добавили метод,
getVolatileOffscreenBuffer
, к javax.swing.RepaintManager
определенно возвратить a VolatileImage
объект.
Отчет bugtraq, который соответствует этому изменению:
Этот выпуск представляет нового менеджера по расположению, SpringLayout
.
См.SpringLayout
.