Wait for Window Title Issue

[dougb1]

Hi All,

 

Scenario. Program A puts a bit of data onto the clipboard and displays a window. When the user sees the window created by Program A, they press F9 to activate the MacroExpress macro. ME macro gets data off clipboard and parses out what it needs. It then uses Activate Window followed by Wait For Window Title to ensure that Application B has focus. It then sends some keystrokes via Text Type to activate a search dialog from the menus in Application B which has a title of "Input". The macro then uses Activate Window "Input" and Wait for Window Title "Input" before sending keystrokes to the window to perform the search from the clipboard data.

 

Problem: On occasion, the Input window isn't detected. This tells me that either the keystrokes to Program B didn't get there to activate the window or because of a timing issue, not all the keystrokes made it to Program B. I added debugging to a log file as well as added LogErrors at the top of the macro. The macro is aborting stating 'The window "Input" did not appear within the specified time.'. I have a message written to the debug log file immediately after I do the Wait For Window Title of Program B so I'm pretty confident that Program B had/has focus immediately before sending the text to bring up the search dialog "Input".

 

 

Questions:

1. Is Wait for Window Title the best way to know that a particular window has focus and is ready to accept keystrokes? We had only Activate Window before and I added Wait for Window Title to ensure the app was available to accept keystrokes. I've got the max wait time set to 8 seconds (up from 5) with no change. We used to have the default of 10 minutes and still experienced the problem so I don't think it's the wait length.

2. I tried using GetControl as follows to avoid sending keystrokes to activate the Input window. The control is a general search box always on the screen that does the same thing as the Input box I have to send keystrokes to in order to display:

Activate Window: "FACS Workstation (BDEBT)"

Get Control %C8% (FACS Workstation (BDEBT): WindowsForms10.EDIT.app3)

Set Focus to %C8%

Text Type: Text<ENTER>

This fails on the Set Focus line stating "The specified control could not be found". I used the Get control utility to detect the control. This would be the preferred way to send the information to Program B. Am I missing something in order to send keystrokes to the control?

 

Regarding #1, I've added in a hard Wait of 75MS before sending the keystrokes and slowed down the keystrokes to 50 MS but the problem is still happening (perhaps a little better but not foolproof).

 

I've also added new code to write all the visible windows to the debug file - I'm curious if Input really does exist or not. I would expect to NOT see Input in the list of window titles.

 

Thanks,

Doug

[acantor]

Hello Doug,

 

All I can tell you is that you are going about this in exactly the right way. There are no pat answers to your questions, but the way forward will be revealed, eventually, through trial and error experimentation.

 

My own experience is that developing a working version of a complex script, like the one you're describing, can be done relatively quickly with Macro Express; but making it virtually 100% reliable takes perseverance. (100% reliability is extremely difficult to achieve, but we can come close.)

 

Sometimes, when dealing with multiple windows, a short time delay (say, 250 ms) after switching to the second window makes the crucial difference. I often use "wait for window title" in these situations, but on occasion, I have found the time delay works equally well. (But it is not as elegant…) For some windows, you may find a script works better if you wait for the window to gain focus; in other circumstances, it works better to wait for it to open. Figuring out the best approach is as much art as science. (Maybe it's even more art than science…)

 

You may or may not get better results detecting and acting on controls rather than windows. Again, there are no guidelines or rules. It comes down to figuring out which tact works best.

[dougb1]

Hi Alan,

 

Thanks for reply and the reassurance I'm approaching this the correct way. I had a 75 MS timedelay after the Wait For Window Title but have just increased it to 250MS - we'll see how that works.

 

I have one example this morning where, after sending the keystrokes to Program B to activate the Input window that the this window title does appear in the visible window list (I write visible windows to my debug file) yet ME aborted stating the window didn't appear within the 8 second max wait. Since the code to list the windows saw it immediately before the Wait for Window Title statement, why didn't Wait For Window Title see it? This sounds like a bug to me.

 

As to the controls my code example below attempted to use the control but as described, it fails on the Set Focus command. Any clues as to why this may be or am I missing something in my code?

 

Thanks,

Doug

 

 

Hello Doug,

 

All I can tell you is that you are going about this in exactly the right way. There are no pat answers to your questions, but the way forward will be revealed, eventually, through trial and error experimentation.

 

My own experience is that developing a working version of a complex script, like the one you're describing, can be done relatively quickly with Macro Express; but making it virtually 100% reliable takes perseverance. (100% reliability is extremely difficult to achieve, but we can come close.)

 

Sometimes, when dealing with multiple windows, a short time delay (say, 250 ms) after switching to the second window makes the crucial difference. I often use "wait for window title" in these situations, but on occasion, I have found the time delay works equally well. (But it is not as elegant…) For some windows, you may find a script works better if you wait for the window to gain focus; in other circumstances, it works better to wait for it to open. Figuring out the best approach is as much art as science. (Maybe it's even more art than science…)

 

You may or may not get better results detecting and acting on controls rather than windows. Again, there are no guidelines or rules. It comes down to figuring out which tact works best.

[acantor]

Ah, yes, focus problems!!! I have been there.

 

Try a different approach. Maybe use two "switch to window" commands in a row, with or without delays. Or leave out the "wait for window title" and substitute a time delay. Or check pixel colours to infer when the second window is ready.

 

For debugging, you might want to break the macro down into several, and ensure each part works as you expect. How about experimenting with a macro triggered by the appearance of the second window?

[dougb1]

Ah, yes, focus problems!!! I have been there.

 

Try a different approach. Maybe use two "switch to window" commands in a row, with or without delays. Or leave out the "wait for window title" and substitute a time delay. Or check pixel colours to infer when the second window is ready.

 

For debugging, you might want to break the macro down into several, and ensure each part works as you expect. How about experimenting with a macro triggered by the appearance of the second window?

 

Well, nothing seems to be helping that much - it's better but still fails.

 

I removed the wait for window command and did 3 Active Window commands back to back.

 

I don't see what breaking up a single macro into 2 will accomplish. The single macro fails on the window title appearing so why would I break it up into 2 macros? I assume you mean that the first would run up to issuing the commands that should make the 2nd window appear and the 2nd macro would then activate when the window appeared. I can prove the window is an active window but the activate window/wait for window command doesn't appear to see it for some reason. Since I've recorded the list of available windows in my debug log *before* the activate/wait for window, I know for a fact the window does exist. This still sounds like a bug to me.

 

Doug