Windows 7 - Windows do not gain focus

[jrgreenman]

When I run this macro under Win 7 Home Premium, notepad starts, but does not gain focus:

 

<LAUNCH PROGRAM AND ACTIVATE WINDOW Title="Untitled - Notepad" Exact_Match="FALSE" Wildcards="FALSE" Path="C:\\WINDOWS\\notepad.exe" Mode="\x00" Default_Path="TRUE" Wait="2" Wait_For_Program="12"/>

 

Works fine under XP. Confirmed on two different Win 7 machines and two different user accounts.

 

Same thing for "Window Activate" command. It has no effect.

 

Jace

[paul]

Works perfectly for me under Windows 7 Home Premium.

BTW, I suggest removing the " - untitled" portion of the window name, leaving it simply as Notepad.

[jrgreenman]

Works perfectly for me under Windows 7 Home Premium.

BTW, I suggest removing the " - untitled" portion of the window name, leaving it simply as Notepad.

 

I've create a "Steps Recorder" file that shows the behavior. Here's the macro information I exported from MEP 4.1.7.1:

 

Name: Notepad
Icon: (Default)
HotKey: Win+N
Scope: Global
<LAUNCH PROGRAM AND ACTIVATE WINDOW Title="Notepad" Exact_Match="FALSE" Wildcards="FALSE" Path="C:\\WINDOWS\\notepad.exe" Mode="\x00" Default_Path="TRUE" Wait="0" Wait_For_Program="12"/>

 

And here's a thread complaining about the same thing (Windows 7 x64):

 

http://social.answers.microsoft.com/Forums/en-US/w7files/thread/a55aec2b-ee7e-40f2-bc8b-8f4728671ca4

 

So while MEP is affected by (or affecting) the behavior, it may not be causing it. Still, am wondering if anyone else has encountered it and if/how they solved it.

steps.zip

[chris]

I am very familiar with this particular issue as it's caused us a lot of grief since Microsoft started implementing this back in Windows 2000.

 

Essentially, the idea is that a program should not come up into the foreground unless you started it from Explorer (i.e. the start menu, an explorer window, etc.). That way your workflow is not interrupted when a background program launches another program.

 

Since Windows 2000, each version of Windows has a slight change to how this is implemented. We have some code in place to work around this, but it's not always 100% perfect.

 

Add to that fact, Vista and 7 added an additional quirk with the thumbnail previews of windows when you hover over their taskbar entries. In this case, the preview window is not marked as hidden and it has the same name as the window you're previewing. So, when we go to do our activation code, Windows will sometimes give us the preview window instead (most likely that's where your activations are going).

 

One way to get around this is to follow up your launch command with a "Window Activate" command. We've found this to be the most reliable solution as it gives Windows a moment to finish cleaning up after a program launch and then give us the correct window handle to activate.

 

Could you try that and let me know if it works any better?

[jrgreenman]

I am very familiar with this particular issue as it's caused us a lot of grief since Microsoft started implementing this back in Windows 2000.

 

Essentially, the idea is that a program should not come up into the foreground unless you started it from Explorer (i.e. the start menu, an explorer window, etc.). That way your workflow is not interrupted when a background program launches another program.

 

Since Windows 2000, each version of Windows has a slight change to how this is implemented. We have some code in place to work around this, but it's not always 100% perfect.

 

Add to that fact, Vista and 7 added an additional quirk with the thumbnail previews of windows when you hover over their taskbar entries. In this case, the preview window is not marked as hidden and it has the same name as the window you're previewing. So, when we go to do our activation code, Windows will sometimes give us the preview window instead (most likely that's where your activations are going).

 

One way to get around this is to follow up your launch command with a "Window Activate" command. We've found this to be the most reliable solution as it gives Windows a moment to finish cleaning up after a program launch and then give us the correct window handle to activate.

 

Could you try that and let me know if it works any better?

 

 

I tried both "Window Activate", following a Program Launch command, as well as "Launch Program and Activate Window", and while so far they appear to work in two other test cases (launching "calc" and "winword") neither works for launching "notepad".

 

I'll continue testing and see if adding in some Window Activate commands will bring some reliability back to my macros, but the failure of Notepad windows to respond to the "Window Activate" command under Win 7 x64 is puzzling, and suggests some other programs might misbehave in a similar fashion.

 

Thanks you for your response and especially the validation. Nice to know I'm not nuts...or at least that this isn't the reason why I am.

[paul]

Essentially, the idea is that a program should not come up into the foreground unless you started it from Explorer (i.e. the start menu, an explorer window, etc.). That way your workflow is not interrupted when a background program launches another program.

