Anyhow, I trying to run a perl script that is capable of selecting a
window and forcing text to it, essentially providing automation for
testing. It works just fine when executed locally but I want to use if
via 'rcmd' to do things remotely. However when I run it remotely, it
does indeed select the window I want but then it sends its output back
the the remote machine on which I'm running 'rcmd'. I'm guessing this
is how 'rcdm' is designed to work - it sends the output of a program
back to the window from which it was invoked. Does anyone have any
clever ideas how to defeat this capability? Of better yet, how to get a
program to send its output to a window (such as a control waiting for an
OK button to be clicked)?
I also tried running a second program that can move the mouse anywhere
on the screen and then do a mouse-click, but that failed to run with
'rcmd' as well.
Finally I thought I could simply schedule my program to run with AT
since it would lose its 'rcdm' context. Further, I can test this
without 'rcmd' in the loop. But even though it gets scheduled to run, it
fails to run and write an error to the system event log saying there is
something wrong with the command syntax even though a cut/paste of the
command to a DOS window does in fact run and move the cursor and click
the button! What I'm doing is the following:
AT xx:yy c:\windows\system32\cmd.exe /K start c:\temp\mouse.pl
Any thoughts? Is this a hopeless problem?
-mark
If by output, you mean stdout, yes. But that would never appear in another
program's window. SendMessage and PostMessage should work even if output is
redirected. However, if you are running in a separate logon session, then
you may not have permission to access the windows.
> clever ideas how to defeat this capability? Of better yet, how to get a
> program to send its output to a window (such as a control waiting for an
> OK button to be clicked)?
>
> I also tried running a second program that can move the mouse anywhere on
> the screen and then do a mouse-click, but that failed to run with 'rcmd'
> as well.
>
> Finally I thought I could simply schedule my program to run with AT since
> it would lose its 'rcdm' context. Further, I can test this without 'rcmd'
> in the loop. But even though it gets scheduled to run, it fails to run and
> write an error to the system event log saying there is something wrong
> with the command syntax even though a cut/paste of the command to a DOS
> window does in fact run and move the cursor and click the button! What
> I'm doing is the following:
>
> AT xx:yy c:\windows\system32\cmd.exe /K start c:\temp\mouse.pl
At a guess, you might need some quotes there.