This is the way it's done. You can think of JavaScript as running on the event-dispatch-thread.
Therefore, opening a DialogBox and making the thread wait until a button is clicked results in the following on the queue: +----------------+ +-------------+ | wait for click | -> | click event | +----------------+ +-------------+ the wait for click will wait for ever since it never lets the thread move onto the "click event" task and process the actual event. This is a simplification, but in essence the way it works. I wrote about this problem in terms of GWT RPC... but the principal is the same: http://lemnik.wordpress.com/2008/07/04/gwt-rpc-is-called-aynchronous-for-a-reason/ Hope that explains things a bit. lama wrote: > I have the same question. > I've had to workaround this by adding callbacks to transfer the data > from the dialog back to the caller. > > Regards, > lama > > On Aug 29, 9:16 am, gwt-user <[EMAIL PROTECTED]> wrote: >> 1. To illustrate the first point. In the following code: >> >> boolean ok = Window.confirm("Are you sure ....."); >> >> if (ok) { >> >> .... >> >> } >> >> code inside the if block will be executed only after user presses >> button on the confirm dialog. Is it possible to do the same with >> instance of DialogBox? >> >> 2. The following code >> >> DialogBox dialog = new DialogBox(true, true); >> dialog.show(); >> >> does not ignore keyboard and mouse events for widgets not contained by >> the dialog >> >> Thank you, >> >> ----Boris > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
