WinBatch Tech Support Home

Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.

TechHome

Sending Keystrokes

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

Locked Workstation SendKey and Mouse Problem Explained


There is this concept called a "session". In the "old" days, Windows [NT] only supported a single session. Today, with the way that Terminal Services is an integrated part of the Win2K server, WinXP and Win2K3 server products, Windows itself can support multiple sessions. Each session may or may not be connected. When a session is in a disconnected or locked state, the logical keyboard & mouse are also placed into a disconnected state. Within the session, there can be one or more things known as a "windowstation". On each windowstation, there can be one or more things known as "desktops". On each desktop, there can be one or more windows. The logical keyboard & mouse can only be associated with any single combination of windowstation & desktop at any given moment, and the other desktops on the current windowstation, and all desktops on all other windowstations in the session, will all be in a condition where the keyboard & mouse are disconnected. When the session is locked or disconnected, then *all* desktops on *all windowstations in the session experience this disconnected keyboard/mouse condition.

Whenever any desktop is in this state where the logical keyboard/mouse are disconnected, all of the API functions related to keyboard and mouse input become disabled. Within WinBatch, all of the SendKey*() and Mouse*() functions make use of those same API functions to inject keystrokes into other windows or to move the mouse or inject mouse button click events into other windows. Since the API functions related to keyboard/mouse input are disabled, these WinBatch functions don't work.

*ALL* that you can do is outright avoid using the SendKey*() and Mouse*() functions.

One way is to re-write to use the Control Manager extender. The RoboScripter utility can help with this, but some applications simply cannot be automated in this manner. One category of applications would be those that use non-standard controls that the Control Manager extender cannot manipulate. The other would be command prompt windows such as the ones displayed by CMD.EXE and/or COMMAND.COM.

In the case of command prompt windows, there's a couple of UDF library functions that have been written to either make Win32 API function calls to manipulate some named pipes in an effort to allow console window input & output to be manipulated via WinBatch. Other UDF functions make use of WSH objects that wrap around a console window and manipulate it via COM/OLE. Finally, there's a 3rd party extender for more directly controlling console windows via pipes.

Again, there is simply no way to directly use the SendKey*() and Mouse*() functions in a locked or disconnected session. There is also no way to unlock the session from within the session, and even if there were, there's no way to force a disconnected session back into a connected state from within the session, so that wouldn't address the problem in a disconnected TS session.


Article ID:   W17258
File Created: 2007:07:03:14:29:02
Last Updated: 2007:07:03:14:29:02