You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@pivot.apache.org by Tomas Stenlund <to...@telia.com> on 2011/10/16 11:13:09 UTC
Modeless dialog gets moved to the back in display order
I have an Application that creates a Frame containing menues and some
controls. Nothing fancy. In addition to this I have a modeless dialog
where modal="false" set in the bxml. It implements Bindable and extends
Dialog. I create it (dialog) with a readObject on the BXMLSerializer and
open it with dialog.open (source.getDisplay());
So far so good. Now two scenarios.
1) I create an Action that reads and opens the dialog and connects it
programmatically to the action name in the Menu.Item in the main frames
bxml. When I select that menuitem the dialog box is created and shown.
But now to the interesting part here.
The modeless dialog is shown on top of the main frame. This is done at
the same time as the menus (graphically) are expanded and shown. But
when the frame redraws the menu to hide the expansion as is the normal
behaviour when the mouse is clicked and released on a menu item the
entire frame is put topmost in display order hiding my newly created
modeless dialogbox. This is not what I want, since the user cannot start
working on this until the main frame is either moved or put backwards in
displayorder.
2) If I do exacly the same but from a Button in the main frame the
modeless dialogbox stays as the topmost window.
The same behaviour for both windows and linux, so I guess I must be
doing something wrong here.
Any ideas ?
Cheers,
Tomas
Re: Modeless dialog gets moved to the back in display order
Posted by Greg Brown <gk...@verizon.net>.
It was a pretty simple fix. We weren't checking the value of the modal flag so all dialogs behaved as if they were modal.
On Oct 18, 2011, at 3:33 PM, Tomas Stenlund wrote:
> Quick as always, care to enligthen me with what it was ?
>
> Thanks,
>
> Tomas
>
> On 10/17/2011 07:18 PM, Greg Brown wrote:
>>>> Did you try opening the dialog with the main frame as its owner? That will ensure that it remains on top of the frame.
>>> Yes, but then I don't get it to be non-modal even if I use the setModal (false) on the dialog. So I can't continue to use the main frames menus and buttons. Or am I missing something obvious here ?
>> Nope, you discovered a bug. :-) I just checked in a fix.
>>
>>
>
Re: Modeless dialog gets moved to the back in display order
Posted by Tomas Stenlund <to...@telia.com>.
Quick as always, care to enligthen me with what it was ?
Thanks,
Tomas
On 10/17/2011 07:18 PM, Greg Brown wrote:
>>> Did you try opening the dialog with the main frame as its owner? That will ensure that it remains on top of the frame.
>> Yes, but then I don't get it to be non-modal even if I use the setModal (false) on the dialog. So I can't continue to use the main frames menus and buttons. Or am I missing something obvious here ?
> Nope, you discovered a bug. :-) I just checked in a fix.
>
>
Re: Modeless dialog gets moved to the back in display order
Posted by Greg Brown <gk...@verizon.net>.
>> Did you try opening the dialog with the main frame as its owner? That will ensure that it remains on top of the frame.
> Yes, but then I don't get it to be non-modal even if I use the setModal (false) on the dialog. So I can't continue to use the main frames menus and buttons. Or am I missing something obvious here ?
Nope, you discovered a bug. :-) I just checked in a fix.
Re: Modeless dialog gets moved to the back in display order
Posted by Greg Brown <gk...@verizon.net>.
>> Did you try opening the dialog with the main frame as its owner? That will ensure that it remains on top of the frame.
> Yes, but then I don't get it to be non-modal even if I use the setModal (false) on the dialog. So I can't continue to use the main frames menus and buttons. Or am I missing something obvious here ?
Nope, you discovered a bug. :-) I just checked in a fix.
Re: Modeless dialog gets moved to the back in display order
Posted by Tomas Stenlund <to...@telia.com>.
Yes, but then I don't get it to be non-modal even if I use the setModal
(false) on the dialog. So I can't continue to use the main frames menus
and buttons. Or am I missing something obvious here ?
/Tomas
On 10/17/2011 03:32 PM, Greg Brown wrote:
> Did you try opening the dialog with the main frame as its owner? That will ensure that it remains on top of the frame.
>
> On Oct 16, 2011, at 5:13 AM, Tomas Stenlund wrote:
>
>> I have an Application that creates a Frame containing menues and some controls. Nothing fancy. In addition to this I have a modeless dialog where modal="false" set in the bxml. It implements Bindable and extends Dialog. I create it (dialog) with a readObject on the BXMLSerializer and open it with dialog.open (source.getDisplay());
>>
>> So far so good. Now two scenarios.
>>
>> 1) I create an Action that reads and opens the dialog and connects it programmatically to the action name in the Menu.Item in the main frames bxml. When I select that menuitem the dialog box is created and shown. But now to the interesting part here.
>>
>> The modeless dialog is shown on top of the main frame. This is done at the same time as the menus (graphically) are expanded and shown. But when the frame redraws the menu to hide the expansion as is the normal behaviour when the mouse is clicked and released on a menu item the entire frame is put topmost in display order hiding my newly created modeless dialogbox. This is not what I want, since the user cannot start working on this until the main frame is either moved or put backwards in displayorder.
>>
>> 2) If I do exacly the same but from a Button in the main frame the modeless dialogbox stays as the topmost window.
>>
>> The same behaviour for both windows and linux, so I guess I must be doing something wrong here.
>>
>> Any ideas ?
>>
>> Cheers,
>>
>> Tomas
>>
>
Re: Modeless dialog gets moved to the back in display order
Posted by Greg Brown <gk...@verizon.net>.
Did you try opening the dialog with the main frame as its owner? That will ensure that it remains on top of the frame.
On Oct 16, 2011, at 5:13 AM, Tomas Stenlund wrote:
> I have an Application that creates a Frame containing menues and some controls. Nothing fancy. In addition to this I have a modeless dialog where modal="false" set in the bxml. It implements Bindable and extends Dialog. I create it (dialog) with a readObject on the BXMLSerializer and open it with dialog.open (source.getDisplay());
>
> So far so good. Now two scenarios.
>
> 1) I create an Action that reads and opens the dialog and connects it programmatically to the action name in the Menu.Item in the main frames bxml. When I select that menuitem the dialog box is created and shown. But now to the interesting part here.
>
> The modeless dialog is shown on top of the main frame. This is done at the same time as the menus (graphically) are expanded and shown. But when the frame redraws the menu to hide the expansion as is the normal behaviour when the mouse is clicked and released on a menu item the entire frame is put topmost in display order hiding my newly created modeless dialogbox. This is not what I want, since the user cannot start working on this until the main frame is either moved or put backwards in displayorder.
>
> 2) If I do exacly the same but from a Button in the main frame the modeless dialogbox stays as the topmost window.
>
> The same behaviour for both windows and linux, so I guess I must be doing something wrong here.
>
> Any ideas ?
>
> Cheers,
>
> Tomas
>
SV: SV: SV: Modeless dialog gets moved to the back in display order
Posted by Edvin Syse <es...@syse.no>.
> that works, but it feels like aspirin to cure the headache. Not whats causing it
> ;-)
>
> But as a workaround ... I've seen worse ...
Just to be clear - I did not in any way suggest you use the code as a workaround. It merely shows you where the problem is :) You could dig into the code that handles action execution from menu items and try to solve it/submit a patch.
-- Edvin
Re: SV: SV: Modeless dialog gets moved to the back in display order
Posted by Tomas Stenlund <to...@telia.com>.
Well,
that works, but it feels like aspirin to cure the headache. Not whats
causing it ;-)
But as a workaround ... I've seen worse ...
Cheers,
Tomas
On 10/16/2011 07:00 PM, Edvin Syse wrote:
>> I've made a simple example which shows the same thing in eclipse
>> (tar/gziped the entire project). You can start the dialog either with a press on
>> the pushbutton or via the menuitem selection - Start.java is the Application.
>>
>> The behaviour, at least as it is for me, is that the modeless dialog is shown
>> initially, but hidden behind the main frame after the menu is redrawn. This
>> behaviour does not happen when using the pushbutton.
> It looks like this is what's happening:
>
> 1. You select the menu item and the action fires
> 2. Your dialog is opened and will be shown in the foreground for a short time
> 3. The handling of the menu item sends the focus back to the frame which contains the menu item, or possibly the menu item itself, which will put the newly opened window in the background again.
>
> You can try this piece of nasty code to open the dialog in ActionTest.java:
>
> new Thread() {
> public void run() {
> try {
> Thread.sleep(500);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> ApplicationContext.queueCallback(new Runnable() {
> public void run() {
> dialog.open(Window.getActiveWindow().getDisplay());
> }
> });
> }
> }.start();
>
> (instead of just dialog.open()).
>
> Since I sleep for half a second there, the menu item handling has completed, and the dialog will show up correctly. What's causing this I don't know though.
>
> -- Edvin
SV: SV: Modeless dialog gets moved to the back in display order
Posted by Edvin Syse <es...@syse.no>.
> I've made a simple example which shows the same thing in eclipse
> (tar/gziped the entire project). You can start the dialog either with a press on
> the pushbutton or via the menuitem selection - Start.java is the Application.
>
> The behaviour, at least as it is for me, is that the modeless dialog is shown
> initially, but hidden behind the main frame after the menu is redrawn. This
> behaviour does not happen when using the pushbutton.
It looks like this is what's happening:
1. You select the menu item and the action fires
2. Your dialog is opened and will be shown in the foreground for a short time
3. The handling of the menu item sends the focus back to the frame which contains the menu item, or possibly the menu item itself, which will put the newly opened window in the background again.
You can try this piece of nasty code to open the dialog in ActionTest.java:
new Thread() {
public void run() {
try {
Thread.sleep(500);
} catch (InterruptedException e) {
e.printStackTrace();
}
ApplicationContext.queueCallback(new Runnable() {
public void run() {
dialog.open(Window.getActiveWindow().getDisplay());
}
});
}
}.start();
(instead of just dialog.open()).
Since I sleep for half a second there, the menu item handling has completed, and the dialog will show up correctly. What's causing this I don't know though.
-- Edvin
Re: SV: Modeless dialog gets moved to the back in display order
Posted by Tomas Stenlund <to...@telia.com>.
Hi,
I've made a simple example which shows the same thing in eclipse
(tar/gziped the entire project). You can start the dialog either with a
press on the pushbutton or via the menuitem selection - Start.java is
the Application.
The behaviour, at least as it is for me, is that the modeless dialog is
shown initially, but hidden behind the main frame after the menu is
redrawn. This behaviour does not happen when using the pushbutton.
Cheers,
Tomas
On 10/16/2011 01:48 PM, Tomas Stenlund wrote:
> Hi,
>
> no that does not seem to be it. I use the display to create the
> dialog, i.e. with no window owner. I don't think I can get a modeless
> dialog otherwise. I just for the fun of it wrote out the hashCode for
> the display I use in both cases and they hash to the same value.
>
> But I have too much additional code in here so I will try to make a
> barebone example and see wether or not that yields the same result.
>
> Cheers,
>
> Tomas
>
> On 10/16/2011 11:19 AM, Edvin Syse wrote:
>>> same time as the menus (graphically) are expanded and shown. But when
>>> the frame redraws the menu to hide the expansion as is the normal
>>> behaviour when the mouse is clicked and released on a menu item the
>>> entire
>>> frame is put topmost in display order hiding my newly created modeless
>>> dialogbox. This is not what I want, since the user cannot start
>>> working on this
>>> until the main frame is either moved or put backwards in displayorder.
>>>
>>> 2) If I do exacly the same but from a Button in the main frame the
>>> modeless
>>> dialogbox stays as the topmost window.
>>>
>>> The same behaviour for both windows and linux, so I guess I must be
>>> doing
>>> something wrong here.
>> I think that source.getWindow() returns different results depending
>> on where you call it from, and I think you need it to be your "main"
>> window. I'm not sure this would be the best solution, but try saving
>> a static reference to your main window somewhere and pass that to the
>> dialog.open call and see if it solves your problem, then others might
>> be able to shed some light as to why this happens.
>
>
Re: SV: Modeless dialog gets moved to the back in display order
Posted by Tomas Stenlund <to...@telia.com>.
Hi,
no that does not seem to be it. I use the display to create the dialog,
i.e. with no window owner. I don't think I can get a modeless dialog
otherwise. I just for the fun of it wrote out the hashCode for the
display I use in both cases and they hash to the same value.
But I have too much additional code in here so I will try to make a
barebone example and see wether or not that yields the same result.
Cheers,
Tomas
On 10/16/2011 11:19 AM, Edvin Syse wrote:
>> same time as the menus (graphically) are expanded and shown. But when
>> the frame redraws the menu to hide the expansion as is the normal
>> behaviour when the mouse is clicked and released on a menu item the entire
>> frame is put topmost in display order hiding my newly created modeless
>> dialogbox. This is not what I want, since the user cannot start working on this
>> until the main frame is either moved or put backwards in displayorder.
>>
>> 2) If I do exacly the same but from a Button in the main frame the modeless
>> dialogbox stays as the topmost window.
>>
>> The same behaviour for both windows and linux, so I guess I must be doing
>> something wrong here.
> I think that source.getWindow() returns different results depending on where you call it from, and I think you need it to be your "main" window. I'm not sure this would be the best solution, but try saving a static reference to your main window somewhere and pass that to the dialog.open call and see if it solves your problem, then others might be able to shed some light as to why this happens.
SV: Modeless dialog gets moved to the back in display order
Posted by Edvin Syse <es...@syse.no>.
> same time as the menus (graphically) are expanded and shown. But when
> the frame redraws the menu to hide the expansion as is the normal
> behaviour when the mouse is clicked and released on a menu item the entire
> frame is put topmost in display order hiding my newly created modeless
> dialogbox. This is not what I want, since the user cannot start working on this
> until the main frame is either moved or put backwards in displayorder.
>
> 2) If I do exacly the same but from a Button in the main frame the modeless
> dialogbox stays as the topmost window.
>
> The same behaviour for both windows and linux, so I guess I must be doing
> something wrong here.
I think that source.getWindow() returns different results depending on where you call it from, and I think you need it to be your "main" window. I'm not sure this would be the best solution, but try saving a static reference to your main window somewhere and pass that to the dialog.open call and see if it solves your problem, then others might be able to shed some light as to why this happens.