I would like to set focus to a window with a function call without raising 
that window to the foreground.

It is possible to make this behavior happen by moving the mouse if 
SetActiveWindowTracking is on, so Windows is capable of doing it.  The 
question is, is there a way for an application to do it by calling a function?

On Jul 14, 4:03 am, ArchibaldMartel
 wrote:
> I would like to set focus to a window with a function call without raising
> that window to the foreground.
>
> It is possible to make this behavior happen by moving the mouse if
> SetActiveWindowTracking is on, so Windows is capable of doing it.  The
> question is, is there a way for an application to do it by calling a function?



Hi,

You can use the following API to set the keyboard focus
to the specified window:

	SetFocus()

http://msdn.microsoft.com/en-us/library/ms646312(VS.85).aspx

Kellie.

No, that doesn't do what I described because SetFocus not only sets focus but 
also raises the specified window to the foreground.

"Kellie Fitton" wrote:

> On Jul 14, 4:03 am, ArchibaldMartel
>  wrote:
> > I would like to set focus to a window with a function call without raising
> > that window to the foreground.
> >
> > It is possible to make this behavior happen by moving the mouse if
> > SetActiveWindowTracking is on, so Windows is capable of doing it.  The
> > question is, is there a way for an application to do it by calling a function?
> 
> 
> 
> Hi,
> 
> You can use the following API to set the keyboard focus
> to the specified window:
> 
> 	SetFocus()
> 
> http://msdn.microsoft.com/en-us/library/ms646312(VS.85).aspx
> 
> Kellie.
> 
>

ArchibaldMartel wrote:
> I would like to set focus to a window with a function call without raising 
> that window to the foreground.
> 
> It is possible to make this behavior happen by moving the mouse if 
> SetActiveWindowTracking is on, so Windows is capable of doing it.  The 
> question is, is there a way for an application to do it by calling a function?

Look at SetWindowPos()

-- 
Dean Earley (dean.earley@icode.co.uk)
i-Catcher Development Team

iCode Systems

What combination of flags are you thinking of?  I don't see any obvious way 
to use SetWindowPos for this purpose, and the documentation for that function 
says:

"An application cannot activate an inactive window without also bringing it 
to the top of the Z order. "

"Dean Earley" wrote:

> Look at SetWindowPos()
> 
> -- 
> Dean Earley (dean.earley@icode.co.uk)
> i-Catcher Development Team
> 
> iCode Systems
>

On Jul 14, 11:57 am, ArchibaldMartel
 wrote:
> What combination of flags are you thinking of?  I don't see any obvious way
> to use SetWindowPos for this purpose, and the documentation for that function
> says:
>
> "An application cannot activate an inactive window without also bringing it
> to the top of the Z order. "

What are you trying to do? Perhaps if we had a better idea of that it
would
be easier to suggest an alternate approach.

The reason SetFocus brings the window to the front is so the user can
see
where the input is going and get visual feedback so they can correct
mistakes.
It's actually a little frustrating for a user to be not be sure if
their input is not
only correct but even if it is reaching the correct destination.

----
Geoff

On Jul 14, 8:31 am, ArchibaldMartel
 wrote:
> No, that doesn't do what I described because SetFocus not only sets focus but
> also raises the specified window to the foreground.
>


Hi,

The API SetFocus() does not raise a window to the foreground,
it only sets the focus for that particular window.  To raise a window
to the foreground, a function must put the thread that created the
specified window into the foreground and activates the window,
and that's what the API  SetForegroundWindow() does:

http://msdn.microsoft.com/en-us/library/ms633539(VS.85).aspx

Kellie.

On Mon, 14 Jul 2008 04:03:02 -0700, ArchibaldMartel
 wrote:

>I would like to set focus to a window with a function call without raising 
>that window to the foreground.

The SetFocus function returns a handle that had focus before the
function call. Perhaps you can call SetFocus to show one window, keep
the handle returned by that call, and then use it in a call to
SetFocus that will the original window back in focus.


-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
20 Park Plaza, Suite 478
Boston, MA 02116
www.penfact.com

Regardless of what the documentation says, SetFocus moves the window (or its 
top-level parent) to the top of the Z-order.  Try it if you don't believe me.

I need a way to set focus without altering the Z-order.

"Kellie Fitton" wrote:

> On Jul 14, 8:31 am, ArchibaldMartel
>  wrote:
> > No, that doesn't do what I described because SetFocus not only sets focus but
> > also raises the specified window to the foreground.
> >
> 
> 
> Hi,
> 
> The API SetFocus() does not raise a window to the foreground,
> it only sets the focus for that particular window.  To raise a window
> to the foreground, a function must put the thread that created the
> specified window into the foreground and activates the window,
> and that's what the API  SetForegroundWindow() does:
> 
> http://msdn.microsoft.com/en-us/library/ms633539(VS.85).aspx
> 
> Kellie.
> 
>

Yes, I can restore things to the way they were before the call.  
Unfortunately that does not solve my problem.   I need to do what I described 
in my first message -- set focus without a change in Z-order.

"r_z_aret@pen_fact.com" wrote:

