API REVIEW request for RT-19783: Provide an option to allow modal windows to be blocking

[Tom Schindl]

Hi Kevin,

Something else in this context came to my mind. Isn't it needed for
Dialogs for example that their visibility is bound to the visibility of
some parent stage?

Say I have an application with a "main" stage and a none modal dialog
stage, I think now closing the "main" stage should also bring down the
dialog stage.

Beside that a dialog stage should not have a Dock-Item showing for
example. So I guess to really implement dialogs you'll also have to add
a new constructor "Stage(Stage parent)" or are you going to add a new
class which can be used as the super-class for that like FXDialog?

Anyways this is maybe a different discussion but it just came to my mind
because the current API doesn't allow me to implement my own dialog
stages who don't show up in the dock.

Tom

Am 11.04.12 04:38, schrieb Kevin Rushforth:
> Sure, I could add something like that to make it more clear. Anything
> that causes the window to be no longer showing will cause showAndWait()
> to return, which includes calling hide() or closing the window through
> window system interaction.
> 
> I just realized that there is something else I need to add to the
> documentation:  nested calls are permitted, but an "outer" call to
> showAndWait() will never return until all "inner" calls return. This can
> happen in the following case:
> 
>     <SOME EVENT HANDLER> {
>         s1.showAndWait(); // blocks until s1 is hidden
>         some instruction after s1 is hidden
>    }
> 
> ...
> 
>     <SOME OTHER EVENT HANDLER> {
>          s2.showAndWait(); // blocks until s2 is hidden
>         some instruction after s2 is hidden
>    }
> 
> At this point you have a nested event loop within a nested event loop.
> If some piece of code calls "s1.hide()" it will not unblock and exit
> "some instruction after s1 is hidden" until s2 is also closed.
> 
> -- Kevin
> 
> 
> Tom Schindl wrote:
>> What I'm not clear about is what are the circumstances the call returns.
>> Is it only when the user hits the stages close icon, someone calls the
>> close/hide method, ...?
>>
>> Maybe referring to close/hide in the javadoc makes it clear?
>>
>> So the revised javadoc could be:
>>
>> --
>> Show the stage and wait for it to be closed (through user interaction or
>> by calling {@link #close} or {@link #hide}) before returning to the
>> caller. This must be called on the FX Application thread. The stage must
>> not already be visible prior to calling this method. This must not be
>> called on the primary stage.
>> --
>>
>>
>> Tom
>>
>>
>>
>> Am 10.04.12 22:43, schrieb Kevin Rushforth:
>>   
>>> JIRA:  http://javafx-jira.kenai.com/browse/RT-19783
>>>
>>> We have had several requests for a way to block the caller while a
>>> (modal) dialog is shown. The show() method on a Stage is specified to
>>> return to the caller immediately regardless of the modality of a stage.
>>> This is a good semantic for many applications, but complicates the logic
>>> for other applications which don't want to proceed until the dialog is
>>> dismissed. It is also needed internally to implement an Alert class (see
>>> RT-12643 <http://javafx-jira.kenai.com/browse/RT-12643> for example).
>>> Swing dialog, for example, JOptionPane, work by blocking the caller
>>> until the dialog is dismissed meaning that Swing application programmers
>>> are already familiar with that model.
>>>
>>> Our proposal for JavaFX 2.2 is to add a new method on Stage,
>>> showAndWait(), which will block the caller until the stage is hidden.
>>> Note that while this is primarily useful for modal Stages, there is
>>> nothing in the API that restricts it to such.
>>>
>>> The proposed method and javadoc are described in the JIRA
>>> <http://javafx-jira.kenai.com/browse/RT-19783?focusedCommentId=110277&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-110277>,
>>> but since it is so short, I will also list it here:
>>>
>>>        /**
>>>         * Show the stage and wait for it to be closed before returning
>>> to the
>>>         * caller. This must be called on the FX Application thread. The
>>> stage
>>>         * must not already be visible prior to calling this method. This
>>> must not
>>>         * be called on the primary stage.
>>>         *
>>>         * @throws IllegalStateException if this method is called on a
>>> thread
>>>         *     other than the JavaFX Application Thread.
>>>         * @throws IllegalStateException if this method is called on the
>>>         *     primary stage.
>>>         * @throws IllegalStateException if this stage is already showing.
>>>         */
>>>        public void showAndWait();
>>>
>>>
>>> -- Kevin
>>>
>>>     
>>
>>
>>   


-- 
B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl                 geschäftsführer/CEO
------------------------------------------------------------------------
eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
http://www.BestSolution.at                      phone    ++43 512 935834