pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Brind <christopher.br...@googlemail.com>
Subject Re: Blocking while a dialog/prompt/alert/sheet is open, like Javascript's alert() ?
Date Tue, 26 Jan 2010 14:06:02 GMT
Hi Bob,

This isn't really about being modal, but about stopping the flow of
execution.  For example, in Javascript:



The second alert doesn't appear until you press OK on the first.

In Pivot or Swing (and every other UI framework?) if you popup an Alert
processing continues, for instance in Flex:



The second alert appears immediately and on top of the previous one.

Clint wants to achieve the first scenario, but this is not possible with


2010/1/26 Bob Santos <bob.santosjr@gmail.com>

> If I'm not mistaken, in Swing, you can create confirm dialogs(Yes/No),
> message dialogs or option dialogs by using JOptionPane and also I think they
> are by default modal(?), which means access to other part of the application
> is not allowed until interaction with the active dialog is done.
> You can also create your custom dialog by extending Dialog and specifying
> the modality.
> And yes it helps to know that everything you want to do with the UI should
> be done within the EDT as Greg stated.
> On Tue, Jan 26, 2010 at 9:40 PM, Greg Brown <gkbrown@mac.com> wrote:
>> Hi Clint,
>> > Now, my question: Is it possible to achieve behavior like the
>> > Javascript's alert() function with Pivot?  That is, I'd like to put up a
>> > simple yes/no "do something"/"please don't" popup on the screen, and
>> > have the app block - the alert doesn't just block input to other
>> > elements - until the user chooses an option, or closes the popup.  This
>> > is possible in SWT, I don't know about Swing.
>> Sorry, it is not possible - as you noted, Window#open() is not a blocking
>> call in WTK. Pivot is ultimately based on AWT, which uses a push model for
>> event notifications (vs. pull). If you were to call a blocking method from a
>> user input event such as a button press, no further event processing could
>> occur until that method had returned, and the entire UI would appear to
>> freeze.
>> I personally don't mind the anonymous inner class syntax:
>>    dialog.open(owner, new DialogCloseListener() {
>>        @Override
>>        public void dialogClosed(Dialog dialog, boolean modal) {
>>            // Get selected option and act on it
>>        }
>>    });
>> I actually think this reflects a pretty consistent design - you open the
>> dialog in response to one event (e.g. "button pressed"), and you handle the
>> dialog's result in response to another event (e.g. "dialog closed").
>> > Making the call to Dialog.open() from another thread doesn't have any
>> effect.
>> Note that, as in Swing, multi-threaded access to UI elements is not
>> supported. All UI operations must be performed on the EDT.
>> Hope this helps,
>> Greg

View raw message