SendKeys to 2+ Applications

[Roger Garstang]

I've seen the various SendKey type apps here, but none of them can do 100% of what I need...which is go completely against all Windows standards and send keystrokes to 2+ other windows as I type in another. Sending the Key Up/Down messages to the window(s) doesn't work...most likely because it is coming from my app and not windows itself which was somewhat expected. keybd_event and SendInput do work for one window, but involves setting the other window to foreground which removes focus from the window I'm typing in.

There are a lot of mentions of AttachThreadInput too, but mostly to force SetForegroundWindow to work. What other uses are there for it? If I can't figure out a way of making other windows accept my key messages I may have to use a scripted approach and record the keys to a file that is then played to each window since I can't have a 3rd window where I manually type. It sounds like AttachThreadInput allows keys to be read or something, although I'm not seeing this. It says checking key state is an advantage, but I'd think key state would be the same in every app??? When I switch to a different app, my Caps Lock is still on, etc.

I'd really like to get it to work by passing key messages, but if anyone has any other ideas I'm open to them.

[Roger Garstang]

Been looking at the Journal Playback method and kinda like it so far, although it has its own things to overcome. Found Lance's code that works alright, but doesn't follow all guidlines mentioned in API Docs like Ctrl Break to exit and other messages sent to cancel it like pressing CAD or Ctrl+Esc, etc. It didn't make use of the time either to return a delay value and make things run the speed they were ran during recording.

One thing that is confusing though is it makes use of the hWnd and such when recording and playing back, but this appears to be translated into the current hWnd values as I can record with Notepad and playback with another instance of it or wordpad open and it plays fine.

This still keeps me in somewhat of a scripted mode though and doesn't allow for typing in one window and having the keys sent to 2+ other windows...

[Michael Mattias]

WM_COPYDATA? SendMessage (private registered message)?

(These *are* cooperating applications, right?)

[John Petty]

To add to what Micheal said, can the other applications and control you want to type in send you their handles or can you determine them?

[Roger Garstang]

I've got there handles/can determine them. It is getting them to accept key messages that is the problem. To give a little more detail, one is a DOS version of the app, the other is a Windows version. That makes sending WM_COPYDATA out, and even if both were windows apps they wouldn't be designed that way. It is just to send keys and verify both behave the same way.

[Michael Mattias]

>It is just to send keys and verify both behave the same way.

I must be missing something, because I'd test that by using the keyboard.

Oh wait a minute... this almost sounds like you are trying to set up three processes...
1 to send keys
1 for the Windows App
1 for the MS-DOS App

.. and "watch" the two apps (hopefully) do the same thing?

I'd still test with the keyboard.

[Cliff Nichols]

RegisterWindowMessage maybe?

According to docs

The RegisterWindowMessage function is typically used to register messages for communicating between two cooperating applications.
If two different applications register the same message string, the applications return the same message value. The message remains registered until the Windows session ends.
Only use RegisterWindowMessage when more than one application must process the same message. For sending private messages within a window class, an application can use any integer in the range WM_USER through 0x7FFF. (Messages in this range are private to a window class, not to an application. For example, predefined control classes such as BUTTON, EDIT, LISTBOX, and COMBOBOX may use values in this range.)

[Roger Garstang]

.. and "watch" the two apps (hopefully) do the same thing?

I'd still test with the keyboard.

I'd test it with the keyboard too, but when I got that part right and need to run through it 1000 times and maybe even again in the future making sure I do the exact same keystrokes...I want to eliminate the human error factor. Not to mention a whole lotta typing.

[Paul Dixon]

Roger,
can't you use SetForegroundWindow to force each of your 2 applications to gain focus before sending them each the keyboard input you want using KEYBD_EVENT ?

Paul.

[Roger Garstang]

That is what I tried, but while all the focus is going on it is possible to type something in one of the other windows, etc. I've been playing with the Journal Playback though and may be able to do something like that but with a Journal the keyboard is controlled by windows, so I have it on while sending to avoid miss keys in the other windows...but this may lead to missed keys? Not sure how quick that will be for each char though too. I may still end up using it for recording just Key messages and then playing them back.

One weird thing I noticed though is with the paramL I've found docs stating it should be the Virt Key Value, which the lower byte is. But, some keys have extra bits i can't figure out. It doesn't track repeat, and I don't see that it tracks anything like the prev state of the key, etc. Not sure what the bits are. I can save off just Lo(Byte,@MyEvent.paramL) though and play it back and it works??? The recording seems pretty basic. It doesn't appear to keep track of Caps or anything. Only what keys are pressed, so the keyboard and all apps must be in the same state as when recorded for proper playback.

[Roger Garstang]

I found code for making it do everything timed out and honor CAD/Ctrl+Esc/Ctrl+Break and such too. Only odd thing is it shows a Msg Hook in the app too. For some reason I always thought hooks had to be in a DLL. Or is that just keyboard hooks?