Flushes all pending events from the queue.
Calling flushEvents() affects the timing of Java repaint() events.
Any change (e.g. BBjControl::setText()) that changes the visual appearance of a window generates a repaint event on the Java EventDispatchThread. Internally Java accumulates all repaint events until it determines that there are no more outstanding events on the EventQueue and only when the EventQueue is empty does Java actually paint the areas of the screen that have changed. This allows Java to collapse all the outstanding repaint requests into a single paint operation and is an important optimization since paint is an expensive operation.
When a program calls flushEvents(), BBj stops placing events onto the Java EventQueu until the EventQueue becomes empty. This means that a call to flushEvents() will cause Java to execute any repaint() requests that are outstanding at the time flushEvents() is called.
A program that makes a large number of method calls that modify the appearance of Windows and intersperces calls to flushEvents() within that list of method calls may suffer performance degradation because each call to flushEvents() will result in a paint of the screen. Without the flushEvents() calls, all the screen changes will be collapsed to a single paint.
A repaint will typically take a couple hundred milliseconds so this is only an issue when there are a large number of screen changes with a large number of flushEvents() interspersed in the list of screen changes.
See the BBj Object Diagram for an illustration of the relationship between BBj Objects.