JAVA SWING and AWT

JAVA AWT

Contiene todas las clases para crear interfaces de usuario y para el pintado de gráficos e imágenes.
Un objeto de interfaz de usuario como un botón de barra de desplazamiento o de una que se llama, en terminología de AWT, un componente. La clase Component es la raíz de todos los componentes AWT. Véase el componente para obtener una descripción detallada de las propiedades que comparten todos los componentes de AWT.
Algunos componentes hechos de fuego cuando un usuario interactúa con los componentes. La clase AWTEvent y sus subclases se utilizan para representar los eventos que pueden disparar los componentes AWT. Ver AWTEvent para obtener una descripción del modelo de eventos AWT.
Un contenedor es un componente que puede contener componentes y otros recipientes. Un recipiente Con también puede tener un controlador de distribución que controla la colocación visual de los componentes en el contenedor. El paquete AWT contiene varias clases de gestión de diseño y una interfaz para la construcción de su propio gestor de diseño. Ver Contenedores y LayoutManager para más información.
Resumen de interfaz.
ActiveEvent Una interfaz para los eventos que saben cómo expedición.
Adjustable La interfaz para los objetos que tienen un valor numérico ajustable contenida dentro de un rango limitado de valores.
Composite La interfaz de Composite, junto con CompositeContext, define los métodos para componer un empate primitivo con el área de gráficos subyacente.
CompositeContext La interfaz de CompositeContext define el entorno encapsulado y optimizado para una operación de composición.
ItemSelectable La interfaz de los objetos que contienen un conjunto de elementos para los que cero o más se pueden seleccionar.
KeyEventDispatcher Un KeyEventDispatcher coopera con el KeyboardFocusManager actual en la selección y envío de todas las KeyEvents.
KeyEventPostProcessor KeyEventPostProcessor coopera con el KeyboardFocusManager actual en la resolución final de todas las KeyEvents no consumidos.
LayoutManager Define la interfaz para las clases que saben cómo diseñar contenedores.
LayoutManager2 Define una interfaz para las clases que saben como contenedores de diseño basado en un objeto de diseño de las restricciones.
MenuContainer la superclase de todos los contenedores de menú relacionados.
Esta interfaz de pintura Paint define cómo los patrones de color se pueden generar para las operaciones de Graphics2D.
PaintContext La interfaz PaintContext define el entorno encapsulado y optimizado para generar patrones de color en el espacio del dispositivo para las operaciones de relleno y de trazo en un Graphics2D.
PrintGraphics una clase abstracta que proporciona un contexto de impresión de gráficos de una página.Shape La interfaz Shape proporciona definiciones de los objetos que representan algún tipo de forma geométrica.
Stroke La interfaz Stroke  permite a un objeto Graphics2D para obtener una forma que es el esquema de decoración, o la representación estilística del esquema, de la forma especificada.
Transparency La interfaz de Transparency  define los modos de transparencia comunes para la implementación de clases.
Resumen de clase
AlphaCompositeLa clase AlphaComposite implementa las reglas básicas de composición de alfa para la combinación de colores de origen y de destino para lograr la mezcla y efectos de transparencia con gráficos e imágenes.
AWTEvent La clase de evento raíz para todos los eventos de AWT.
GraphicsDevice
GraphicsEnvironment
GridBagConstraints
GridBagLayout
GridBagLayoutInfo
GridLayout
Image
ImageCapabilities
Insets
JobAttributes
JobAttributes.DefaultSelectionType
JobAttributes.DestinationType
JobAttributes.DialogType
JobAttributes.MultipleDocumentHandlingType
JobAttributes.SidesType
KeyboardFocusManager
Label LinearGradientPaint
List MediaTracker
Menu
MenuBar
MenuComponent
MenuItem
MenuShortcut
MouseInfo
MultipleGradientPaint
PageAttributes
PageAttributes.ColorType
PageAttributes.MediaType
PageAttributes.OrientationRequestedType
PageAttributes.OriginType
PageAttributes.PrintQualityType
Panel
Point
PointerInfo
Polygon
PopupMenu
PrintJob
RadialGradientPaint
Rectangle
RenderingHints
RenderingHints.Key
Robot
Scrollbar
ScrollPane
ScrollPaneAdjustable
SplashScreen
SystemColor
SystemTray
TextArea
TextComponent
TextField
TexturePaint
Toolkit
TrayIcon
Window

enum Resumen
Component.BaselineResizeBehavior
Desktop.Action
Dialog.ModalExclusionType
Dialog.ModalityType
MultipleGradientPaint.ColorSpaceType
MultipleGradientPaint.CycleMethod
TrayIcon.MessageType

Excepción Resumen
 AWTException Señales de que una excepción Window Toolkit Absract ha ocurrido.
FontFormatException Lanzada por CreateFont método en la clase de fuente para indicar que la fuente especificada es malo.
HeadlessException Se produce cuando el código que depende de un teclado, la pantalla o el ratón que se llama en un ambiente que no es compatible con un teclado, la pantalla o el ratón.
IllegalComponentStateException Indica que un componente AWT no se encuentra en un estado apropiado para la operación solicitada.

Resumen de Error

AWTError  Se produce cuando un grave error de Abstract Window Toolkit se ha producido.



