Other |
---|
tbdUnresolved |
Duplicate :
|
|
Duplicate :
|
|
Duplicate :
|
|
Duplicate :
|
|
Duplicate :
|
|
Duplicate :
|
|
Duplicate :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
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) ======================================================================
|