I don't understand what you mean here. Suppose I start MyProg.exe from a shortcut. Are you saying its future behaviour will differ from MyProg.exe started by double-clicking it from Explorer? I have written many, many programs and not once have I observed this behaviour. Please clarify.

 

Add to that fact, Vista and 7 added an additional quirk with the thumbnail previews of windows when you hover over their taskbar entries. In this case, the preview window is not marked as hidden and it has the same name as the window you're previewing. So, when we go to do our activation code, Windows will sometimes give us the preview window instead (most likely that's where your activations are going).

Would this problem be resolved if you captured the handle of a window when it was created, and if you then added the necessary commands to allow us to capture this id and use it to activate windows, etc.?

[chris]

I don't understand what you mean here. Suppose I start MyProg.exe from a shortcut. Are you saying its future behaviour will differ from MyProg.exe started by double-clicking it from Explorer? I have written many' date=' many programs and not once have I observed this behaviour. Please clarify.[/quote']

No, that's not what I'm saying. I used Explorer as an example, but what I really meant is that if a program is launched by a "background" program such as Macro Express (because the player is almost never the active window), then this problem will occur. If the program launch is caused by the foreground window, such as a user clicking on shortcut in Explorer, the desktop, etc. (as these actions are foreground tasks), then the problem won't occur. The idea is to not take focus away from what you are doing in the current foreground window.

 

Would this problem be resolved if you captured the handle of a window when it was created' date=' and if you then added the necessary commands to allow us to capture this id and use it to activate windows, etc.? [/quote']

Not necessarily. What we do to get around this is we figure out what the foreground window currently is and attach the macro's thread to that. Then we launch the window and call the "SetForegroundWindow" API. This has the effect of tricking Windows into thinking that the foreground window was the program that launched the new program and is requesting focus. In this situation, Windows will gladly let us set it to the foreground. If we didn't do that, then Windows would launch the program and then make the taskbar icon flash while leaving focus in the current foreground window.

 

I hope that was clear. If not, please let me know. I tend to have difficulty expressing myself when I get into technical details.

[jrgreenman]

At last I have found the magic Windows registry value that was causing this behavior. It is called "Foreground Lock timeout" and can be modified per this thread:

 

http://social.answers.microsoft.com/Forums/en-US/w7performance/thread/1199682e-2415-4a7a-bf21-f57a972122ee

 

I hope that helps others who were suffering as I was.

 

Jace

[terrypin]

BTW, I suggest removing the " - untitled" portion of the window name, leaving it simply as Notepad.

 

Paul: I'm curious about that suggestion from you, which I've seen you make several times before. Why? If anything, it seems rather better IMO to use the full string. That avoids any ambiguity with other windows that might include the string 'notepad'. Such as this one I have on my desktop right now after testing Jace's macro: Macro Express Pro - Script Editor [Notepad problem]

 

--

Terry, East Grinstead, UK

[paul]

Paul: I'm curious about that suggestion from you, which I've seen you make several times before. Why? If anything, it seems rather better IMO to use the full string. That avoids any ambiguity with other windows that might include the string 'notepad'. Such as this one I have on my desktop right now after testing Jace's macro: Macro Express Pro - Script Editor [Notepad problem]

The string "Notepad - Untitled" (FYI, on my Windows 7 system, the window is called "Untitled - Notepad") names 2 different states, one of which I surmise you're not interested in:

- "Notepad" is the name of the program or window you're interested in locating; all notepad windows contain this string

- "untitled" happens to be the name used for Notepad's initial unused window. Once you give this window a name, or if you open Notepad using an existing file, the name "untitled" disappears. Do you really want to tie your macro to Notepad only when it is in its initial state? In other words, you're including something which is probably not relevant to your macro, and which could change one day; it's something you have no control over, and which is probably not relevant to what you're trying to do.

 

IMHO, it simply removes a dependency you don't need - which therefore makes it better practice. It's a bit like using a variable type naming convention, e.g. tTextVar, nIntegerVar - it's not necessary, but it makes for more readable code.

 

Who knows? One day they may decide to change the name of this initial Notepad window to something else. That would catch you out, wouldn't it?

[terrypin]

Thanks Paul, understood.

 

It's pretty rare for me to apply a macro to Notepad anyway, as my text editor is TextPad. So it's usually been confined to thread discussions like this one, when I've always explicitly targeted the new window.

 

BTW, I've only just noticed that 'Untitled - Notepad' is itself ambiguous, because if you happen to open another one that too gets the same name! TextPad by contrast creates

'Latest - TextPad - [Document2]', etc.

 

--

Terry, East Grinstead, UK