JAVA SWING

Package javax.swing

Proporciona un conjunto de "ligera" (todo el lenguaje Java) componentes que, en la medida de lo posible, funcionan de la misma en todas las plataformas. Para la guía de un programador a la utilización de estos componentes, consulte Creación de una interfaz gráfica de usuario con JFC / Swing, un sendero en el Tutorial de Java. Para otros recursos, consulte la documentación relacionada.

Política Threading de Swing
En Swing general, no es seguro para subprocesos. Todos los componentes Swing y clases relacionadas, a menos que se documenta, se debe acceder en el hilo de despacho de eventos.
Las aplicaciones típicas Swing realizar el procesamiento en respuesta a un evento generado a partir de un movimiento del usuario. Por ejemplo, hacer clic en un JButton notifica a todos los ActionListeners añadido a la JButton. Como todos los eventos generados a partir de un movimiento del usuario se envían en el hilo de despacho de eventos, la mayoría de los desarrolladores no se ven afectados por la restricción.

Cuando el impacto se encuentra, sin embargo, es en la construcción y que muestra una aplicación Swing. Las llamadas al método principal de una aplicación, o los métodos de Applet, no se utilizan en el hilo de despacho de eventos. Como tal, se debe tener cuidado para transferir el control a las conversaciones de despacho de eventos en la construcción y que muestra una aplicación o applet. La mejor forma de transferir el control y empezar a trabajar con Swing es usar invokeLater. Los horarios método invokeLater un Ejecutable que se procesa en el hilo de despacho de eventos. Los dos ejemplos siguientes funcionan igual de bien para la transferencia de control y puesta en marcha de una aplicación Swing:
public class MyApp implements Runnable {
    public void run() {
        // Invoked on the event dispatching thread.
        // Construct and show GUI.
    }

    public static void main(String[] args) {
        SwingUtilities.invokeLater(new MyApp(args));
    }
}

O
public class MyApp {
    MyApp(String[] args) {
        // Invoked on the event dispatching thread. Do any initialization
        // here.
    }

    public void show() {
        // Show the UI.
    }

    public static void main(final String[] args) {
        // Schedule a job for the event-dispatching thread:
        // creating and showing this application's GUI.
        SwingUtilities.invokeLater(new Runnable() {
            public void run() {
                new MyApp(args).show();
            }
        });
    }
}
Esta restricción también se aplica a los modelos adjuntos a los componentes Swing. Por ejemplo, si un TableModel está unido a un JTable, el TableModel sólo debe ser modificado en el hilo de eventos de despacho. Si se modifica el modelo en un subproceso independiente se corre el riesgo de las excepciones y la corrupción de visualización posible.
Como todos los eventos se entregan en el thread de despacho de eventos, se debe tener cuidado en el procesamiento de eventos. En particular, una tarea de larga duración, como la red io o el procesamiento intensivo de computación, realizado en el despacho de eventos bloques Enhebrar el hilo de despacho de eventos del despacho de cualquier otro evento. Mientras que el hilo de despacho de eventos se bloquea la aplicación es completamente insensible a la entrada del usuario. Consulte SwingWorker la mejor forma de hacerlo dicho tratamiento cuando se trabaja con el swing.

Resumen de la Interface
Action
BoundedRangeModel
 ButtonModel
CellEditor
ComboBoxEditor
ComboBoxModel
DesktopManager
Icon
JComboBox.KeySelectionManager
ListCellRenderer
ListModel
ListSelectionModel
MenuElement
MutableComboBoxModel
Renderer
RootPaneContainer
Scrollable
ScrollPaneConstants
SingleSelectionModel
SpinnerModel
SwingConstants
UIDefaults.ActiveValue
UIDefaults.LazyValue
WindowConstants

Resumen de las Clases

AbstractAction
AbstractButton AbstractCellEditor AbstractListModel AbstractSpinnerModel ActionMap BorderFactory Box Box.Filler BoxLayout ButtonGroup CellRendererPane ComponentInputMap DebugGraphics DefaultBoundedRangeModel DefaultButtonModel DefaultCellEditor DefaultComboBoxModel DefaultDesktopManager DefaultFocusManager DefaultListCellRenderer DefaultListCellRenderer.UIResource DefaultListModel DefaultListSelectionModel DefaultRowSorter DefaultRowSorter.ModelWrapper DefaultSingleSelectionModel FocusManager GrayFilter GroupLayout ImageIcon InputMap InputVerifier InternalFrameFocusTraversalPolicy JApplet JButton JCheckBox JCheckBoxMenuItem JColorChooser JComboBox JComponent JDesktopPane JDialog JEditorPane JFileChooser JFormattedTextField JFormattedTextField.AbstractFormatter JFormattedTextField.AbstractFormatterFactory JFrame JInternalFrame JInternalFrame.JDesktopIcon JLabel JLayeredPane JList JList.DropLocation JMenu JMenuBar JMenuItem JOptionPane JPanel JPasswordField JPopupMenu JPopupMenu.Separator JProgressBar JRadioButton JRadioButtonMenuItem JRootPane JScrollBar JScrollPane JSeparator JSlider JSpinner JSpinner.DateEditor JSpinner.DefaultEditor JSpinner.ListEditor JSpinner.NumberEditor JSplitPane JTabbedPane JTable JTable.DropLocation JTextArea JTextField JTextPane JToggleButton JToggleButton.ToggleButtonModel JToolBar JToolBar.Separator JToolTip JTree JTree.DropLocation JTree.DynamicUtilTreeNode JTree.EmptySelectionModel JViewport JWindow KeyStroke LayoutFocusTraversalPolicy LayoutStyle LookAndFeel MenuSelectionManager OverlayLayout Popup PopupFactory ProgressMonitor ProgressMonitorInputStream RepaintManager RowFilter RowFilter.Entry RowSorter RowSorter.SortKey ScrollPaneLayout ScrollPaneLayout.UIResource SizeRequirements SizeSequence SortingFocusTraversalPolicy SpinnerDateModel SpinnerListModel SpinnerNumberModel Spring SpringLayout SpringLayout.Constraints SwingUtilities SwingWorker Timer ToolTipManager TransferHandler TransferHandler.DropLocation TransferHandler.TransferSupport UIDefaults UIDefaults.LazyInputMap UIDefaults.ProxyLazyValue UIManager UIManager.LookAndFeelInfo ViewportLayout

