How to open new windows at the top of z-order, when process is not current process ?
-
Is there a way to create a new window, which is brought to the front, from a process which is not the current process. On NT5 upwards, Windows does not allow processes which are not the current process to bring newly created windows to the front. AllowSetForegroundWindow() will work, but not on Win95/98 I need a method which works on Win95/WinNT4 upwards. Is this possible ?
-
Is there a way to create a new window, which is brought to the front, from a process which is not the current process. On NT5 upwards, Windows does not allow processes which are not the current process to bring newly created windows to the front. AllowSetForegroundWindow() will work, but not on Win95/98 I need a method which works on Win95/WinNT4 upwards. Is this possible ?
Try
SetWindowPos (&CWnd::wndTopMost, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);. /ravi My new year's resolution: 2048 x 1536 Home | Articles | Freeware | Music ravib@ravib.com -
Is there a way to create a new window, which is brought to the front, from a process which is not the current process. On NT5 upwards, Windows does not allow processes which are not the current process to bring newly created windows to the front. AllowSetForegroundWindow() will work, but not on Win95/98 I need a method which works on Win95/WinNT4 upwards. Is this possible ?
If i understand what you mean (you asking how to steal input focus on 2K/XP if a window belonging to another process has the focus) You need to attach your threads input Q to the active windows input Q - other wise as you say SetForgroundWindow does nothing. Like this: AttachThreadInput(GetWindowThreadProcessId(::GetForegroundWindow(),NULL), GetCurrentThreadId(),TRUE); SetForegroundWindow(); SetFocus(); AttachThreadInput(GetWindowThreadProcessId(::GetForegroundWindow(),NULL), GetCurrentThreadId(),FALSE); That will attach ure threads input Q to the input Q of the window with the foucs, steal the focus - which is now allowed, then detach it. I hope thats what u ment :o)
-
If i understand what you mean (you asking how to steal input focus on 2K/XP if a window belonging to another process has the focus) You need to attach your threads input Q to the active windows input Q - other wise as you say SetForgroundWindow does nothing. Like this: AttachThreadInput(GetWindowThreadProcessId(::GetForegroundWindow(),NULL), GetCurrentThreadId(),TRUE); SetForegroundWindow(); SetFocus(); AttachThreadInput(GetWindowThreadProcessId(::GetForegroundWindow(),NULL), GetCurrentThreadId(),FALSE); That will attach ure threads input Q to the input Q of the window with the foucs, steal the focus - which is now allowed, then detach it. I hope thats what u ment :o)
Diddy wrote: AttachThreadInput(GetWindowThreadProcessId(::GetForegroundWindow(),NULL), GetCurrentThreadId(),TRUE); SetForegroundWindow(); SetFocus(); AttachThreadInput(GetWindowThreadProcessId(::GetForegroundWindow(),NULL), GetCurrentThreadId(),FALSE); This is exactly what I want, thanks. Two questions though: Shouldn't the ThreadProcessId be stored when GetWindowThreadProcessId() is first called ? Otherwise, when you call it the second time, you are getting the ThreadProcessId of your apps window and not the original window, since it is no longer the Foreground Window. Also, will it not make the other app unstable, because by stealing the threads input for a short period, you are also stealing its' messages. This means that certain messages, received during the time that my app has the other apps thread input, will not be handled by the other app. Bit of a convoluted description, I know:o) Anyway, will it make the other app (or my app) unstable ? Thanks again for your help.
-
Diddy wrote: AttachThreadInput(GetWindowThreadProcessId(::GetForegroundWindow(),NULL), GetCurrentThreadId(),TRUE); SetForegroundWindow(); SetFocus(); AttachThreadInput(GetWindowThreadProcessId(::GetForegroundWindow(),NULL), GetCurrentThreadId(),FALSE); This is exactly what I want, thanks. Two questions though: Shouldn't the ThreadProcessId be stored when GetWindowThreadProcessId() is first called ? Otherwise, when you call it the second time, you are getting the ThreadProcessId of your apps window and not the original window, since it is no longer the Foreground Window. Also, will it not make the other app unstable, because by stealing the threads input for a short period, you are also stealing its' messages. This means that certain messages, received during the time that my app has the other apps thread input, will not be handled by the other app. Bit of a convoluted description, I know:o) Anyway, will it make the other app (or my app) unstable ? Thanks again for your help.
- Yes :o) Thats called me trying to attack the situation with copy and paste :o) Well spotted. 2) No. It's not stealing its input - its stealing - or rather sharing - its input states. Each thread has a number of states associated with all the windows it has created - such as the one that has the focus, and the curent cursor for each etc. When you call SetFocus, it says is the focus state set for our thread for at least one window we have created - if thats a no, it does nothing - if its a yes, it sets the focus to the window provided. AttachThreadInput simply combins the states for both threads, so thread A and thread B are now working with the same state - since you are attaching to the current forground window, your focus state is now set and you can change the focus to one of your own windows. In other words: defenestration wrote: This means that certain messages, received during the time that my app has the other apps thread input, will not be handled by the other app Isn't true - its nothing to do with the messages - just to do with certian states of the thread (specifically focus, active, capture windows, key state, queue status, and so on). It's the recomended way by MSDN anyway - and I have used it for ages with no stabality problems. One thing to be aware of - never put a break point between attaching and detacting. If you are debuging - you will be attaching to MSDEVS thread, and because your app is being debugged, you will be bascially freeze the debugger. Hope it helps
-
- Yes :o) Thats called me trying to attack the situation with copy and paste :o) Well spotted. 2) No. It's not stealing its input - its stealing - or rather sharing - its input states. Each thread has a number of states associated with all the windows it has created - such as the one that has the focus, and the curent cursor for each etc. When you call SetFocus, it says is the focus state set for our thread for at least one window we have created - if thats a no, it does nothing - if its a yes, it sets the focus to the window provided. AttachThreadInput simply combins the states for both threads, so thread A and thread B are now working with the same state - since you are attaching to the current forground window, your focus state is now set and you can change the focus to one of your own windows. In other words: defenestration wrote: This means that certain messages, received during the time that my app has the other apps thread input, will not be handled by the other app Isn't true - its nothing to do with the messages - just to do with certian states of the thread (specifically focus, active, capture windows, key state, queue status, and so on). It's the recomended way by MSDN anyway - and I have used it for ages with no stabality problems. One thing to be aware of - never put a break point between attaching and detacting. If you are debuging - you will be attaching to MSDEVS thread, and because your app is being debugged, you will be bascially freeze the debugger. Hope it helps
Diddy wrote: Hope it helps It certainly has. Thanks for the explanation Diddy!