Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.
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