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

[Kevin Rushforth]

>
> 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?

We already have "initOwner(Window)" which sets the owner (parent) of 
that Stage. If the owner of a given stage is closed or iconified then 
that stage will also be closed or iconified. Also, it won't show up as a 
separate item in the dock. This should do what you want.

The following API docs have been added to 2.1 that should explain this 
(which is available as a developer preview and will go live later this 
month). Note that this is just a javadoc change; the feature was 
available in 2.0.

    *Owner*

    A stage can optionally have an owner Window. When a window is a
    stage's owner, it is said to be the parent of that stage. When a
    parent window is closed, all its descendant windows are closed. The
    same chained behavior applied for a parent window that is iconified.
    A stage will always be on top of its parent window. The owner must
    be initialized before the stage is made visible.


-- Kevin



Tom Schindl wrote:
> 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
>>>>
>>>>     
>>>>         
>>>   
>>>       
>
>
>