Resumen de Enum
DropMode GroupLayout.Alignment JTable.PrintMode LayoutStyle.ComponentPlacement RowFilter.ComparisonType SortOrder SwingWorker.StateValue


Resumen de Excepciones
UnsupportedLookAndFeelException Una excepción que indica la apariencia y la sensación solicitado clases de gestión no están presentes en el sistema del usuario.








INFORMACION ADICIONAL

El Subsistema de enfoque AWT
Antes de Java 2 Standard Edition, JDK 1.4, el subsistema de atención AWT era insuficiente. Se sufrió de diseño más importantes y los problemas de la API, así como más de un centenar de bugs abiertos. Muchos de estos errores fueron causados ​​por las inconsistencias de la plataforma, o incompatibilidades entre el sistema de enfoque nativo para los pesos pesados ​​y el sistema de enfoque de Java para los pesos ligeros.
El peor problema de un solo foco en la aplicación AWT fue la incapacidad para consultar el componente centrado en la actualidad. No sólo no hubo API para este tipo de consulta, sino que también, gracias a una arquitectura insuficiente, dicha información no se mantuvo incluso en el código. Casi tan mala fue la incapacidad de los niños de peso ligero de una ventana (no es un marco o cuadro de diálogo a) para recibir la entrada del teclado. Este problema existe porque nunca recibió los eventos de Windows WINDOW_ACTIVATED y por lo tanto nunca podría ser activado, y sólo de Windows activos pueden contener componentes específicos.
  1. El "enfoque de dueño" - el componente que normalmente recibe la entrada del teclado.
  2. El "dueño foco permanente" - el último componente para recibir atención de forma permanente. El "dueño de foco" y el "dueño foco permanente" son equivalentes a menos que un cambio de foco temporal vigente en la actualidad. En tal situación, el "dueño foco permanente" volverá a ser el "dueño de enfoque" cuando el cambio de foco temporal termina.
  3. La "ventana enfocada" - la ventana que contiene el "dueño de enfoque".
  4. La "ventana activa" - en el marco u diálogo que sea la "ventana enfocada", o el primer fotograma o cuadro de diálogo que es el dueño de la "ventana enfocada".
  5. "Enfoque transversal" - la capacidad del usuario para cambiar el "dueño de enfoque" sin mover el cursor. Típicamente, esto se hace utilizando el teclado (por ejemplo, mediante el uso de la tecla TAB), o un dispositivo equivalente en un entorno accesible. El código de cliente también puede iniciar el recorrido programación. Normal enfoque transversal puede ser "adelante" a la "siguiente" de componentes, o "hacia atrás" a la "anterior" de componentes.
  6. "Enfoque del ciclo de recorrido" - una parte de la jerarquía de componentes, de tal manera que lo normal enfoque transversal "hacia adelante" (o "hacia atrás") recorrerá a través de todos los componentes en el ciclo de foco, pero ningún otro componente. Este ciclo ofrece una asignación de un componente de arbitrariedad en el ciclo de su "siguiente" (avance de recorrido) y "anterior" Componentes (hacia atrás de recorrido).
  7. "Enfoque de la raíz del ciclo" - Container que es la raíz de la jerarquía de componentes para un determinado "enfoque de ciclo de recorrido". Cuando el "dueño de enfoque" es un componente dentro de un ciclo particular, normal hacia adelante y atrás se centran el recorrido no se puede mover el "dueño de enfoque" sobre la raíz del ciclo se centran en la jerarquía de componentes. En su lugar, dos operaciones adicionales de recorrido ", hasta el ciclo" y "ciclo de abajo", se definen para permitir que el teclado y navegación programática arriba y abajo de la jerarquía enfoque transversal ciclo.
  8. "Enfoque transversal proveedor de la política" - de contenedores que tiene "FocusTraversalPolicyProvider" propiedad como verdadera. Este contenedor se utilizará para adquirir orientación de la política transversal. Este contenedor no define ciclo de nuevo enfoque, pero sólo modifica el orden en que sus hijos se desplazan "hacia adelante" y "hacia atrás". Enfoque proveedor de la política transversal se puede ajustar mediante setFocusTraversalPolicyProvider en el envase.
