Community
Participate
Working Groups
Using either Shell.forceActive or Shell.setActive doesn't consistently raise the shell above all other applications' windows. The below snippet open a shell and calls forceActive on it every 5 seconds. If you run the application and place another window on top (I used a Windows Explorer window), the SWT shell will not raise above that window. Instead the shell's entry in the task bar will flash. When I use setActive instead of forceActive, the shell will raise above the Windows Explorer window once. But if I put the Windows Explorer window back on top, the setActive call will not raise the shell again. public class FocusTest { public static void main (String [] args) { final Display display = new Display (); final Shell shell = new Shell (display); shell.open (); Timer t = new Timer (); TimerTask task = new TimerTask () { @Override public void run () { display.asyncExec (new Runnable () { public void run () { shell.forceActive (); } }); } }; int time = 5000; t.scheduleAtFixedRate (task, 0, time); while (!shell.isDisposed ()) { if (!display.readAndDispatch ()) display.sleep (); } t.cancel (); display.dispose (); } } System information: OS : Win XP Pro Java : jdk1.5.0_07 SWT : 3.2.2.v3236b
Shell.forceActive() makes the Windows API call SetForegroundWindow() (http://msdn2.microsoft.com/en-us/library/ms633539.aspx). This call has all sorts of restrictions every application must live with. I'm not sure that there's much we can do about this, other that try to figure out ways to outfox SetForegroundWindow(). I'm leaning towards WONTFIX.
appears from (a link at the bottom of) the msdn link that what you need to do is something like this C code (basically, if you're not the foreground window, temporarily attach to it via AttachThreadInput, then unattach. Doesn't look impossible... HWND __LINKAGE_WMD __stdcall ForceForegroundWindow(HWND hTo) { if (!hTo) return(NULL); HWND hFrom=GetForegroundWindow(); if (!hFrom) { SetForegroundWindow(hTo); return(NULL); } if (hTo==hFrom) return(NULL); DWORD pid=GetWindowThreadProcessId(hFrom,0); if (_threadid==pid) { SetForegroundWindow(hTo); return(hFrom); } if (pid) { if (!AttachThreadInput(_threadid,pid,true)) return(NULL); SetForegroundWindow(hTo); AttachThreadInput(_threadid,pid,false); } return(hFrom); }
appears from experimentation that sometimes (with the work around), it brings the window forward, but only to just "behind" the active window. To actually get it to come to the front you need to run the code, then an additional setActive afterwards (not quite sure why forceActive doesn't run one already, anyway). http://stackoverflow.com/questions/2315560/how-do-you-force-a-java-swt-program-to-move-itself-to-the-foreground
based on Rogers C Code i just wrote the following _workaround_ 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); } as long as there is no solution to the force focus issue this workaround maybe helps. !!but pls keep in mind that in this workaround we use an API which is marked as "Discouraged access"!! Alois
(In reply to comment #4) > as long as there is no solution to the force focus issue this workaround maybe > helps. What is really the problem you are trying to fix ? What is this force focus issue ? > !!but pls keep in mind that in this workaround we use an API which is marked as > "Discouraged access"!! Personally I rather not fix this bug. There is a good reason SetForegroundWindow() doesnt work all the time: forcing popup windows are bad design (they are really annoying). Would something like this Bug 304922 work you ?
like roger i wanted to solve the issue that forceActive doesn't bring a shell to the front (at least not always - often the window just flashes in the taskbar) i understand the problem with popups and agree that one should try to avoid to use this functionality but there are also cases were this behaviour is a requirement! for instance the project i currently work on has this requirement. they want to replace an old crm system gradually, some tasks are handled by an eclipse rcp application, others by the old system. another non functional requirement is to save time (money). so they don't accept that the user has to switch applications by using the mouse (they one to save every single click they can) .... Alois
Is this not fixed yet? I'm using eclipse 3.7 on Windows 7 and still have the same problem. When window is minimized it is brought to the top by the following code shell().setMinimized(false); shell.forceActive(); but not when otherwise. The code Aloise provided works though but is just workaround. /Olof
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Can this be fixed? It would be nice to be able to put a shell to foreground without any hacks.
Strange, we have the problem, that our SWT application erratically brings itself into foreground on Windows 10 if a control is focused using setFocus() while we are working in another application (e.g. IDE saving a file in a watched directory).
(In reply to Thomas Singer from comment #10) > Strange, we have the problem, that our SWT application erratically brings > itself into foreground on Windows 10 if a control is focused using > setFocus() while we are working in another application (e.g. IDE saving a > file in a watched directory). The difference here is that in your case the Shells are all connected to the same thread, while in this bug the Shells are connected to different threads. In that case, there must be a connection to the other thread. https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setfocus """By using the AttachThreadInput function, a thread can attach its input processing to another thread. This allows a thread to call SetFocus to set the keyboard focus to a window attached to another thread's message queue."""
How is it possible with SWT to operate on controls/shells from different threads? Until now I had the impression that all operations need to be performed in the (single) GUI thread (usually the one where `main` was started).
(In reply to Thomas Singer from comment #12) > How is it possible with SWT to operate on controls/shells from different > threads? Until now I had the impression that all operations need to be > performed in the (single) GUI thread (usually the one where `main` was > started). There is a single SWT/UI thread for each process, e.g., when you fire up two Eclipse instances there are two UI threads, one in each process. Every independent process has its own UI thread.
