Click here to Skip to main content
15,665,942 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Is there a way to automate control of another application in c# using sendkeys or user32 api calls if the main and secondary applications are on a dedicated windows server that does not have a monitor connected?

I have tried but it only works when I am connected to the machine with Remote Desktop. Without a monitor (or mouse or keyboard!) I'm guessing there is effectively no ui so the ui calls fail. For example I can find the window handles but even bring to foreground calls don't work.

Any ideas on alternative solution or approach here would be greatly appreciated!

1 solution

Never tried it - so I'm all guesses here...

My first thought is: "How are these apps (that need a UI) running on a server in a session without a UI?" I can see that you could start the apps in your remote desktop session - but what happens to the apps when you log out (or are you just disconnecting?)?

On a desktop box, when you log out, all your apps are closed - so any 'user' app (i.e. app that needs a UI) I imagine must be associated with a user session somehow.

So, the corollary would be that if the apps are running in a logged-in-but-disconnected session, then they don't know that there's no current display / keyboard attached, and you should be able to inject events into the UI message loop.

Hmm - but you say you can find the window handles. You can do this when you are NOT connected in a remote desktop session? If so, that blows my theory out of the water. :((

So, none of that was anywhere near an idea for a solution.

How much control do you have over the implementation of these apps?

Can you rewrite them so they don't need a UI? If they're running on a server, as server apps, that would appear to make sense. Then what you need to do is design a protocol that they can respond to. Remember, no UI means no 'built in for free' message pump - you'll have to write your own.

It sounds like you sometimes want to control them automatically and sometimes via a UI. If that's the case then partitioning the app into the 'bit that does the work' and the 'bit that has a UI' would be a more robust architecture - where you're not finagling the Win32 windows architecture and message pump to do things it was not intended for.

Of course, you may not be able to make that kind of change. In which case I've probably been no help at all. Sorry if that's the case. :-O
Share this answer
Redgraves 9-Aug-10 17:53pm    
Thanks for first thoughts, unfortunately I am trying to automate a third party application so no coding control or custom interface. Find child window in that app, set focus and sendkeys or postmessage was my initial attempt here :(

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900