Todas las ventanas y JInternalFrame es, por defecto, una "raíz enfoque de ciclo". Si se trata de la raíz ciclo se centran solamente, entonces todos sus descendientes enfocables debe estar en su ciclo de foco, y su enfoque de la política transversal debe cumplir que están asegurándose de que todo se puede alcanzar durante la normal hacia adelante (o atrás) de recorrido. Si, por otro lado, la ventana o JInternalFrame tiene descendientes que también se centran las raíces del ciclo, entonces cada descendiente tal es un miembro de dos ciclos de enfoque: el uno que es la raíz de, y el de su más cercano enfoque de ciclo de la raíz ancestral. Con el fin de atravesar los componentes enfocables pertenecientes al ciclo de enfoque de un "descendiente" la raíz del ciclo de enfoque, se atraviesa primero (hacia adelante o hacia atrás) para llegar a la descendencia, a continuación, utiliza el "ciclo de abajo" para llegar a la operación, a su vez, sus descendientes.

Aquí está un ejemplo:

 
Three groups as described below: ABCF BDE and DGH.  

Supongamos lo siguiente:
  • A es una ventana, lo que significa que debe ser una raíz ciclo de enfoque.
  • B y D son contenedores que se encuentran las raíces de enfoque de ciclo.
  • C es un contenedor que no es una raíz ciclo de enfoque.
  • G, H, E y F son todos los componentes

 Hay un total de tres raíces de enfoque de ciclo en este ejemplo:
  • A es una raíz, y A, B, C y F son miembros de una de ciclo.
  • B es una raíz, y B, D y E son miembros de ciclo B.
  • D es una raíz, y D, G y H son miembros de ciclo D's.
 Las ventanas son los únicos contenedores que, por defecto, se concentran las raíces del ciclo. KeyboardFocusManager es una clase abstracta. AWT proporciona una implementación predeterminada de la clase DefaultKeyboardFocusManager.

KeyboardFocusManager y el navegador Contextos Algunos applets de los navegadores de partición en bases de código diferentes en contextos diferentes, y establecer barreras entre estos contextos. Cada hilo y cada componente está asociado a un contexto particular y no puede interferir en las discusiones o componentes de acceso en otros contextos. En tal escenario, habrá un KeyboardFocusManager por contexto. Otros navegadores colocar todos los applets en el mismo contexto, lo que implica que sólo habrá un KeyboardFocusManager única y global para todos los applets. Este comportamiento depende de la implementación. Consulte la documentación de su navegador para obtener más información. No importa cómo muchos contextos puede haber, sin embargo, nunca puede haber más de un propietario de enfoque, centrado ventana, o la ventana activa, por cargador de clases. KeyEventDispatcher y KeyEventPostProcessor Mientras KeyEvents de los usuarios en general, se debe entregar al propietario el enfoque, hay casos excepcionales en los que esto no es deseable. Un método de entrada es un ejemplo de un componente especializado que debe recibir KeyEvents aunque su componente de texto asociado es y debe seguir siendo el propietario de enfoque.

  1. WindowEvent.WINDOW_ACTIVATED: Este evento se distribuye a un marco o cuadro de diálogo (pero nunca de una ventana que no es un marco o cuadro de diálogo) cuando se convierte en la ventana activa.
  2. WindowEvent.WINDOW_GAINED_FOCUS: Este evento se distribuye a una ventana cuando se convierte en la ventana enfocada. Sólo de Windows enfocables puede recibir este evento.
  3. FocusEvent.FOCUS_GAINED: Este evento se distribuye a un componente cuando se convierte en el dueño de enfoque. Sólo los componentes enfocables puede recibir este evento.
  4. FocusEvent.FOCUS_LOST: Este evento se distribuye a un componente cuando ya no es el dueño de enfoque.
  5. WindowEvent.WINDOW_LOST_FOCUS: Este evento se distribuye a una ventana cuando ya no es la ventana enfocada.
  6. WindowEvent.WINDOW_DEACTIVATED: Este evento se distribuye a un marco o cuadro de diálogo (pero nunca de una ventana que no es un marco o cuadro de diálogo) cuando ya no es la ventana activa.

 Evento de entrega
Si el foco no está en la aplicación Java y el usuario hace clic en un Componenta niños pueden recibir el foco de un marco B inactivo, los siguientes eventos serán enviados y manipulados con el fin de:
  1. b recibirá un evento WINDOW_ACTIVATED.
  2. A continuación, b, recibirá un evento WINDOW_GAINED_FOCUS.
  3. Finalmente, una recibirá un evento FOCUS_GAINED.
Si el usuario hace clic en un posterior niño c Componente enfocable de otro d marco, los siguientes eventos serán enviados y manipulados con el fin de:
uno va a recibir un evento de FOCUS_LOST.
  1. b recibirá un evento WINDOW_LOST_FOCUS.
  2. b recibirá un evento WINDOW_DEACTIVATED.
  3. d recibirá un evento WINDOW_ACTIVATED.
  4. d recibirá un evento WINDOW_GAINED_FOCUS.
  5. c recibirá un evento FOCUS_GAINED.
