Delphi CreateProcess App Keystroke Automation: Can Window Handle Change?

[6volt]

I'm automating a software using SendKeys.

The s/w is executed in my Delphi 7 code by CreateProcess.

The first time I want to sendkeys, I get the window handle by a title search.

Then I use than handle subsequently.

Everything works like it should but sometimes, typically when sending keystrokes to close a window that has been open for a while, it fails.

Most of the time, everything works flawlessly without incident while my Delphi program runs for days if not weeks - yes, execution time is very long. But other times, I could get this problem every hour during an execution.

NOTE: I have not demonstrated this, but I suspect that this problem occurs when the PC has been on for a long time. After a fresh boot, I suspect this problem does not surface.​

Should I run my HandleByTitle every time I want to send a keystroke? And if YES, won't there always be the possibility that the handle could change in the very short interval between getting the handle and then using it ASAP?

Thanks in advance,
Tom

 

[Glenn9999]

SendKeys is what exactly and where are you getting it from? I don't find that referenced in any Delphi library or Windows API I'm directly aware of. While you don't provide any direct code which duplicates your problem, I would suspect that whatever this "SendKeys" is is your problem in some way as it quite obviously is a wrapper which implements something else that is known to any generic Delphi or Windows API.

Please provide more details.

 

[6volt]

Thanks for the reply!

Unfortunately, he code has nothing to do with the reality of the question.

I just need a Yes or No answer with a short explanation if Yes so I can proceed to troubleshoot.

Unfortunately, I need to know this first so I'm not out on a Wild Goose Chase.
_________________________________________

If you've never used SendKeys, you are a lucky guy. Keystroke automating windows is a terrible situation to be in and if carried out thoroughly, you will find yourself facing at least one Windows OS Black Box you cannot look inside which is required for your programming objective.

Here is a little about SendKeys:

SendKeys is an historically iconic set of procedures and functions that has been used for years to facilitate sending keystrokes to windows.

Its basic method is use the window handle to SetForegroundWindow.

Then send the appropriate keybd_event.

The problem is that keystrokes to close a window that has been open before I run an external application using CreateProcess, fails to close when it is sent the appropriate keystrokes to the handle that was found when the window opened.

What is perplexing about this problem is that some XP PC's will run for weeks if not months and then one will "act up" and produce the failure sometimes minutes apart.​

 

[6volt]

UPDATE: Turns out the Window Handle and Title are intact, but the window is unresponsive to any automation attempts to close it.

I try these and they all fail to close the window:

0) Check Focus, Report, and SetFocus if required.
1) Send Closing SENDkeys again (CloseKey = F12, ENTER, Y, N, etc)
2) If CloseKey fails, try F12, then try ENTER.
3) Send DestroyWindow​

The only way to close the window is with a mouse clicking on the upper RH corner "X"

 

[whosrdaddy]

It seems that the process you created is "hanging", and in that state, it wont be able to process input messages.
Your only option in that case is to use the TerminateProcess API.

/Daddy

-----------------------------------------------------
Helping people is my job...

 

[Glenn9999]

The problem with a Yes/No question is the need to be able to make a proof of concept of it given you are likely calling a third-party app that you have no source control over. As long as the window is not being closed and reopened, the window handle involved should remain stable.

That said, I am aware of what SetForegroundWindow and keybd_event is. Just not someone's wrapper.

What it looks like is you are possibly overloading the message buffer...or you need to be sending close messages

PostMessage(thewnd, WM_SYSCOMMAND, SC_CLOSE, 0);

or the code you're using to get the proper window handle isn't quite good. See faq102-7840 . I will note that was probably the roughest part of getting that bit of code to work both correctly and consistently.

 

[6volt]

Thanks,

The SendKeys code is simple and you can see the keybd_event calls.

What is interesting is that the same code runs on many XP PC's and a lone Vista one, and most of the time, this won't happen for many months. Then one PC gets buggy with this.

It's not clear how the Message Buffer could get full. I probably send somewhere between 500 to 1000 keystrokes to the window every minute, usually without issue. That would say the Message Buffer is not getting full.

What is further obscuring this is that while "sendmessage" is not working and the app diagnoses itself and pauses for user intervention, by the time the user clicks on the Close X, the problem may have already "dissipated."

I've just written a "CloseUnresponsiveWindow" procedure that tries some of the things I mentioned previously, and I've had it get called and SUCCEED in closing the window. Another problem could be all kinds of 3rd party "new update available" popups that I just don't turn off.

I've thought of having a special boot that would have bare bones programs and services running, but since most of the time this is a non-issue, I think it is better to try to find out what is going on with the particular PC that is acting up. I may gain some insight into this particular problem

RE: TERMINATE THE PROCESS: I have looked at this window and it looks like I could just kill the process instead of dealing with the window.

QUESTION: If it terminate the process, would it close the window?

I use CloseHandle (hThread) and CloseHandle (hProcess) to terminate.

 

[whosrdaddy]

Terminateprocess will kill the window. It has the same effect as ending the process via task manager..

-----------------------------------------------------
Helping people is my job...