> On Mon, 14 Jul 2008 04:03:02 -0700, ArchibaldMartel
>  wrote:
> 
> >I would like to set focus to a window with a function call without raising 
> >that window to the foreground.
> 
> The SetFocus function returns a handle that had focus before the
> function call. Perhaps you can call SetFocus to show one window, keep
> the handle returned by that call, and then use it in a call to
> SetFocus that will the original window back in focus.
> 
> 
> -----------------------------------------
> To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).
> 
> Robert E. Zaret, eMVP
> PenFact, Inc.
> 20 Park Plaza, Suite 478
> Boston, MA 02116
> www.penfact.com
>

> What are you trying to do? Perhaps if we had a better idea of that it
> would
> be easier to suggest an alternate approach.

I'm injecting keystrokes into several different windows in very rapid 
succession with SendInput.     This is part of a utility for gamers who play 
several instances of the same game simultaneously.

Timing is very important here.   When focus is changed with SetFocus, 
SetActiveWindow, or SetForegroundWindow, the operating system redraws part of 
the screen.  This is slow enough to be a problem for what I'm trying to do.

However, when SetActiveWindowTracking is on and the user changes focus with 
the mouse, there is practically no redrawing and focus changes faster.

I want to do that second sort of focus change programmatically. 

> It's actually a little frustrating for a user to be not be sure if
> their input is not
> only correct but even if it is reaching the correct destination.

This is not a problem with this application.

"Geoffrey Summerhayes" wrote:

> On Jul 14, 11:57 am, ArchibaldMartel
>  wrote:
> > What combination of flags are you thinking of?  I don't see any obvious way
> > to use SetWindowPos for this purpose, and the documentation for that function
> > says:
> >
> > "An application cannot activate an inactive window without also bringing it
> > to the top of the Z order. "
> 
> What are you trying to do? Perhaps if we had a better idea of that it
> would
> be easier to suggest an alternate approach.
> 
> The reason SetFocus brings the window to the front is so the user can
> see
> where the input is going and get visual feedback so they can correct
> mistakes.
> It's actually a little frustrating for a user to be not be sure if
> their input is not
> only correct but even if it is reaching the correct destination.
> 
> ----
> Geoff
>

On Jul 14, 1:55 pm, ArchibaldMartel
 wrote:
> > What are you trying to do? Perhaps if we had a better idea of that it
> > would
> > be easier to suggest an alternate approach.
>
> I'm injecting keystrokes into several different windows in very rapid
> succession with SendInput.     This is part of a utility for gamers who play
> several instances of the same game simultaneously.
>
> Timing is very important here.   When focus is changed with SetFocus,
> SetActiveWindow, or SetForegroundWindow, the operating system redraws part of
> the screen.  This is slow enough to be a problem for what I'm trying to do.
>
> However, when SetActiveWindowTracking is on and the user changes focus with
> the mouse, there is practically no redrawing and focus changes faster.
>
> I want to do that second sort of focus change programmatically.
>
> > It's actually a little frustrating for a user to be not be sure if
> > their input is not
> > only correct but even if it is reaching the correct destination.
>
> This is not a problem with this application.

Sounds like you'd be better off with system hooks, although getting
them working under Vista is more of a problem due to security issues.

----
Geoff

> Sounds like you'd be better off with system hooks, although getting
> them working under Vista is more of a problem due to security issues.

Which system hook do you have in mind and how would it help?  The program 
already has a low-level keyboard hook.   So far as I know, there's no way to 
use it to direct input to a particular window.  Please tell me if I'm wrong.  
I would be very happy to be wrong.

What would help me most, I think, is if somebody here knows how 
SetActiveWindowTracking is written.  As I've said several times in this 
thread, it allows the mouse to do what I want to do programmatically.  It may 
just happen to be the case that SetActiveWindowTracking uses undocumented 
functions that I can call from an app.   If so, and if somebody can tell me, 
my problem would be solved 100%.

"Geoffrey Summerhayes" wrote:

> On Jul 14, 1:55 pm, ArchibaldMartel
>  wrote:
> > > What are you trying to do? Perhaps if we had a better idea of that it
> > > would
> > > be easier to suggest an alternate approach.
> >
> > I'm injecting keystrokes into several different windows in very rapid
> > succession with SendInput.     This is part of a utility for gamers who play
> > several instances of the same game simultaneously.
> >
> > Timing is very important here.   When focus is changed with SetFocus,
> > SetActiveWindow, or SetForegroundWindow, the operating system redraws part of
> > the screen.  This is slow enough to be a problem for what I'm trying to do.
> >
> > However, when SetActiveWindowTracking is on and the user changes focus with
> > the mouse, there is practically no redrawing and focus changes faster.
> >
> > I want to do that second sort of focus change programmatically.
> >
> > > It's actually a little frustrating for a user to be not be sure if
> > > their input is not
> > > only correct but even if it is reaching the correct destination.
> >
> > This is not a problem with this application.
> 
> Sounds like you'd be better off with system hooks, although getting
> them working under Vista is more of a problem due to security issues.
> 
> ----
> Geoff
>

