Daniele Futtorovic <da.futt.news@laposte.invalid> writes:
On 24/07/2008 08:43, Leo Breebaart allegedly wrote:
In reality, my application has a number of these Actions. I
want the user to be able to continue to select other Actions,
even if he or she is not yet finished with the current one.
If I make the dialog modal, the main window becomes
inaccessible and no other buttons can be clicked. If I set
the ModalityType of my QuestionnaireDialog to DOCUMENT_TYPE,
I *almost* get what I want. Now I can indeed start multiple
actions (and I take care to disable the originating Action as
long as its Questionnaire is showing, so you can not start
the same action twice), but unfortunately the last-started
Questionnaire will always be the only available to user
input. You cannot select any of the earlier Questionnaire
dialogs -- they are visible, but disabled. You can start
multiple actions, but you have to unwind the dialog stack one
by one. [...]
I see. I might note that your design may be a bit awkward (in
terms of "good UI design"), and may confuse some users. You
might want to look for better ways to visually represent the
flow you envision.
Hmmm. I don't want to abuse the newsgroup and anyone's time, so
if nobody is up for this discussion I will completely understand,
but let me explain the context in a bit more detail. I am always
interested in suggestions to improve the UI.
My application has to present the user with a main console from
which various "experiments" can be chosen by clicking on a
button/link/whatever. Users have to be free to run these
experiments at random and simultaneously (and even multiple
instances of the same one), hence my desire to not block the
entire application with one experiment's modal dialogs.
These non-modal experiments all take the form of third-party
"black box" applications that I am starting with ProcessBuilder.
So they all have their own GUIs that are *not* under my control
at all. This is why I feel I can't really use the suggestion made
earlier of giving every experiment its own tab pane to run in.
the tab pane would be empty -- there will be windows and frames
all over the place anyway (and I know *that* may end up confusing
the user, but the 'multiple simultaneous apps' is a basic
requirement I cannot escape from),
Now some, not all, of these experiments, need to be run bookended
by pre- and post-run questionnaires the user has to fill in. The
user *is* allowed to cancel the questionnaire, after which the
experiment app will be launched regardless (but in 'play' mode --
the experiment will not be logged in the experiment database).
And so that is why I want to be able to execute multiple
simultaneous Actions, with every Action in effect being a modal
wrapper around an application I have no further control over
during its run.
Does my UI approach make a little more sense now?
Java 6 has extended the concept of modality so you should be able to do what you
want in Java 6. In previous versions the modality was application modality,
which blocked everything. There are now application, document and toolkit
Have you looked at the modality examples in the Java Tutorial no Swing? This one
the same ownerless top-level window. It doesn't block access to other windows
which have different top-level windows. The example above uses two distinct
which blocks both the other chains. Also, windows which are themselves