Name: el35337 Date: 10/05/98


It seems like one problem with the current
Swing M/(VC) model is that there is no ordering
distinction among the listeners added to Swing
components. This makes it very difficult to
ensure that operations are ordered properly.

For instance, with the JComboBox, it is easily
possible to have one's actionPerformed() method
called before the JComboBox has completed its
rendering cycle and put the popup menu down. In
our application, we put up a modal dialog in response
to a change in a particular JComboBox. Because
our actionPerformed() method is called before the
V/C has finished with its rendering, we get the
display stuck in the middle. There is no practical
way of preventing this outcome, as even if we use
threads, there's no guarantee that we can invoke
the display of our dialog after the JComboBox has
finished putting down the popup menu. The
SwingUtilities.invokeLater() method might help
here, but it seems very iffy at best. If we
could add a listener with the qualification that
it was to be called after the primary gui control
had finished with its update cycle, this wouldn't
be an issue.

Similarly, there are times when one seeks to do
event filtering, such as with popup's over JLists,
or with keystrokes in a text field. It would be
great if there was a way to get notified of an
event before the model was, so that some code
could make a go/no-go decision before the gui
did its update. We do this with text fields
now by subclassing the text field and overriding
processKeyEvent(), but this seems very reminiscent
of the pre-JDK 1.1 model, where you had to subclass
everything to provide any sort of custom behavior.
If it were possible to interpose an event listener
before the model was changed that had the ability
to prevent further processing of the event,
it would be possible to easily impose event
filtering without having to be always subclassing
GUI components and/or models.

My briefly-thought-out idea is to have three temporal
categories for listeners, so you could add listeners
to be called before, during, and after the gui
rendering cycle. I know this is a horrifically
big change to the code, and may thus not be feasible,
but as it stands, it is very difficult to reliably
use Swing in some circumstances because of the
loose-binding brought about by the MVC model.
(Review ID: 39994)
======================================================================