Sending a message to Win32 Dialog in background.

[balajinagaraju]

Hi Monks, I am working on automating a win32 GUI application using some perl modules and uptill now i have been running the application in foreground mode and all my scripts are running fine , but now i would like to make changes to my script to make my application run in background while the user can be able to do other jobs in the foreground.

I am using Postmessage and Sendmessage commands to send commands to a particular window and this works perfectly fine if i am running in background but i want to enter data into an edit control in background and i am not able to find a solution for this. I have been using SendKeys to send key strokes but this requires the application to be in foreground.How can i enter data to an edit control when my application is running in background?. I have tried using the below commands but its not working. Any suggestions are appreciated.

PostMessage($URLDialog,WM_SETTEXT,0,"Test");
            
    SendMessage($URLDialog, WM_SETTEXT, 0, "Test");

[BrowserUk]

I think you may be out of luck.

When you post messages to an application, they go into a common queue. When those messages represent user input -- keyboard or mouse -- they get routed to the appropriate window by determining where the keyboard focus or mouse pointer is when the input arrives. If the windows you are targeting are not visible to the user, then they cannot have the keyboard focus or be under the mouse pointer.

SendMessage on the other hand does not go via the message queue, but is actually a synchronous call to the targeted window procedure. But, if you are sending them to a dialog, that usually consists of several controls; possibly including multiple input fields; then again, the keyboard focus or mouse pointer position is used to determine which of the controls within the dialog should respond to the input. If none of the sub-controls has the focus or is under the pointer -- because the dialog is hidden -- then it is probable that the input cannot be routed and so is discarded.

You might be able to bypass the problem by sending the messages directly to the required controls; but there is no guarantee that they will -- in the absence of focus and visibility -- be in a state that will allow them to respond correctly.

Indeed, given the possible nefarious uses that such techniques might be put to, it is quite possible that the system might actively inhibit the attempts to fake user input to hidden dialogs.

The bottom line is that you should probably re-think the design of what you are trying to do.

[nikosv]

is it possible to hook or sub class the windows procedure so to look for a custom WM_ message hence uppon reception handle it in any way fit?
does win32 GUI allow accessing the low level winproc internals ?

[BrowserUk]

At the perl level, not to my knowledge. Though I have done nothing with Win32::GUI in a few years.

[Anonymous Monk]

What you're doing with sendmessage etc is simulating a user sitting behind a keyboard -- GUI toolkits generally stop processing events when the application loses focus (its in the background)

In short, I don't think you can't do it

[Corion]

At least up until Windows XP, this does not match my experience. The Win32 windows callback gets called for every message sent to it, whether the window is in the foreground or not. Especially, there are messages that get sent to set the focus to the window.

If all else fails, the controlling/sending program can force the other window into the foreground and then send the messages.

[balajinagaraju]

Hi, Thanks for your responses, win32 windows will indeed process the messages sent to them no matter whether they are foreground or background, but i am facing an issue particularly here. I think the only way to achieve this could be to set the required window to foreground and then sendkeys. Let me check other options.

[Anonymous Monk]

At least up until Windows XP, this does not match my experience.

You're right, I was misremembering an experience I had with some GUI toolkits, which drop/filter incoming messages based on focus

[Anonymous Monk]

OTOH, it might work if you can make the app always-on-top, shrink the window to 1x1px or 16x16px, and/or move it off screen ( -100,-100 ) ... good luck finding out :)