Tenga en cuenta que cada evento será totalmente manejado antes de que el próximo evento se distribuye. Esta restricción se aplicará incluso si los componentes se encuentran en diferentes contextos y se manejan en las discusiones de eventos diferentes de despacho.
Además, cada tipo de evento se distribuye en 1-a-1 correspondencia con su tipo de evento opuesto. Por ejemplo, si un componente recibe un evento de FOCUS_GAINED, bajo ninguna circunstancia puede jamás recibirá otro evento FOCUS_GAINED sin un evento FOCUS_LOST intervenir.
Por último, es importante señalar que estos eventos se entregan sólo con fines informativos. Es imposible, por ejemplo, para evitar la entrega de un caso pendiente de FOCUS_GAINED mediante la solicitud de atención de nuevo al enfoque de componentes perder mientras controla el evento FOCUS_LOST anterior. Mientras que el código de cliente puede hacer una solicitud, el FOCUS_GAINED pendiente serán entregados, seguido más tarde por los eventos de transferencia foco de nuevo al propietario de enfoque original.
Si es absolutamente necesario suprimir el evento FOCUS_GAINED, código de cliente se puede instalar un VetoableChangeListener que rechaza el cambio de foco. Ver Focus y VetoableChangeListener.


Componentes de Windows y opuestos Cada evento incluye información sobre el "frente" o la ventana de componentes involucrados en el cambio de foco o la activación. Por ejemplo, para un evento FOCUS_GAINED, el componente opuesto es el componente que pierde el foco. Si el cambio de enfoque o la activación se produce con una aplicación nativa, con una aplicación Java en una máquina virtual diferente o contexto, o con ningún otro componente, el componente opuesto o de la ventana es nulo. Esta información es accesible a través de FocusEvent.getOppositeComponent o WindowEvent.getOppositeWindow.


Enfoque transversalCada componente define su propio conjunto de teclas de recorrido de enfoque para un enfoque dado operación de recorrido. Componentes son compatibles con distintos conjuntos de teclas para avanzar y retroceder el recorrido, y también para el recorrido por un enfoque de ciclo de recorrido. Los contenedores que se encuentran las raíces de enfoque de ciclo también soportan un conjunto de claves para el recorrido por un enfoque de ciclo de recorrido. Si un conjunto no está explícitamente definido para un componente, éste hereda de forma recursiva de un conjunto de su padre, y en última instancia, debido al impago del contexto de ancho situado en la KeyboardFocusManager actual.Uso de la API AWTKeyStroke, código de cliente puede especificar en cuál de las dos KeyEvents específicos, o KEY_PRESSED KEY_RELEASED, la operación de enfoque transversal va a producir. Independientemente de que KeyEvent se especifica, sin embargo, todos KeyEvents relacionado con la tecla de enfoque transversal, incluyendo el evento KEY_TYPED asociado, se consume, y no se envían a cualquier componente. Se trata de un error de ejecución para especificar un evento KEY_TYPED como la asignación a una operación de enfoque transversal, o para asignar el mismo evento a varias operaciones de enfoque de recorrido para cualquier componente en particular o de un defecto de KeyboardFocusManager.Las claves por defecto de enfoque de recorrido son dependiente de la implementación. Sun recomienda que todas las implementaciones de la plataforma nativa particular, utilizar las mismas claves. Para Windows y Unix, las recomendaciones son las siguientes:recorrer hacia adelante al siguiente componente:Áreas de texto: Ctrl-Tab en KEY_PRESSED Todos los demás: TAB en KEY_PRESSED y CTRL TAB-en KEY_PRESSEDrecorrer hacia atrás para el componente de los anteriores: Áreas de texto: CTRL + SHIFT + TAB en KEY_PRESSED Todos los demás: Mayús-Tab en KEY_PRESSED y CTRL-SHIFT-TAB en KEY_PRESSEDse subirá por un enfoque de ciclo de recorrido: <ninguno>atravesar por un enfoque de ciclo de recorrido: <ninguno>Los componentes se pueden habilitar y deshabilitar todas sus claves de enfoque de recorrido en masa utilizando Component.setFocusTraversalKeysEnabled. Cuando las teclas de recorrido de enfoque está incapacitado, el componente recibe todos los KeyEvents de esas claves. Cuando las teclas de recorrido de enfoque están habilitados, no se selecciona el componente para las teclas de recorrido KeyEvents, sino que los KeyEvents se asignan automáticamente a centrar las operaciones de recorrido.Para el funcionamiento normal de recorrido delante y hacia atrás, la puesta en práctica el enfoque AWT determina qué componentes para enfocar el próximo basado en el FocusTraversalPolicy de raíz el dueño foco de atención se centran en bicicleta o proveedor de recorrido en la política. Si el propietario del enfoque es la raíz del ciclo de enfoque, entonces puede ser ambigua en cuanto a los componentes que representan los componentes anterior y posterior a concentrarse durante el enfoque normal de recorrido. Por lo tanto, el KeyboardFocusManager actual mantiene una referencia a la "actual" ciclo de la raíz de enfoque, que es global en todos los contextos. La raíz enfoque actual ciclo se utiliza para resolver la ambigüedad.Para un máximo del ciclo de recorrido, el propietario de enfoque se fija a la raíz del propietario actual enfoque de ciclo de foco, y la raíz de enfoque del ciclo actual se establece en la raíz el dueño nuevo foco de atención del ciclo. Sin embargo, si la raíz del propietario actual enfoque de ciclo de enfoque es una ventana de nivel superior, entonces el dueño de enfoque está ajustado al componente por defecto la raíz del ciclo de enfoque para enfocar, y la raíz enfoque actual ciclo no ha cambiado.Por abajo del ciclo de recorrido, si el propietario actual enfoque es un enfoque de ciclo de raíz, entonces el dueño de enfoque está ajustado al componente por defecto el dueño actual enfoque para concentrarse, y la raíz de enfoque del ciclo actual se establece en el dueño de enfoque actual. Si el propietario del enfoque actual no es la raíz del ciclo de enfoque, entonces no se produce la operación de enfoque transversal.

