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.
Related
I want to play a beep for 1 second in thread. I'm not familiar with threads and maybe there is another easy way without using threads. I used console.beep(), but unfortunately it freeze's the form for a second.
while(true)
{
do some jobs;
console.beep();
}
The Winform app freeze on the console.beep(); for one second. I need to pass the line and simultaneously beep for one second.
You can use
using System.Media;
SystemSounds.Beep.Play();
And Play() doesn't block so you don't need a Thread.
It plays whatever is configured in the User's sytem sound settings.
But if you need to know when the sound has finished this is not what you want.
How to: Play a Beep from a Windows Form
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 want to write a convenient front-end to the old and ugly Win95 application. I nailed the problem to this:
Invoke the target executable;
Wait for application window to appear;
Wait for message box (i hope it is a message box) to appear;
Trigger an onClick event for the "OK" button of the message box;
Wait for the application to exit.
1st and 5th items are easy, it is just the System.Diagnostics.ProcessStartInfo stuff; but i have no idea where to start with the rest of items. How could it be done?
Take a look at the windows automation framework, this is a good starter codeproject.com/Articles/141842/
Sorry for the delay.
If it's not too much of an effort you could open up the executable in a disassembler (like ollydbg) and simply NOP the call to the messagebox. Then from C# you could simply wait for the process to exit instead of dismissing the messagebox using code.
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.
I have embedded a console window within my Windows application form using ะก#
I have an application that runs in the console window. my c# project is a GUI to display the output of this and also to send parameters to it.
Most is working fine except when a call to _getch() is made from my GUI to the console window it tends to freeze up the whole system.
anyone got any ideas why this would happen?
I can post code if need be.
Thank you
Odds are that _getch() is a blocking call.
The _getch() function won't return until the user presses a typing key on the keyboard. If this function is called from your program's main thread then this will stall the UI thread. It won't pump the message loop, your UI freezes when it no longer processes input events nor paints the windows. After a couple of seconds Windows puts the ghost window in place with "Not Responding" in the title bar.
While calling _getch() from a background thread will solve the problem, that's probably not going to be convenient. You can use _kbhit() to check if a keystroke is available. Calling _getch() after _kbhit() returns true won't block. Probably not convenient either. Trying to pump the message loop while _kbhit() returns false would technically be a solution, if it wasn't for the message loop living in the wrong code.
Note that you can type Ctrl+S in the console window to pause output, Ctrl+Q resumes it again. You'll still block the UI thread but at least you'll do it knowingly.
What does _getch() do. You can start the call in another thread if its blocking the UI thread.