How do you force a java swt program to "move itself to the foreground"?

Currently with swt, I sometimes want a program to arbitrarily come to the foreground (like an alarm clock might).

Typically the following works (jruby):

@shell.setMinimized(false)
@shell.forceActive

This brings the shell to the front if it was minimized.

Creating a new shell at any time also brings the (new shell) to the front.

So far so good, however, if the shell is not minimized, the above code just flashes (blinks) the app's icon in the taskbar. Well actually the first time you run it, it brings it to the front. After that, it just blinks in the taskbar. That's windows. On Linux it appears to only blink in the taskbar (ubuntu default).

Does anybody know of a cross platform way of getting the app to come to the front, in swt?

It seems that no incantation of forceActive setAct开发者_如何学JAVAive setMinimized(false) setFocus forceFocus and setVisible can accomplish this thing.

I'm pretty sure it is possible (at least in windows), as the E Text Editor does it. Well, that's not swt, but at least some other apps have been known to do it.

I'm thinking maybe this is swt bug 192036?

Many thanks.

Related:

• How to bring a window to the front?
• Opening a Shell
• Keep window in foreground (even if it loses focus)
• Bug 244597 - Cannot activate shell programatically on gtk
• Need to bring application to foreground on Windows
• How to bring a window to the front? this swing example might be some type of clue, too...

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

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();
        }
    });
}

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.

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);
  }

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();
            }
        }
    }

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();
    }
});