FocusTraversalPolicy Un FocusTraversalPolicy define el orden en que los componentes dentro de un enfoque de ciclo de raíz o enfoque proveedor de la política de recorrido se atraviesan. Los casos de FocusTraversalPolicy se pueden compartir entre contenedores, permitiendo que los contenedores para poner en práctica la misma política transversal. FocusTraversalPolicies no necesitan ser reinstaladas cuando los cambios en la jerarquía de enfoque transversal de ciclo.

Cada FocusTraversalPolicy debe definir los siguientes cinco algoritmos:

  1. Teniendo en cuenta la raíz del ciclo de enfoque y un componente de una en ese ciclo, el siguiente componente después de una.  Un FocusTraversalPolicy opcionalmente puede proporcionar un algoritmo para el siguiente:
    Dada una ventana, la "inicial" de componentes en la ventana. El componente inicial será el primero en recibir el foco cuando la ventana se hace visible primero. Por defecto, este es el mismo que el "default" de componentes.
    Además, Swing proporciona una subclase de InternalFrameFocusTraversalPolicy FocusTraversalPolicy, que permite a los desarrolladores para proporcionar un algoritmo para el siguiente:
    Dado un JInternalFrame, la "inicial" de componentes en ese JInternalFrame. El componente inicial es el primero en recibir el foco cuando el JInternalFrame se selecciona por primera vez. Por defecto, este es el mismo que el componente JInternalFrame por defecto para enfocar.
    Un FocusTraversalPolicy está instalado en un contenedor con Container.setFocusTraversalPolicy. Si una política no se establece explícitamente, a continuación, un contenedor hereda su política de la más cercana a su enfoque de ciclo de la raíz ancestral. Top-inicializar sus niveles de enfocar las políticas transversales utilizando la política por el contexto. La política por defecto se establece un contexto mediante el uso de KeyboardFocusManager. setDefaultFocusTraversalPolicy.
    AWT proporciona dos implementaciones estándar FocusTraversalPolicy para el uso de código de cliente.


    1. ContainerOrderFocusTraversalPolicy: Itera a través de los componentes de un ciclo de enfoque transversal en el orden en que se han añadido a sus contenedores. Cada componente es la prueba de condición física con la acepta (componente) método. De manera predeterminada, un componente de sólo sirve si está visible, mostrable, habilitado, y recibir el foco.
      De forma predeterminada, ContainerOrderFocusTraversalPolicy implícitamente transfiere la selección hacia abajo-ciclo. Es decir, durante el funcionamiento normal de enfoque hacia delante de recorrido, el componente de recorrido después de un ciclo de la raíz se centrará el foco de componentes del ciclo de la raíz por defecto para enfocar. Esto proporciona compatibilidad con aplicaciones diseñadas sin que los conceptos de arriba y abajo del ciclo de recorrido.
    2. DefaultFocusTraversalPolicy: Una subclase de ContainerOrderFocusTraversalPolicy que redefine el examen de aptitud. Si el código de cliente se ha establecido explícitamente la focusability de un componente, ya sea Component.isFocusTraversable primordial () o Component.isFocusable (), o llamando al Component.setFocusable (boolean), y luego una DefaultFocusTraversalPolicy se comporta exactamente como un ContainerOrderFocusTraversalPolicy. Sin embargo, si el componente está confiando en focusability por defecto, y luego una DefaultFocusTraversalPolicy rechazará todos los componentes con las organizaciones no enfocables compañeros.
      El focusability de un compañero depende de la implementación. Sun recomienda que todas las implementaciones de la plataforma nativa en particular la construcción de sus compañeros con la misma focusability. Las recomendaciones para Windows y Unix son que los lienzos, etiquetas, paneles, barras de desplazamiento, ScrollPanes, Ventanas, y componentes ligeros que no enfocables compañeros, y todos los demás componentes tienen sus compañeros enfocables. Estas recomendaciones se utiliza en las implementaciones de AWT Sun. Tenga en cuenta que el focusability de los pares de un componente es diferente, y no afecta, el focusability del propio componente.
    Swing proporciona dos implementaciones adicionales, FocusTraversalPolicy estándar para el uso de código de cliente. Cada aplicación es un InternalFrameFocusTraversalPolicy.
    1. SortingFocusTraversalPolicy: determina el orden de recorrido por la clasificación de los componentes de un ciclo de enfoque transversal basado en un comparador dado. Cada componente es la prueba de condición física con la acepta (componente) método. De manera predeterminada, un componente de sólo sirve si está visible, mostrable, habilitado, y recibir el foco.
    2. De forma predeterminada, SortingFocusTraversalPolicy implícitamente transfiere la selección hacia abajo-ciclo. Es decir, durante el funcionamiento normal de enfoque hacia delante de recorrido, el componente de recorrido después de un ciclo de la raíz se centrará el foco de componentes del ciclo de la raíz por defecto para enfocar. Esto proporciona compatibilidad con aplicaciones diseñadas sin que los conceptos de arriba y abajo del ciclo de recorrido.
    3. LayoutFocusTraversalPolicy: Una subclase de SortingFocusTraversalPolicy los componentes que ordena en función de su tamaño, posición y orientación. Sobre la base de su tamaño y posición, los componentes son más o menos clasificados en filas y columnas. Para un contenedor con orientación horizontal, las columnas de correr de izquierda a derecha o de derecha a izquierda, y las filas correr de arriba a abajo. Para un contenedor con orientación vertical, las columnas de correr de arriba a abajo y ejecutar las filas de izquierda a derecha o de derecha a izquierda. Todas las columnas de una fila están completamente atravesado antes de proceder a la siguiente fila
    Aplicaciones Swing, o mixtos aplicaciones Swing / AWT, que utilizan uno de los aspecto estándar y se siente, o cualquier otra mirada y la sensación derivada de BasicLookAndFeel, utilizarán LayoutFocusTraversalPolicy para todos los contenedores de forma predeterminada.

    Todas las demás aplicaciones, incluyendo aplicaciones AWT puras, se utilizan DefaultFocusTraversalPolicy por defecto.


    Enlaces

    Swing
    http://www.dcc.uchile.cl/~lmateu/CC60H/Trabajos/edavis/swing.html
    &
    http://docs.oracle.com/javase/6/docs/api/

    awt
    http://docs.oracle.com/javase/6/docs/api/
  2. Dada una raíz ciclo de enfoque y un componente de un ciclo en que, el componente anterior antes de una.
  3. Teniendo en cuenta la raíz del ciclo de enfoque, la "primera" de componentes en ese ciclo. La "primera" de componentes es el componente de enfocar cuando el recorrido se envuelve en la dirección de avance.
  4. Teniendo en cuenta la raíz del ciclo de enfoque, la "última" de componentes en ese ciclo. El "último" componente es el componente de enfocar cuando el recorrido se envuelve en la dirección inversa.
  5. Teniendo en cuenta la raíz del ciclo de enfoque, el "defecto" de componentes en ese ciclo. El "default" de componentes será el primero en recibir el foco cuando se atraviesa hacia abajo en un nuevo enfoque de ciclo de recorrido. Esto puede ser el mismo que el "primer" de componentes, pero no necesariamente.
