Project: SWT
Bug 200153 Provide AllowSetForegroundWindow in org.eclipse.swt.internal.win32.OS
Reported: 2007-08-16 03:27:44 | Status: resolved fixed

Since Windows restricts the processes that can set the foreground window, opening a new workbench window while an RCP application is in the background or is minimized does not bring newly created windows to the foreground. An example scenario in which such a problem is exhibited is an RCP application which restricts itself to a single instance and opens a new workbench window on each attempt to start a new instance while one is already running. Registering a specific file type on Windows with a specific application and trying to open a file of the type in question by double-clicking it in Windows Explorer is a common reproduction of the described scenario. Because double-clicking a file in Windows Explorer mandates that the workbench window of the RCP application is not the foreground one, the newly created workbench window will open in the background and will not become the foreground window. In many situations the described behavior is considered problematic and unconventional for Windows. The feature request of this bug report is based on the availability of the Win32 API function AllowSetForegroundWindow. In the long run, it's probably best that a solution to this problem is offered by org.eclipse.swt.widgets.Shell because it is a part of the public API of SWT. However, it may be initially enough to have AllowSetForegroundWindow in org.eclipse.swt.internal.win32.OS. Because AllowSetForegroundWindow is part of the public Win32 API (of recent Windows versions), using reflection to check its presence in the mentioned class and then invoking it will allow clients to provide better integration of their RCP applications. An example patch introducing AllowSetForegroundWindow to org.eclipse.swt.internal.win32.OS is attached to this bug report.

Files changed in fix:
bundles/org.eclipse.swt/Eclipse SWT PI/win32/org/eclipse/swt/internal/win32/OS.java