Hi there
I also did something like that
All I needed to do is making a Proxy class with a synchronized method.
Andreas
On Jan 26, 2010, at 3:06 PM, Christopher Brind wrote:
> Hi Bob,
>
> This isn't really about being modal, but about stopping the flow of
> execution. For example, in Javascript:
>
> Alert.show("hello");
> Alert.show("world");
>
> 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:
>
> Alert.show("hello");
> Alert.show("world");
>
> 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
> Pivot.
>
> Cheers,
> Chris
>
>
>
> 2010/1/26 Bob Santos <[email protected]>
> 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 <[email protected]> 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
>
>
>
