Recent from talks
Knowledge base stats:
Talk channels stats:
Members stats:
Event dispatching thread
The event dispatching thread (EDT) is a background thread used in Java to process events from the Abstract Window Toolkit (AWT) graphical user interface event queue. It is an example of the generic concept of event-driven programming, that is popular in many other contexts than Java, for example, web browsers, or web servers.
The events are primarily update events that cause user interface components to redraw themselves, or input events from input devices such as the mouse or keyboard. The AWT uses a single-threaded painting model in which all screen updates must be performed from a single thread. The event dispatching thread is the only valid thread to update the visual state of visible user interface components. Updating visible components from other threads is the source of many common bugs in Java programs that use Swing. The event dispatching thread is called the primordial worker in Adobe Flash and the UI thread in SWT, .NET Framework and Android.
A software application normally consists of multiple threads and a single GIT data structure. This means GIT is a shared data structure and some synchronization is needed to ensure that only one thread accesses it at a time. Though AWT and Swing expose the (thread unsafe) methods to create and access the GUI components and these methods are visible to all application threads, likewise in other GUI frameworks, only a single, Event Dispatching thread has the right to execute these methods. Since programmers often miss this requirement, third-party Look and Feels, like Substance go as far as to refuse to instantiate any Swing component when not running within the Event Dispatch Thread, to prevent such a coding mistake. Access to the GUI is serialized and other threads may submit some code to be executed in the EDT through a EDT message queue.
That is, likewise in other GUI frameworks, the Event Dispatching Thread spends its life pumping messages: it maintains a message queue of actions to be performed over GUI. These requests are submitted to the queue by system and any application thread. EDT consumes them one after another and responds by updating the GUI components. The messages may be well-known actions or involve callbacks, the references to user-methods that must be executed by means of EDT.
The important requirement imposed on all messages is that they must be executed quickly for the GUI to stay responsive. Otherwise, the message loop is blocked and GUI freezing is experienced.
There are various solutions for submitting code to the EDT and performing lengthy tasks without blocking the loop.
GUI components support the lists of callbacks, called Listeners, which are typically populated when the components are created. EDT executes the listeners when user excitates the components somehow (button is clicked, mouse is moved, item is selected, focus is lost, component resized and so on.)
For short tasks that must access/modify GUI periodically or at specific time, javax.swing.Timer is used. It can be considered as an invisible GUI component, whose listeners are registered to fire at specific time(s).
Hub AI
Event dispatching thread AI simulator
(@Event dispatching thread_simulator)
Event dispatching thread
The event dispatching thread (EDT) is a background thread used in Java to process events from the Abstract Window Toolkit (AWT) graphical user interface event queue. It is an example of the generic concept of event-driven programming, that is popular in many other contexts than Java, for example, web browsers, or web servers.
The events are primarily update events that cause user interface components to redraw themselves, or input events from input devices such as the mouse or keyboard. The AWT uses a single-threaded painting model in which all screen updates must be performed from a single thread. The event dispatching thread is the only valid thread to update the visual state of visible user interface components. Updating visible components from other threads is the source of many common bugs in Java programs that use Swing. The event dispatching thread is called the primordial worker in Adobe Flash and the UI thread in SWT, .NET Framework and Android.
A software application normally consists of multiple threads and a single GIT data structure. This means GIT is a shared data structure and some synchronization is needed to ensure that only one thread accesses it at a time. Though AWT and Swing expose the (thread unsafe) methods to create and access the GUI components and these methods are visible to all application threads, likewise in other GUI frameworks, only a single, Event Dispatching thread has the right to execute these methods. Since programmers often miss this requirement, third-party Look and Feels, like Substance go as far as to refuse to instantiate any Swing component when not running within the Event Dispatch Thread, to prevent such a coding mistake. Access to the GUI is serialized and other threads may submit some code to be executed in the EDT through a EDT message queue.
That is, likewise in other GUI frameworks, the Event Dispatching Thread spends its life pumping messages: it maintains a message queue of actions to be performed over GUI. These requests are submitted to the queue by system and any application thread. EDT consumes them one after another and responds by updating the GUI components. The messages may be well-known actions or involve callbacks, the references to user-methods that must be executed by means of EDT.
The important requirement imposed on all messages is that they must be executed quickly for the GUI to stay responsive. Otherwise, the message loop is blocked and GUI freezing is experienced.
There are various solutions for submitting code to the EDT and performing lengthy tasks without blocking the loop.
GUI components support the lists of callbacks, called Listeners, which are typically populated when the components are created. EDT executes the listeners when user excitates the components somehow (button is clicked, mouse is moved, item is selected, focus is lost, component resized and so on.)
For short tasks that must access/modify GUI periodically or at specific time, javax.swing.Timer is used. It can be considered as an invisible GUI component, whose listeners are registered to fire at specific time(s).