Community
Participate
Working Groups
Build ID: 3.2.2 Steps To Reproduce: 1. On SLED10, on an application window, bring up a drop down shell that has SWT.ON_TOP style bit. 2. From the drop down shell, bring up a modal dialog like jface/InputDialog or SWT/MessageBox. 3. The dialog pops up in front of the drop down shell. 4. Click on the dialog and start dragging on the dialog, the dialog goes behind the drop down shell right away. Expected result: the dialog should stay in front of the drop down shell all the time no matter clicking or dragging on the dialog. Actual result: Once click on the dialog, the drop down shell (with SWT.ON_TOP style bit) goes to the front right away. The dialog displays behind the drop down shell. More information: 1. This behavior is only on SLED10. On Windows, the dialog always stays in front of the drop down shell. 2. This problem happens to any modal dialog like jface/InputDialog or SWT/MessageBox. 3. This problem may be related to PR#173218, which is a feature request for SWT to support ModalityListener interface. 4. Will provide a snippet to demo the problem.
Created attachment 58479 [details] Snippet to demo the dialog going behind ON_TOP shell on SLED10 To bring up the dialog when running the snippet, please right mouse click on the drop down shell.
Mei - I looked into this today and there doesn't seem to be a way to parent a dialog with an ON_TOP shell in GTK. This led to a discussion about the intended use of ON_TOP shells which prompts me to ask: why are you wanting to have a dialog parented by an ON_TOP shell? We're curious as to what your use case is and if there is another way that you can implement your code without having to rely on the ON_TOP style hint.
The shell that uses the ON_TOP bit is for a custom menu in our case. I can do without the ON_TOP style bit on Windows. But on Linux, I need to add the ON_TOP style bit to the shell of the custom menu for two reasons: 1. to avoid extra task items to display on the taskbar. When display the first root menu, one more task item is added to the taskbar in addition to the application's task item. Then when navigate down one level of submenu, another one task item is added to the task bar, etc.. Only when adding the ON_TOP bit to the shell of the custom menu, no more task item is added to the taskbar. 2. On RHEL4, without the ON_TOP bit, when navigate down a couple levels of submenus, the application quits because of some XWindow error. Let me add the error message tomorrow since it's not on hand now. In our use case, we bring up a context menu based on the selected menu item. When user clicks on the context menu item "Rename", the "Rename" InputDialog comes up with the custom menu staying up. User modifies the menu item label and clicks OK to dismiss the InputDialog. Then the modified menu item label is changed right away on the custom menu. However, when user tries to drag the InputDialog, the InputDialog goes to behind the custom menu.
Here is the crash error reported on REHL4 when navigate down a few levels of submenus: The program 'DefaultPlatform' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 26105 error_code 8 request_code 42 minor_code 0) This error does not happen on SLED10. So on SLED10, only the reason 1 (creating extra task items on taskbar for each custom menu coming up) made it necessary to use the ON_TOP bit. But on RHEL4, both reasons 1 and 2 made this a must to avoid the problems. On Windows, I don't see any of these 2 problems and hence the ON_TOP bit can be optional to use.
Can you attach some screenshots of your custom menu workflow? Does this represent an accurate summary of your desired workflow: 1. User selects an item from a regular menu. 2. A context menu pops up. 3. The user selects some action from the context menu. The action might open a dialog which requires the user to input some text. You want the context menu to stay open underneath while this dialog is open.
Here is a patch that will free you from having to use the ON_TOP style bit to stop a window with no trim from showing up in the tray. You can now create a window with SWT.NO_TRIM or SWT.NONE etc. to serve as your custom menu.
Created attachment 62141 [details] Patch to disable taskbar hints for windows with no trim
Fixed in HEAD > 20070327
Wait a second, modal windows still open behind ON_TOP windows. The patch allows Mei to avoid ON_TOP shells, but doesn't fix the problem.
Are we committing to addressing this for 3.3M7 ? If so, pls retain a patch for the change, and pls provide some risk assessment for a 3.3M6 backport.
No, we can't fix the bug that this report is talking about for 3.3, but we have stopped ON_TOP shells from appearing in task bar, which is the reason that Mei was using ON_TOP in the first place. We should really open a new bug for that, add Mei to it, attach the patch and mark that one as fixed. Your thoughts?
Fine by me, if Mei also acknowledges the resolution.
I am fine with Steve's suggestion. However, I still need to use the ON_TOP style bit because without the ON_TOP sytle bit, the custom menu navigation on RHEL4 would crash. Please see the error message in Comment #4. This does not happen on SELD10. I can try to gather more information on this problem on RHEL4 and open another bug report for that. But really thanks for fixing the task item problem. This will help to some extent.
OK, please open a new bug report for the RHEL4 X Window error you're getting and we can track that.
One more thing I wanted to mention before you open a new RHEL 4 bug. It would be great if we could get a stack trace from you for the crash you are getting on RHEL4. You can get more info about the crash if you set the Device.DEBUG flag: Device.DEBUG = true; //add the line before you create the Display For example: Device.DEBUG = true; Display display = new Display(); Shell shell = new Shell(); etc. This will print out the stack trace when you get the X Window Error message. If you could change your code and reproduce the problem, it could help us pinpoint what's going wrong on RHEL 4.
The snippet runs as expected for me. SLED10 is no longer supported for Oxygen.
