Multiple Desktops SendKey

Question:

Although I may eventually wind up getting some additional machines to run some of the stuff that I'm scripting, it had occurred to me that maybe a multiple-desktop type of utility might obviate the need for separate machines.
Here is what I'm getting at. I'm scripting some custom apps using some custom controls. And using the control manager extender and RoboScripter is working well. But with my scripts, I typically activate the window, and do the control manager type stuff. Unless I'm missing something, one problem with this approach is that I can't also be doing something else at the same time as my scripts are taking over the machine and setting active windows and all that.
So, I wondered if there might be a way to make use of multiple-desktops or virtual desktops to handle this situation. I could have one desktop running my winbatch scripts, and run other stuff on other desktops. Again, I realize that just having multiple machines will be the better way to go, but it might be nice to find a way to not have to have multiple machines.
I know there are a number of multiple-desktop products available. In fact, I even own one as I own Object Desktop and it includes a multiple-desktop type product. But, it doesn't seem to be sufficient. There is still really only one active window, not one active window per desktop. And, I'm afraid that maybe all multiple-desktop products have this same limitation. And if so, then maybe my idea won't work.

Any comments?

Answer:

Generally speaking, I don't find that the Control Manager gets interfered with when using it to manipulate one application while I'm actively use another application on the desktop. This would be a problem with SendKeys*(), SendMenus*(), MouseMove () & MouseClick() types of functions, though, as they do rely heavily on the target window/application being the active window in the foreground. The Control Manager directly manipulates controls in a window using regular Win32 window messages.

Now, regarding multiple desktops, are you talking about the term "desktop" as defined in the Win32 Platform SDK as it pertains to desktop objects in the NT platform family?

If you are talking about NT desktop objects, then you have to understand that any thread of execution in a process has its desktop set for it at the time that it is created and thus you cannot readily change the desktop associated with any application after that application is running. Since the keyboard & mouse are only associated with any single desktop at any given moment, an application's association with any particular desktop dictates when the app will have access to the keyboard & mouse.

It is possible for applications to create additional desktops beyond the "default" desktop on which the Windows Explorer is launched as the shell for your interactive logon session. It is also possible for an application to switch which desktop is the active desktop on the windowstation in your session. However, when you change the active desktop you are going to lose access to the Windows Explorer shell so you need to have some other application that runs as a shell on those other desktops.

If you have the CPU, memory and hard drive capacity resources on your system, I would suggess that you take a look at VMware Workstation [http://www.vmware.com]. It allows you to carve up your desktop/laptop system into several virtual machines, each of which runs its own guest operating system [all versions of Windows, NetWare and many Linux variants]. You could very easily set up multiple guest Windows systems and have each one of them run its own set of applications independently of each other and there wouldn't be any cross-talk or intereference between them.

You can play with this cute little script...

http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/Samples~from~Users+DesktopHopper.txt Mostly you have to worry about SendKeys of any flavor and Mouse commands.SendKey and mouse goto where the real sendkey and mouse.

If you use RoboScripter and the Control Manager Extender and refrain from using the SendKey/Mouse stuff, then I think a lot of stuff should work. Its just that RoboScripter give you access to some functions that you should not use in this context.

Like VMWARE M$oft has a free 45-day trial of their virtual machine software http://www.microsoft.com/windowsxp/virtualpc/ Legal disclaimer: Note that just like VMWARE, you have to have multiple licenses for whatever operating system you want to install.But each is completely independent and looks like multiple machines running on yours. I agree the "multiple desktop" type products only provide new visual space, but use the same address space.

User Reply:

I've found a multiple-desktops product that seems more advanced than most of the two-dozen or so others I've seen. Specifically, each desktop has its own active window. Also, when you list the windows, such as with the WinBatch WinItemize function, only the windows for the destop that the function is run from is reported. It really seems like a very complete multiple desktop program.
I haven't done much testing with WinBatch and the product yet, but I think it will do what I want--allowing my WinBatch scripts to take over what it thinks are the mouse and keyboard, but only virtually on its own desktop.
If anyone else is interested, the product is called Multi-User Desktop. I'll report back after I've tested it more with WinBatch.

http://www.multiuserdesktop.com

Answer:

It does sound like this product is actually using the NT-style "desktop" objects. On any given desktop, the only windows that can be enumerated by a program attached to that desktop are the windows of other programs that are also attached to that desktop. It like having separate sandboxes to play in.

I still see the issue of the mouse & keyboard to be a problem, however, as the mouse & keyboard belong to your windowstation, and only one desktop at any given time can be the active desktop and thus have access to the mouse & keyboard. Look in the tech support database or search the Tech Support Forum for articles & messages about what happens when keyboard & mouse input simulation is used in script to control an app while the desktop is locked on a NT/2K/XP system. Or, the same problem applies when a service tries to do the same thing but the service doesn't have access to the interactive desktop.

Test *carefully*, such as having notepad opened on a desktop, and have a script running that uses SendKeysTo() to insert text at timed intervals into notepad. Get things running on that desktop and then make a different desktop active, wait for a bit and then switch back and see if the script was able to continue inserting text into notepad using SendKeysTo() while the desktop was not active. If it works then you're OK; if it doesn't work, then you know why it didn't work. Also, compare the results of that test to running the same test on your main desktop [e.g. the one named "default"], but lock the workstation for about 5 minutes, then unlock it and see if the script was able to keep on entering the text into notepad via SendKeysTo().

Article ID:   W16399

File Created: 2014:07:18:09:50:34

Last Updated: 2014:07:18:09:50:34

Database Search

TechHome