I've been down this road. Not all platforms bring windows to the foreground properly. There's some discussions around the net about it here and there.
The only thing I found that works well across platforms was to dispose and re-create the shell. (keeping Data and GUI separate).
For example here I toggle between 'Gui', 'Progress bar' 'exit' states, and between each state shells are disposed and re-created:
It's a bit of a workaround, but that was the only thing I could find at the time. If you/anyone knows of a better solution, I'd be interested to hear.
From: "Marcel Bruch" <
marcel.bruch@xxxxxxxxxxxxxx>
To: platform-swt-dev@xxxxxxxxxxxSent: Saturday, February 7, 2015 2:56:53 AM
Subject: [platform-swt-dev] [mac] Different behavior of forceActive() under Mac and Linux/Windows
Hi SWT devs,
I’m seeking your advice for a dialog placement issue under Mac.
The error reporter we introduced in Mars M5 [1] uses a non-modal dialog to ask users to send error reports.
The dialog is shown whenever an error is logged to the Eclipse error log. When opening the dialog we check whether there is a modal dialog around (e.g, the preference dialog) and if so, we force this modal one to become active again (see the code below). The expected behavior is that the modal dialog comes to the top and is placed over the non-modal send dialog. This works as expected on Linux and Windows 7/8 but does not work on Mac 10.10. It seems that the call to shell.forceActive() is ignored completely and there is also no manual way to put the modal dialog on top.
I double-checked that both dialogs (modal and non-modal) have the same parent (the workbench shell).
When using null as parent of the non-modal dialog, it becomes visible after the modal dialog is closed (which is a bit weird because I’d expect it to be there already but just behind the modal one). But of course when I click on the workbench window the send dialog is moved behind the large workbench and a user just might not see it anymore - which is also not good.
The problem has been discussed in Bug 457115 [2] and in the forum before but we were not able to find a good solution yet. Does anyone of the SWT committers have an idea how to improve the situation?
Thanks,
Marcel
@Override
public int open() {
int returnCode = super.open();
reactivateModalShell();
return returnCode;
}
private void reactivateModalShell() {
Shell modal = Shells.getModalShellExcluding(getShell()).orNull();
if (modal != null) {
modal.forceActive();
}
}
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev
