I am creating a media player object in a simple console application, to play some file. Though the media player is getting launched successfully, when I am using the close() method, the process still runs and media player window does not close. what needs to be done? here is the code I wrote..
WindowsMediaPlayer player= new WindowsMediaPlayer();
player.OpenPlayer("c:\\abc.wmv");
Thread.Sleep(2000);
player.controls.stop();
player.close();
Here the process doesn't exit and file still keeps running. How can I close the application?
The automation interface doesn't have a way to force the player to exit. The less than ideal approach is to kill it:
var prc = Process.GetProcessesByName("wmplayer");
if (prc.Length > 0) prc[prc.Length - 1].Kill();
The better mouse trap is to embed the player into your own GUI, easy to do with Winforms.
I think you need to close the COM object by calling Marshal.ReleaseComObject. COM does not know that you will never be using the player again, so it cannot close the process.
Do not rely on garbage collection for this because it might never happen if there is no memory pressure. Call Marshal.ReleaseComObject manually.
Related
I am testing out GMap.Net using WPF. So far I have only added the GMapControl, as well as setting some necessary stuff (CacheLocation, MapProvider, Zoom etc). The control is working well, except that when I close my window, it takes a while before VS recognizes that the debugging session has closed.
Apparently, my application's process is still running for some time before it terminates - it's not a bug in VS. This delay only appears when I do zoom/pan just before I close the window. I would want to guess something is still running, but I'm not sure how to tackle this problem.
Has anyone encountered this and have a solution?
What is happening is your program is still caching the tiles.
All you have to do is call gMap.Manager.CancelTileCaching(); when you exit your program or close the form.
gMap is what I named my instance of gMap.Net
Sounds like a there is a thread still running. I have noticed that the classes use the IDisposable interface. When you close the application/window, it is recommended that you call the .Dispose() method to clear any resources in use
I am developing an app for a touch screen monitor. I can call the Virtual keyboard no problem using:
System.Diagnostics.Process.Start("osk.exe");
I am looking to close the keyboard by clicking a button in my application.
In my onclick method I have the following code, but it doesn't work:
System.Diagnostics.Process.Start("osk.exe").Kill();
How do I fix it?
Process.Start returns a Process object. Capture that return value and use it to close the keyboard when the user clicks the button.
var osk = System.Diagnostics.Process.Start("osk.exe");
//Do things
//In your button click event
osk.Close();
I had some trouble finding a solution for this as well. Even though this question is older I'll post the solution which worked for me if anyone runs into the same problem.
Saving the reference when starting the process did not work for me. I still don't know why. What worked is looping through all processes using the process name osk.
foreach (System.Diagnostics.Process process in System.Diagnostics.Process.GetProcessesByName("osk"))
{
process.Kill();
}
Try doing it like this instead:
Process osk = System.Diagnostics.Process.Start("osk.exe");
When you are ready to kill it, do this:
osk.Kill();
The issue with your method is your starting osk.exe, then later trying to kill it. But your code to kill it is spinning up a new process and then killing that new spun up process instead of your original process. It's killing it immediately before the OSK is even showing, thus you aren't even seeing the second instance.
Also, know the difference between osk.Kill() and osk.Close(). Close() is the equivalent of hitting the little red X in the upper right hand corner of the window. It allows the application to gracefully shut down on its own. Kill() is the equivalent of opening task manager and forcing the process to end. Close() is probably what you want.
I've written a WPF/C#-based "shell" which launches WPF apps or other apps.
What would be the best method for checking if the process is finally fully launched or no longer "busy"? I've noticed that the mouse cursor for the launched process stays at the busy cursor from initial launch until I can finally see the UI for the process. Could I use User32.SetCapture API to set the mouse capture to the external process, then somehow check if the mouse cursor is the busy cursor? Or perhaps there's a mechanism in the System.Diagnostics.Process class that I'm unaware of?
As some of the launched apps are pre-compiled third-party apps, I absolutely cannot implement a mechanism in the external processes to message if it is finally ready, such as: Microsoft PowerPoint 2010 Viewer, Adobe Acrobat, or Adobe Flash Player Standalone.
I can't just check if the process has been created, because then I have a blank, unresponding window and a busy cursor. I hope to hide my WPF app the moment the external process is done launching.
The WaitForInputIdle Win32 APi function will wait until given process enters the message loop (with no input pending).
Quote: "Before trying to communicate with the child process, the parent process can use the WaitForInputIdle function to determine when the child's initialization has been completed."
You can call it via P/Invoke.
Not very cear what do you mean saying "beasy", but hear are several considerations:
There is no known (clear) way, at least that I'm aware of, that can let you do something like that. The thing is that process is perfectly isolated OS kernel citizen. So you can not write something that works for all type processes, especially if they are 3rd part binaries.
What you can try to do, is get the MainWindow of the process (if there is any), get its handle, and filter OS messages untill you get for example WM_ACTIVATED.
But even if this could work in certain situations, in others can measurably fail. For example, process loaded but the program is not active, cause for some reason License window of the application appeared.
Let's see what others suggest, in my opinion, there is no generic and no single solution to cover minority of possible cases.
Good luck
I am developing a winform application.
I want to play a sound file, till the dialogresult is OK for a message box. How can i achieve that.
For e.g.
/*Till*/ (MessageBox.Show("Alarm") == DialogResult.OK)
//Play a sound file
I tried while and do while but didn't succeed. Do i need to use background worker or run the code in a separate thread ??
You don't need to roll your own threading. .NET class library already did it for you. This is how you can do it:
SoundPlayer p = new SoundPlayer(#"C:\Windows\Media\chimes.wav");
p.PlayLooping();
MessageBox.Show("Alarm");
p.Stop();
Yes, run the sound file in a seperate thread which you start when the messagebox pops up. Once the MessageBox comes back with OK you can make a call into that thread telling the music to stop, or you could kill the thread.
EDIT
An alternative would be to write your own AlarmMessageBox which inherits from MessageBox. Its only difference would be that upon creation it would start playing that sound and upon clicking ok it would stop. This could work in just one thread.
I am trying to track visible windows from all currently running processes. My program interacts with these windows and the faster it can detect them the better. My goal is to move visible windows to a certain location on screen before they even draw in the default position if that is possible. If not I want to move them as quickly as possible after they are created.
Right now I enumerate through the visble windows using EnumWindows (p/invoked from user32.dll) in a loop with as small a delay in between iterations as I can justify.
I am looking for a method to hook into 'something' which will allow me to wait for a 'window opening up' event to fire instead of constantly polling.
Are there any methods to achieve this?
You need the SetWindowsHookEx() API function, setting a WH_SHELL hook. The callback gets a HSHELL_WINDOWCREATED notification when a new toplevel window is created.
This is a global hook, you cannot write the code for this hook in C#. It requires a DLL that can be injected in a process, the CLR cannot be initialized properly to support managed code. You'll need an unmanaged DLL to get the job done, this project offers one.