Currently with swt, I sometimes want a program to arbitrarily come to the foreground (like an alarm clock might).
Typically the following works (jruby):
There is a way to make it work with what you initially tried. You actually need to call shell.setMinimized(false)
and after that shell.setActive()
to restore the previous state of the shell
. However, that only works if the shell
was truely in the minimized state. So here is my final solution, which artificially minimizes the shell
if it was not minimized already. The cost is a quick animation if the minimization has to be done.
shell.getDisplay().syncExec(new Runnable() {
@Override
public void run() {
if (!shell.getMinimized())
{
shell.setMinimized(true);
}
shell.setMinimized(false);
shell.setActive();
}
});
Bug 192036 - Shell.forceActive doesn't raise a window above all other windows
@rogerdpack's query on Eclipse bug tracker was answered with the following dirty workaround doing what we need.
public void forceActive(Shell shell) {
int hFrom = OS.GetForegroundWindow();
if (hFrom <= 0) {
OS.SetForegroundWindow(shell.handle);
return;
}
if (shell.handle == hFrom) {
return;
}
int pid = OS.GetWindowThreadProcessId(hFrom, null);
int _threadid = OS.GetWindowThreadProcessId(shell.handle, null);
if (_threadid == pid) {
OS.SetForegroundWindow(shell.handle);
return;
}
if (pid > 0) {
if ( !OS.AttachThreadInput(_threadid, pid, true)) {
return;
}
OS.SetForegroundWindow(shell.handle);
OS.AttachThreadInput(_threadid, pid, false);
}
OS.BringWindowToTop(shell.handle);
OS.UpdateWindow(shell.handle);
OS.SetActiveWindow(shell.handle);
}
This worked for me on Windows 7 and Ubuntu:
private void bringToFront(final Shell shell) {
shell.getDisplay().asyncExec(new Runnable() {
public void run() {
shell.forceActive();
}
});
}
http://github.com/rdp/redcar/commit/d7dfeb8e77f13e5596b11df3027da236f23c83f0
shows how I did it in windows, anyway (using ffi).
A couple of helpful tricks "may" be
add a 'sleep 0.1' after the BringToFront.SetForegroundWindow(wanted) call (hopefully this one isn't actually necessary).
add a shell.set_active after you have brought the window to the foreground. For some reason forceActive doesn't call setActive.
NB that setActive does a user32.dll BringWindowToTop call, and needs to be done before you detach thread input.
Note also that it appears if you can do you calls in the right order you may not need to use the thread input hack at all (?)
http://betterlogic.com/roger/?p=2950
(contains several good hints on how to actually do this right)
On Linux, forceActive does work--but only until you move to another few windows,, then it blinks in the taskbar after that (only). Guessing swt bug. [1]
Also related:
How to bring a window to the front?
http://github.com/jarmo/win32screenshot/blob/master/lib/win32/screenshot/bitmap_maker.rb#L110 "set_foreground" which seems to work with both xp and windows 7
[1] Need to bring application to foreground on Windows and https://bugs.eclipse.org/bugs/show_bug.cgi?id=303710
private static void onTop(Shell shell) {
int s = -1;
Shell[] shells = display.getShells();
for (int i = 0; i < shells.length; ++i) {
if (!shells[i].equals(shell)) {
shells[i].setEnabled(false);
shells[i].update();
} else {
s = i;
}
}
while (!shell.isDisposed()) {
if (!display.readAndDispatch())
display.sleep();
}
for (int i = 0; i < shells.length; ++i) {
if (i != s) {
shells[i].setEnabled(true);
shells[i].update();
}
}
}
This is actually a feature of Windows, which can be enabled via the Tweak UI power toy (at least for Windows XP). When enabled the O/S deliberately prevents a window from forcing itself to be the focused window to stop it "stealing focus". As such, the action to grab focus is changed to just flashing the taskbar icon - since the O/S is deliberately converting the action at the user's request, there will be nothing you can do about it (and this is a good thing).
This was (probably) done because so many applications abused the bring-to-front API and the behavior both annoyed users and caused them to input into the wrong application.