I have a cancel button to cancel speakAsync method of a speech syntehsizer. It is called over a PromptBuilder and the output is set to a wavefile, as
reader.SetOutputToWaveFile(CurAudioFile, fmt);
reader.SpeakAsync(PB);
And cancel it as following:
private buttonCancel_Click(...)
{
if (Utility.Warn("Are you sure you want to cancel reading the document aloud?") == System.Windows.Forms.DialogResult.Yes)
{
reader.SpeakAsyncCancelAll();
}
}
But the problem is that, when I click on the cancel button, the code is never executed! actually it become unresponsive to the button click and it is not executed!
I tried to use Application.DoEvents() in speak_progress but it also doesn't help!
Since it is a different thread when playing asynchronously, you are probably loosing reference to your reader object.
I suggest you to declare reader as a static property especially if you cancel it in a different event.
I found that in the Speak_progress event which is called after saying each word, I call Focus method for a control. then it shifts focus from the cancel button frequently and the click couldn't be performed!
Hope this answer be useful for similar problems!
Related
I've got TextBoxes in a C# form. The user enters data, and then when they leave the control (almost always by hitting Tab), I check the data to make sure it's valid. If it is invalid, I want to highlight their text so they can immediately fix it rather than having to click it.
Right now, on Control.Leave, I validate their entry. This works just fine. However, since they hit Tab, right after they dismiss the error message, it goes on to the next object, even though I've got ((TextBox)sender).Focus();
How can I have the above line fire after the form Tabs to the next control.
You may want to look into Control.CausesValidation property
http://msdn.microsoft.com/en-us/library/system.windows.forms.control.causesvalidation(v=vs.110).aspx
You can validate the control prior to the user leaving focus rather than waiting on Focus moving itself.
And here's MSDN documentation for Control.Validating event, does a good job at laying out the sequence of events when gaining / losing focus of a Control.
http://msdn.microsoft.com/en-us/library/system.windows.forms.control.validating(v=vs.110).aspx
Notice how Control.Validating and Control.Validated are launched prior to Control.LostFocus. You can perform your validation step prior to allowing the user to lose focus of your Textbox.
There's also a pretty good previous answer on stackoverflow.com which outlines how to do this: C# Validating input for textbox on winforms
If you handle the Control.Validating event, setting e.Cancel to true will stop the change of focus from occurring.
Note that this method will also stop buttons from working, so you may need to set Control.CausesValidation to false on certain buttons.
You will also need the following snippet on the main form to allow the close button to work:
protected override void OnFormClosing(FormClosingEventArgs e) {
e.Cancel = false;
base.OnFormClosing(e);
}
Try using the LostFocus event on the TextBox to Focus it again
I have few buttons in my windows application which has mnemonics.Now if i press multiple keys the events of the button clicks gets fired as i have used mnemonics.
But the behaviour is not as expected,because second button event handler is getting executed before the first button event handler has finished its execution,and also i have written my code in such a way that in the event handler of first button i am disabling my second button,still the second button event handler is getting executed.The problem here is due to mnemonics.PLease suggest me a better way to handle mnemonics as soon as possible.
Thanks in advance.
If your logic is tied to your buttons, change that. Let your buttons merely manipulations an object that implements your logic. You can then check in this object whether the requested action is allowed (i.e. whether the previous operation has finished.
Alternatively you can just disable buttons when running and re-enable then when.finished.
I have a modal dialog with a cancel button only which pops up when the user clicks on a button. Aftre the modal dialog pops up, I would like to start a long process which monitors external event. If the event happens, then the dialog will be closed automatically. The user can cancel the monitoring process by clicking the cancel button.
I assigned the process start to the Shown event
private void ProceedForm_Shown(object sender, System.EventArgs e)
{
controller.StartSwiping();
}
The process itself is a loop
public void StartSwiping()
{
Status status;
do
{
status = CallForFeedback();
} while (status == Status.Pending);
form.DialogResult = DialogResult.OK;
form.Close();
}
The process starts fine, but the dialog does not pop up, so the user can non cancel the process. I also tried to assign the start to the Load event, but nothing changed.
Is there any way to Show the dialog and after that start the process?
Thanks
Your problem is that you are doing everything in the UI thread. You need to put you status monitoring loop in a separate thread so that the UI thread can remain responsive.
There are several ways you can do this, but one easy place to start is with the BackgroundWorker class
Use a Task to do your LongRunning events:
CancellationTokenSource _cancelationTokenSource = new CancellationTokenSource();
new Task(() =>
{
//Do LongRunning task
}, _cancelationTokenSource.Token, TaskCreationOptions.LongRunning).Start();
Use the _cancelationTokenSource to cancel the task when needed.
I would move the long running code onto a background thread as you are blocking the UI thread, which is why the UI never displays.
Use a background worker class for the controller functionality http://msdn.microsoft.com/en-us/library/cc221403(v=vs.95).aspx
When the work is completed on the background worker (i.e. the event is received) then you can use the following mechanism to callback onto the UI thread:
http://msdn.microsoft.com/en-us/library/ms171728(v=vs.80).aspx
Note: the article says you can turn off the crossthreadexception this would be considered bad practice, instead handle it the correct way using the InvokeRequired check and then invoke method on the windows form.
Others have suggested using a BackgroundWorker, or some other sort of background thread. While in many cases this is appropriate here, there is likely an even better solution. You're not just doing some long running task, you're waiting for something to happen. Rather than constantly polling...whatever it is, you should be using events. There should be an event that is triggered when you are done, and you should subscribe to that event to do whatever you need to do (i.e. close the dialog) when the correct conditions are met.
What event I should handle to react to the completed change of the TextBox (i.e. when the user is
finished editing the content of the TextBox)?
There are several methods that you can use: Leave event, or a manual "typing stopped" event.
The Leave method is the most straight forward way of doing it, although as the event name suggests, it only happens when they TextBox looses focus, not when the user stops typing.
The TypingStopped event is something you would need to create yourself, but the basic idea of it is a short duration timer (say 500ms, but you would need to test it), which you restart on every KeyDown event of the TextBox. The timer would fire its own event and disable itself if it ever hits the end of it's timeout.
Edit: Updated to Leave event as per Hans' recommendation.
The Leave event is generally a good one for processing user input (for validation for example) as they move on to another part of the form. Just make sure that the event fires if they go from the textbox to any other UI element on your form - you may need to force a focus on the new element.
I have a problem that I have found many similar problems related to multi threading, but noone linked to me specific problem.
I have a method that does something, but when the method has been called, I don't want it to return untill a button is clicked.
So basically, at the end of the method, I would like it to stay put and wait for the Button_Click event to finish, and then the event should in some way "tell" the method to continue.
Currently I have done this by adding a loop at the end of the method like this:
while(someVariable){
Thread.Sleep(10);
Application.DoEvents();
}
Then the Button_Click event set someVariable to be false, and then the loop stops.
Of course, this looks very "iffy", and having this loop run every 10 milliseconds seems like a gigantic waste.
Are there any way of doing this properly? Since the method in question runs on the same thread as the rest of the application, it's also important that halting the method does not block the tread for other activities.
The reason I need this is because when the method is called from somewhere else, this method will draw up some components (including two buttons). Then the user clicks one of them, and then the method will return a different value depending on which button was clicked, and the program calling it can't continue untill it knows which button was clicked. So my program will look like this.
....
if( someMethod() == ButtonA ){
//do the proper action if button 1 is clicked
}else{
//do the proper action if button 2 is clicked
}
I hope this was not to confusing.
Assuming this is in the UI thread, you absolutely should not do this. You say "it's important that halting the method does not block the thread for other activities" - that basically means you need to find a different design. If the UI thread is "staying put and waiting for the Button_Click event to finish" then it can't be doing anything else without using the hack of Application.DoEvents().
Instead, you should make a call back to the original caller when the event occurs. Either expose an event that the caller can subscribe to, and raise that event when the button click finishes, or get the caller to pass in a delegate to call appropriately. (They're equivalent really, just different ways of propagating the callback.)
That's the way WinForms (and other rich client UIs) are designed to work - on an event-based model, basically.
Use AutoResetEvent, see sample and documentation at http://msdn.microsoft.com/en-us/library/58195swd.aspx
Your main thread does a WaitOne() on the event and in you Button.Click event, you Set() the event.