Community
Participate
Working Groups
Build Identifier: SWT 3.5.2 On Mac, Dialog popup from a parent shell is covers by another shell which is popup from the parent shell Reproducible: Always Steps to Reproduce: 1. Create Shell A.On Shell A, there are two buttons, one (named "open Shell B") 1. Create Shell A.On Shell A, there are two buttons, one (named "open Shell B") can open a child Shell B, one (named "open dialog C") can open child dialog C. 2. Click "Open Shell B" to open Shell B, click "Open dialog C" to open dialog C 3. Now dialog C is foremost, drag dialog C to Shell B, now dialog C can covers Shell B - dialog C is on Shell B. Click Shell B to make it to the foremost, drag dialog C to Shell B, now Shell B is still on the top of dialog C - Shell B covers dialog C. Click Shell A to bring Shell A to foremost, drag dialog C to Shell B, dialog C can be on the top of Shell B this time.
Created attachment 169453 [details] Sample code to reproduce dialog cover issue
Problem is being reported by Lotus Sametime team.
Scott, please investigate this one.
Carbon or Cocoa? I assume Carbon since you set the platform but I want to be sure.
Carbon.
I think we're going to have to rethink the implementation of parent/child windows. Window groups can't be configured to give the right behavior. Shells should be able to layer independently but window groups create a new layer for all windows in the group. Same is true on Cocoa -- addChildWindow is not what you want to use.
The AWT had a similar problem, and I seem to recall we had to implement our own management of owned windows.
This may not be as big a change as I thought. Setting kWindowGroupAttrSelectAsLayer when creating the window group makes for better behavior; clicking on a dialog brings all of the windows in the group to the foreground so we don't have an active window behind an inactive window. Now I want to see what Windows does.
Created attachment 171860 [details] Fix This change sets kWindowGroupAttrSelectAsLayer when creating the window group. The behavior is now identical to Windows 3.6rc4 -- clicking on a child dialog activates it and brings its parent window to the front too, but the children always stays above the parent.
Silenio, please have a look. Then I have to figure out where it should be checked in. We will want this change for 3.6.1 as well.
The fix looks good to me.
Fixed in HEAD > 20100714.
.
Also fixed in 3.6 maintenance branch > 20100715.