Is it an option to send input messages like WM_KEYDOWN and 
WM_LBUTTONDOWN directly to the control?

ArchibaldMartel wrote:
>> Sounds like you'd be better off with system hooks, although getting
>> them working under Vista is more of a problem due to security issues.
> 
> Which system hook do you have in mind and how would it help?  The program 
> already has a low-level keyboard hook.   So far as I know, there's no way to 
> use it to direct input to a particular window.  Please tell me if I'm wrong.  
> I would be very happy to be wrong.
> 
> What would help me most, I think, is if somebody here knows how 
> SetActiveWindowTracking is written.  As I've said several times in this 
> thread, it allows the mouse to do what I want to do programmatically.  It may 
> just happen to be the case that SetActiveWindowTracking uses undocumented 
> functions that I can call from an app.   If so, and if somebody can tell me, 
> my problem would be solved 100%.
> 
> "Geoffrey Summerhayes" wrote:
> 
>> On Jul 14, 1:55 pm, ArchibaldMartel
>>  wrote:
>>>> What are you trying to do? Perhaps if we had a better idea of that it
>>>> would
>>>> be easier to suggest an alternate approach.
>>> I'm injecting keystrokes into several different windows in very rapid
>>> succession with SendInput.     This is part of a utility for gamers who play
>>> several instances of the same game simultaneously.
>>>
>>> Timing is very important here.   When focus is changed with SetFocus,
>>> SetActiveWindow, or SetForegroundWindow, the operating system redraws part of
>>> the screen.  This is slow enough to be a problem for what I'm trying to do.
>>>
>>> However, when SetActiveWindowTracking is on and the user changes focus with
>>> the mouse, there is practically no redrawing and focus changes faster.
>>>
>>> I want to do that second sort of focus change programmatically.
>>>
>>>> It's actually a little frustrating for a user to be not be sure if
>>>> their input is not
>>>> only correct but even if it is reaching the correct destination.
>>> This is not a problem with this application.
>> Sounds like you'd be better off with system hooks, although getting
>> them working under Vista is more of a problem due to security issues.
>>
>> ----
>> Geoff
>>

"Ivo Beltchev" wrote:

> Is it an option to send input messages like WM_KEYDOWN and 
> WM_LBUTTONDOWN directly to the control?
> 

Yes, the program does that now.  Unfortunately this method has several 
deficiencies:

(a)  It doesn't work with many games.

(b) It's difficult to make the target game apply a desired modifier state 
(shift, alt, ctrl) to injected keystrokes.

"ArchibaldMartel"  wrote in 
message news:3FCF355E-FF7A-4E20-9897-100F0E5783BF@microsoft.com...
>> What are you trying to do? Perhaps if we had a better idea of that it
>> would
>> be easier to suggest an alternate approach.
>
> I'm injecting keystrokes into several different windows in very rapid
> succession with SendInput.     This is part of a utility for gamers who 
> play
> several instances of the same game simultaneously.
>
> Timing is very important here.   When focus is changed with SetFocus,
> SetActiveWindow, or SetForegroundWindow, the operating system redraws part 
> of
> the screen.  This is slow enough to be a problem for what I'm trying to 
> do.
>
> However, when SetActiveWindowTracking is on and the user changes focus 
> with
> the mouse, there is practically no redrawing and focus changes faster.
>
> I want to do that second sort of focus change programmatically.

    How about disabling redraws by sending each window a WM_SETREDRAW 
message, change focus and send your keystrokes, and then re-enable redraws?

-- 

- Gary Chanson (Windows SDK MVP)
- Abolish Public Schools

Not quite the same question, but you might check a current thread
called "Restore a window WITHOUT activation" in this newsgroup.

On Mon, 14 Jul 2008 04:03:02 -0700, ArchibaldMartel
 wrote:

>I would like to set focus to a window with a function call without raising 
>that window to the foreground.
>
>It is possible to make this behavior happen by moving the mouse if 
>SetActiveWindowTracking is on, so Windows is capable of doing it.  The 
>question is, is there a way for an application to do it by calling a function?

-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
20 Park Plaza, Suite 478
Boston, MA 02116
www.penfact.com

Setting focus without activiation is really contradictory with the way 
Windows is designed.

One way to solve the problem is to not send keystrokes. Sending keystrokes 
sounds easy until you encounter the type of problem you have encountered. 
Some examples are:

    - If you need to change the value in an edit control, update the text 
directly instead of sending keystrokes to the control.

    - If you need to click a button, send a button clicked message 
(notification). Note that a button clicked notification goes to the parent 
of the button.

    - If you need to do a menu item, send the command directly.

This might require extra research to accomplish, but it will be much more 
reliable (nearly perfect reliability) and provide better performance.



"ArchibaldMartel"  wrote in 
message news:83A7C83D-3854-4E89-A10C-E388FBC59765@microsoft.com...
>I would like to set focus to a window with a function call without raising
> that window to the foreground.
>
> It is possible to make this behavior happen by moving the mouse if
> SetActiveWindowTracking is on, so Windows is capable of doing it.  The
> question is, is there a way for an application to do it by calling a 
> function?
>