La clase de componente incluye las variantes de requestFocus y requestFocusInWindow que tengan un estado deseado temporal como un parámetro. Sin embargo, porque al especificar un estado temporal arbitrario no puede ser aplicable en todos los sistemas de ventanas nativos, el comportamiento correcto de este método sólo se puede garantizar para los componentes de peso ligero. Este método no está destinado al uso general, pero existe en cambio, como un gancho para las bibliotecas de componentes ligeros, como el Swing.Cuando un componente recibe un evento de FOCUS_LOST temporal, de componentes frente del evento (si existe) puede recibir un evento de FOCUS_GAINED temporal, sino que también podría recibir un evento de FOCUS_GAINED permanente. Mostrar un menú o PopupMenu, o hacer clic o arrastrar una barra de desplazamiento, debe generar un evento FOCUS_GAINED temporal. Cambio de la ventana centrado, sin embargo, dará un evento permanente FOCUS_GAINED para el propietario del nuevo enfoque.Una transferencia de foco temporal se produce normalmente como resultado de la muestra de un menú o PopupMenu, hacer clic o arrastrar una barra de desplazamiento, mover una ventana, arrastre la barra de título, o hacer otra ventana de la ventana enfocada. Tenga en cuenta que en algunas plataformas, estas acciones no pueden generar ningún FocusEvents en absoluto. En otros, las cesiones temporales de enfoque va a producir.Una transferencia permanente enfoque normalmente se produce como resultado de que un usuario hace clic en un componente seleccionable, peso pesado, se centran el recorrido con el teclado o un dispositivo de entrada equivalente, o de una llamada a requestFocus () o requestFocusInWindow ().Los eventos temporales FOCUS_LOST se envían cuando un componente pierde el foco, sino que recuperar el foco en breve. Estos eventos pueden ser útiles cuando el foco cambia son utilizados como disparadores para la validación de los datos. Por ejemplo, un componente de texto que desee para cometer su contenido cuando el usuario comienza a interactuar con otros componentes, y se puede lograr esto mediante la respuesta a los eventos FOCUS_LOST. Sin embargo, si el FocusEvent recibido es temporal, el compromiso no se debe hacer, ya que el campo de texto va a recibir el foco de nuevo en breve.Eventos FOCUS_GAINED y FOCUS_LOST se marcan como temporal o permanente.FocusEvents temporalesEn algunas plataformas, no es posible discernir el componente opuesto o ventana cuando el cambio de enfoque o la activación se produce entre dos componentes de peso pesado diferentes. En estos casos, el componente de frente o en la ventana se puede establecer en nulo en algunas plataformas, y una válida valor no nulo en otras plataformas. Sin embargo, para un cambio de enfoque entre los dos componentes de peso ligero que comparten el mismo contenedor de peso pesado, el componente de lo contrario siempre estarán configurados correctamente. Por lo tanto, una aplicación Swing puro puede ignorar esta restricción la plataforma cuando se utiliza el componente de lo contrario de un cambio de foco que se produjo dentro de una ventana de nivel superior.




