My target is to send keyboard events to external application.
From my application, I'm launching a C# exe (console application) that bring the target application to the front and uses SendKeys.SendWait to send keyboards events. I ran into a rate case were the command don't have any affect.
When debugging it, it works but when running it not in debug it fails.
I think it as something to do with the fact that when debugging my application is the active application.
You'll need to do a little work, and it changes depending on the version of Windows. There's an MSDN page that has a good explanation and an example:
http://msdn.microsoft.com/en-us/library/ms171548.aspx
Related
I'm developing a MVC application using .NET 6.0. I am publishing the app with the following configuration:
The app, so far, is launched by double-clicking the .exe, it shows the classic "cmd-style" window.
Now the requirement is to start the portable app minimized into a system tray notification area in Windows (if this is not possible, I was looking for a method to deploy the app as a service which runs in background).
How can I achieve this? Thank you.
To obtain access to the system tray, you need a message pump and a target window. In other words, a regular command-line executable doesn't cut it. Basically you need to have an executable that creates a window (can be an invisible one) and then the main thread must pump Windows messages.
I'll say this much for now becuase the provided information is insufficient and explaining all possible scenarios would be too long a response.
I'm writing an embedded powershell host in C# using VS13 (Windows Application NOT console app). I can invoke powershell commands just fine. The issue I'm having is that when the invoke function handles a console command like ping, netstat, etc. it triggers an instance of conhost.exe to be created. This is normal behavior for Windows 7 and above from my research so far, but when conhost starts up, it briefly flashes a console on the screen.
Is there a way to have conhost start-up without flashing the console window initially? Keep in mind that I'm handling user input into the powershell pipeline so testing for each command, and starting a new process is probably not practical.
It's been a while since I asked this question so I wanted to share the answer I came up with. Basically, since my embedded host was in an application that runs solely in the background, there was no way to prevent conhost from flashing on the screen when "native commands" were processed. It's just the way Windows works. If my host was attached to a GUI then I think there might have been a way to redirect output, but so far for my use case I couldn't suppress conhost.
I've got an issue with the focus management in WinRT. The issue is specific for the application startup. Let me share the example of it:
If during the startup I change the focus (for instance I can start selecting some text in a browser), the runtime will decide that it doesn't need to show the application. The application is being started in a 'hidden mode'. It means that I do not see the UI, but I still can find it in process explorer.
So what I need here is to make the application be active in all possible cases. I tried to use several native functions such as ShowWindow, SetActiveWindow, SetForegroundWindow, but without any success.
I also noticed that any WinRT app is being started under WWAHOST.exe and mainwindowhandle is 0. The app shows up if I use 'Switch to' option in Process Explorer context menu.
WinRT applications are sandboxed and have very little control on the way the OS handles them, and almost no way to affect the behavior of other applications running on the same host. What I would suggest then is for you to design your application in such a way that it shows some UI as early as possible, then asynchronously you can load any other resources that your application may need.
I have just begun to explore the mono winforms environment and I cannot work out how to start a program from within monodevelop without a console session being started.
My simple program runs okay but when it exits a terminal session is always created & waiting for me to 'press any key'. I guess I could arrange things so that the terminal window closes automatically, but I would rather the app just ran 'natively', is this possible or does the way mono & .net function work preclude it?
As shown in the examples at Zetcode, in 'Main' the rest of the code is started with 'application.run(new aFunction());', I thought this might be the cause of the terminal session occurring but replacing it with:
myNewClass n = new myNewClass();
n.aFunction();
causes the program to not run at all (or maybe just exit without doing anything).
I am an experienced programmer but not familiar at all with C# or the mono/.net environment so 'stating the obvious' may be all that is required in an answer.
MonoDevelop will usually let you start a program with or without it running in an external console.
In MonoDevelop 2.8 on Linux you can control this by context clicking on a project in the solution tree and selecting Options; then Run on external console under the Run section. I'm not sure if you can disable this on OSX.
I have a WPF application that occasionally crashes, and say "not responding". Is there a way to detect if the program is not responding? And if so, restart the WPF application?
This will be a temporary fix until the bugs are fixed.
You could use the Application Recovery & Restart Manager API, which was introduced in Windows Vista. This is an unmanaged (C) API, however there are managed wrappers available in the Windows API Code Pack.
This is a good feature to add to your application anyway, as it provides the user with a nicer experience if (when!) you application crashes. You can even write a callback that persists information about what the user was doing, and then restore that state when the application restarts.
The most basic use of the API would be to just add the following line somewhere in application startup:
ApplicationRestartRecoveryManager.RegisterForApplicationRestart( new RestartSettings( "restart", RestartRestrictions.None ) );
Because this is a temporary fix while you debug the app, one possibility is to cheat and use a bootstrapper/startup app whose sole job is to monitor the problematic app. Start the problematic application via the System.Diagnostics.Process class's Start method, then occasionally monitor the returned Process' Responding property. If not responding, do what you need to do.
It's important that this only be done as a stopgap while you fix the real problem, of course. There are lots of little issues with doing something like this long-term.