El AWT define los siguientes seis tipos de eventos centrales del modelo de atención en dos clases diferentes java.awt.event:FocusEvent y WindowEventAl igual que KeyEventDispatcher, KeyboardFocusManager también implementa KeyEventPostProcessor y restricciones similares se aplican a su uso en esa capacidad.Cliente de código también puede publicar, escuchar a KeyEvents en un contexto particular a través de la interfaz de KeyEventPostProcessor. KeyEventPostProcessors inscritos en el curso recibirán KeyboardFocusManager KeyEvents después de que los KeyEvents han sido enviados para su manejo por el propietario del centro. Los KeyEventPostProcessors también recibirá KeyEvents que han sido desechados porque no hay otro modo de componentes en la aplicación posee en la actualidad el enfoque. Esto permitirá que las aplicaciones para implementar las funciones que requieren KeyEvent mundial posterior a la manipulación, tales como accesos directos del menú.Para mantener la coherencia, KeyboardFocusManager en sí es un KeyEventDispatcher. Por defecto, el KeyboardFocusManager actual será el sumidero de todas las KeyEvents no enviados por los KeyEventDispatchers registrados. El KeyboardFocusManager actual no puede ser completamente eliminado del registro como KeyEventDispatcher. Sin embargo, si un KeyEventDispatcher informes que envió a los KeyEvent, independientemente de si realmente lo hizo, el KeyboardFocusManager tomará ninguna otra medida con respecto a la KeyEvent. (Aunque es posible que el código de cliente para registrar el KeyboardFocusManager actual como una KeyEventDispatcher una o más veces, no hay ninguna razón evidente por qué esto sería necesario, y por lo tanto no es recomendable.)Un KeyEventDispatcher es una interfaz ligera que permite el código de cliente para escuchar previamente a todas las KeyEvents en un contexto particular. Las instancias de clases que implementan la interfaz y están registradas con la actual KeyboardFocusManager recibirá KeyEvents antes de que se envían al propietario de enfoque, permitiendo que el KeyEventDispatcher a reorientar el evento, se consume, el envío en sí, o hacer otros cambios.




Este documento es una especificación formal, tanto de las nuevas APIs y de las interfaces API existentes que siguen siendo pertinentes en el nuevo modelo. Combinado con el javadoc para la atención relacionados con las clases y métodos, este documento debería permitir a los desarrolladores crear aplicaciones importantes AWT y Swing, con un comportamiento de enfoque que se adapte pero consistente a través de plataformas. Este documento tiene las siguientes secciones:Para hacer frente a estas y otras deficiencias, hemos diseñado un modelo nuevo enfoque para el AWT en el JDK 1.4. Los cambios de diseño primarios fueron la construcción de una clase KeyboardFocusManager centralizado nuevo, y una arquitectura de enfoque ligero. La cantidad de enfoque relacionada, dependiente de la plataforma de código se ha minimizado y se sustituye por las APIs públicas totalmente conectable y extensible en el AWT. Si bien hemos tratado de seguir siendo compatible con la aplicación existente, nos vimos obligados a hacer cambios menores que sean incompatibles con el fin de llegar a una conclusión elegante y funcional. Anticipamos que estas incompatibilidades se tienen sólo un efecto insignificante sobre las aplicaciones existentes.Además, muchos desarrolladores señaló que la API para FocusEvent y WindowEvent eran insuficientes porque no proporcionan una forma para determinar el "opuesto" de componentes involucrados en el cambio de foco o la activación. Por ejemplo, cuando un componente ha recibido un evento FOCUS_LOST, no tenía manera de saber qué componente fue ganando atención. Desde que Microsoft Windows proporciona esta funcionalidad para que los desarrolladores libres, la migración desde Microsoft Windows C / C + + o Visual Basic a Java había sido frustrado por la omisión.




Resumen de KeyboardFocusManager
El modelo de atención está centralizada en torno a una sola clase, KeyboardFocusManager, que proporciona un conjunto de APIs para el código de cliente para obtener información sobre el estado del foco actual, iniciar cambios de enfoque, y sustituir el envío de eventos predeterminado foco con un despachador de costumbre. Los clientes pueden solicitar información sobre el estado del foco directamente, o puede registrar un PropertyChangeListener que recibirá PropertyChangeEvents cuando un cambio en el estado del foco se produce.
KeyboardFocusManager introduce siete principales conceptos y su terminología:

No hay comentarios.:

Publicar un comentario

Suscribirse a: Entradas (Atom)