My app has a UserControl that wraps a ServiceController to expose start/stop/restart win service functionality to the user. My concern at the moment is restarting. It takes a small amount of time and I want to reflect the restarting status inside of the control. This is roughly what I have for the restart button click handler
private void RestartButton_Click(object sender, RoutedEventArgs e)
{
startStopButton.Visibility = Visibility.Hidden;
restartButton.Visibility = Visibility.Hidden;
statusTextBlock.Text = "Restarting...";
Controller.Stop();
Controller.WaitForStatus(ServiceControllerStatus.Stopped);
Controller.Start();
Controller.WaitForStatus(ServiceControllerStatus.Running);
startStopButton.Visibility = Visibility.Visible;
restartButton.Visibility = Visibility.Visible;
statusTextBlock.Text = Controller.Status.ToString();
}
Even when I step through the debugger I don't see these changes reflected in the application. Must be something that I'm missing. Also, I've tried disabling the buttons instead of hiding them and that does not work either.
You're doing everything on the UI thread, so the UI isn't updated until this code completes. You should do the heavy lifting on a background thread. The BackgroundWorker component makes this easy:
private void RestartButton_Click(object sender, RoutedEventArgs e)
{
startStopButton.Visibility = Visibility.Hidden;
restartButton.Visibility = Visibility.Hidden;
statusTextBlock.Text = "Restarting...";
var backgroundWorker = new BackgroundWorker();
// this delegate will run on a background thread
backgroundWorker.DoWork += delegate
{
Controller.Stop();
Controller.WaitForStatus(ServiceControllerStatus.Stopped);
Controller.Start();
Controller.WaitForStatus(ServiceControllerStatus.Running);
};
// this delegate will run on the UI thread once the work is complete
backgroundWorker.RunWorkerCompleted += delegate
{
startStopButton.Visibility = Visibility.Visible;
restartButton.Visibility = Visibility.Visible;
statusTextBlock.Text = Controller.Status.ToString();
};
backgroundWorker.RunWorkerAsync();
}
That's because execution is happening in the UI thread. Your button won't update because between { and } the UI thread is busy doing your work and it cannot update the button.
Related
I'm creating a new window in On_Click method. First I tried this;
public partial class MainWindow : Window
{
CustomerOperations customerOperationsWindow;
public MainWindow()
{
customerOperationsWindow = new CustomerOperations();
InitializeComponent();
}
private void btnCustomer_Click(object sender, RoutedEventArgs e)
{
customerOperationsWindow.Owner = this;
customerOperationsWindow.Show();
}
}
It's not working so I started creating the window instance every time the user clicks on the Customers button. And I used the following codes.
private void btnCustomer_Click(object sender, RoutedEventArgs e)
{
CustomerOperations customerOperationsWindow = new CustomerOperations();
customerOperationsWindow.Owner = this;
customerOperationsWindow.Show();
}
In the new window, If user clicks to Main button, I want to navigate to main window.
private void btnMain_Click(object sender, RoutedEventArgs e)
{
this.Close();
this.Owner.Show();
}
First question: Does this.Close() releases the window instance?
Second question: Is this usage correct?
What do you think is the best practice?
Thank you all.
Window.Close() will dispose all resources allocated by the instance. That's why you cannot show it again once it was closed.
If you want to reuse the same Window instance, you should cancel the closing procedure to prevent disposal of internal resources and collapse the Window instead (by setting Window.Visibility to Visibility.Collapsed - Visibility.Collapsed is also the default value of an instantiated Window before Window.Show() is called).
Alternatively hide the Window by calling Window.Hide() (which will set the Visibility to Visibility.Hidden) instead of Window.Close().
Calling Window.Show will also set the window's visibility to Visibility.Visible.
As a matter of fact, showing a Window by setting Window.Visibility is the asynchronous version of Window.Show().
Generally, you switch between Window instances by using the Window.Activate method. Calling Window.Show on a Window that is currently showing/visible, does nothing.
public partial class MainWindow : Window
{
CustomerOperations CustomerOperationsWindow { get; }
public MainWindow()
{
InitializeComponent();
this.CustomerOperationsWindow = new CustomerOperations();
// Consider to move this logic to CustomerOperations class,
// where you can override the OnClosing method instead of subscribing to the event
this.CustomerOperationsWindow.Closing += CollapseWindow_OnClosing;
}
// Cancel close to prevent disposal and collapse Window instead
private void CollapseWindow_OnClosing(object sender, CancelEventArgs e)
{
e.Cancel = true;
this.CustomerOperationsWindow.Visibility = Visibility.Collapsed;
this.CustomerOperationsWindow.Owner.Activate();
}
private void btnCustomer_Click(object sender, RoutedEventArgs e)
{
this.CustomerOperationsWindow.Owner = this;
// Calling Show will set the Visibility to Visibility.Visible
this.CustomerOperationsWindow.Show();
}
}
Creating a Window instance allocates unmanaged resources. If this happens very frequently, you will keep the garbage collector busy. From a performance point of view you may want to avoid it and prefer to reuse the same instance.
In a common scenario this is not necessary. But since Window exposes a Hide() method, you may consider to use it instead of Close().
If you want to switch to the parent window, you can use the code this.Owner.Activate(); and if you want to close the current window, first this.Owner.Activate(); and then this.Close();.
When you enter this.Close(), the compiler does not execute the following lines after reaching it. And when a sample window still exists there is no need to recreate it
private void btnMain_Click(object sender, RoutedEventArgs e)
{
this.Owner.Activate();
this.Close();
}
The focus rectangle and textbox caret are lost after disabling all controls, then enabling them again (vs2012 / .NET Framework v4.5).
To reproduce the issue, just create a WinForms application project, add a button and a textbox in the form, then use this code to disable and enable both controls in the button click event:
private void button1_Click(object sender, EventArgs e)
{
button1.Enabled = false;
textBox1.Enabled = false;
button1.Enabled = true;
textBox1.Enabled = true;
}
You may cycle between the textbox and the button using Tab/Shift+Tab as expected, until you press the button.
After that, the focus is partially lost (its weird). You can still use Tab/Shift+Tab and arrows to nagivate between the controls, and press Enter to active the button, but you cannot type in the textbox, nor use the space key to press the button. The textbox caret and the button focus rectangle are not displayed anymore. Changing focus to another application then returning to this form will fix the focus issue.
This issue does not happen if you don't disabled at least one control that is able to receive focus. Also the focus behavior is restored by disabling and enabling again the form, like this:
private void button1_Click(object sender, EventArgs e)
{
button1.Enabled = false;
textBox1.Enabled = false;
button1.Enabled = true;
textBox1.Enabled = true;
this.Enabled = false;
this.Enabled = true;
}
I was trying to disable all the controls of a more complex form at the start of a task, so the task would enable again all controls after finishing, to prevent user input during the processing, but without locking the UI thread. I thought it was related to the cross-thread invoke calls, but I found this issue happens even with all code running on UI thread.
This undesired behavior can be fixed by calling the form Focus() method:
private void button1_Click(object sender, EventArgs e)
{
button1.Enabled = false;
textBox1.Enabled = false;
button1.Enabled = true;
textBox1.Enabled = true;
this.Focus();
}
The ActiveControl is not changed after calling Focus(), so this works very well for me.
I am writing a program that reads information from a device through the serial port. I have a list of available devices in a datagrid. When the user clicks on a row, it fetches information from the device and displays it in a separate list. It usually takes about a second for the device to respond and the information to populate. However, during this second, the datagrid row does not highlight as selected. So it takes about a second from the time the mouse clicks on the datagrid row for it to actually show as highlighted/selected.
I thought a background worker thread would be the best thing to use for this, but I get the same results with the code below. Am I using it incorrectly, or is there something else I should be doing for selecting a datagrid row?
private void relayList_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
BackgroundWorker worker = new BackgroundWorker();
worker.DoWork += GetLinks;
worker.RunWorkerAsync();
}
private void GetLinks(object sender, DoWorkEventArgs e)
{
//send message to viewModel and do time-consuming work here
}
BackgroundWorker has a RunWorkerCompleted method. It will run in the execution context of the UI thread.
There is also a result property that is used to pass a result to the next method which is the RunWorkerCompleted method.
private void yourMethod()
{
BackgroundWorker worker = new BackgroundWorker();
worker.DoWork += DoWorkMethod;
worker.RunWorkerCompleted += RunWorkerCompletedMethod;
worker.RunWorkerAsync();
}
private void RunWorkerCompletedMethod(object sender, RunWorkerCompletedEventArgs e)
{
string result = (string)e.Result;
// do stuff here
}
private void DoWorkMethod(object sender, DoWorkEventArgs e)
{
e.Result = string.Empty; // Your device data
}
If you desperatly want to not use the completed method. Do not use dispatcher, instead use SynchronizationContext.
You will need to store SynchronizationContext.Current on a field when you first run your form but after that you can invoke whatever you need on the UI thread.
There is a problem with UI update in WPF.
I have such code:
private void ButtonClick_EventHandler(object sender, RoutedEventArgs e)
{
Label.Visibility = Visibility.Visible;
TextBox.Text = "Processing...";
LongTimeMethod(); //some long operation
}
The problem is that until LongTimeMethod ends (that is event handler ends), Label.Visibility and TextBox.Text will not be changed.
I solved it like this so far:
private void ButtonClick_EventHandler(object sender, RoutedEventArgs e)
{
Label.Visibility = Visibility.Visible;
TextBox.Text = "Processing...";
Dispatcher.BeginInvoke(new Action(LongTimeMethod),
DispatcherPriority.Background);
}
Is there any other solution without using dispatcher invocation? Calling this.UpdateLayout() doesn't help.
With Dispatcher.BeginInvoke you are still using the UI thread for LongTimeMethod(). If this is not required (i.e. it is doing some kind of background processing) I would suggest using the TPL to run it on a background thread:
private void ButtonClick_EventHandler(object sender, RoutedEventArgs e)
{
Label.Visibility = Visibility.Visible;
TextBox.Text = "Processing...";
Task.Factory.StartNew(() => LongTimeMethod())
.ContinueWith(t =>
{
Dispatcher.BeginInvoke((Action)delegate()
{
TextBox.Text = "Done!";
});
});
}
With this method, the long running method is processed on a background thread (so the UI thread will be free to keep rendering and the app won't freeze up) and you can do anything that does alter the UI (such as updating the textbox text) on the UI Dispatcher when the background task completes
Visibility and Text are dependency properties which updated by dispatcher. Your solution is absolutely corrent, but my suggestion is to do it asynchronously.
On other hand, you might simulate Application.DoEvents in WPF (see the article).
I'm using the MVVM pattern in my first WPF app and have a problem with something quite basic I assume.
When the user hits the "save" button on my view, a command gets executed that calls the private void Save() in my ViewModel.
The problem is that the code in "Save()" takes some time to execute, so I'd like to hide the "Save" button in the UI view before executing the large chunk of code.
The problem is that the view doesn't update untill all code is executed in the viewmodel.
How can I force the view to redraw and process the PropertyChanged events before executing the Save() code?
Additionally, I would like a reuseable way, so that I can easily do the same thing in other pages as well.. Anyone else made something like this already? A "Loading..." message?
If it takes a long time, consider using a separate thread, for example by using a BackgroundWorker, so that the UI thread can stay responsive (i.e. update the UI) while the operation is performed.
In your Save method, you would
change the UI (i.e. modify some INotifyPropertyChanged or DependencyProperty IsBusySaving boolean which is bound to your UI, hides the Save button and maybe shows some progress bar with IsIndeterminate = True) and
start a BackgroundWorker.
In the DoWork event handler of your BackgroundWorker, you do the lengthy saving operation.
In the RunWorkerCompleted event handler, which is executed in the UI thread, you set IsBusySaving to false and maybe change other stuff in the UI to show that you are finished.
Code example (untested):
BackgroundWorker bwSave;
DependencyProperty IsBusySavingProperty = ...;
private MyViewModel() {
bwSave = new BackgroundWorker();
bwSave.DoWork += (sender, args) => {
// do your lengthy save stuff here -- this happens in a separate thread
}
bwSave.RunWorkerCompleted += (sender, args) => {
IsBusySaving = false;
if (args.Error != null) // if an exception occurred during DoWork,
MessageBox.Show(args.Error.ToString()); // do your error handling here
}
}
private void Save() {
if (IsBusySaving) {
throw new Exception("Save in progress -- this should be prevented by the UI");
}
IsBusySaving = true;
bwSave.RunWorkerAsync();
}
You're using MVVM pattern, so your Save Button's Command is set to an instance of the RoutedCommand object which is added to the Window's CommandBindings collection either declaratively or imperatively.
Assuming that you do it declaratively. Something like
<Window.CommandBindings>
<CommandBinding
Command="{x:Static namespace:ClassName.StaticRoutedCommandObj}"
CanExecute="Save_CanExecute"
Executed="Save"
/>
</Window.CommandBindings>
For the handler of Executed routed event, your Save() method, on entry, you set a variable to false, on return you set it back to true. Something like.
void Save(object sender, ExecutedRoutedEventArgs e)
{
_canExecute = false;
// do work
_canExecute = true;
}
For the handler of the CanExecute routed event, the Save_CanExecute() method, you use the variable as one of the condition.
void ShowSelectedXray_CanExecute(object sender, CanExecuteRoutedEventArgs e)
{
e.CanExecute = _canExecute && _others;
}
I hope I am clear. :)
You could always do something like this:
public class SaveDemo : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;
private bool _canSave;
public bool CanSave
{
get { return _canSave; }
set
{
if (_canSave != value)
{
_canSave = value;
OnChange("CanSave");
}
}
}
public void Save()
{
_canSave = false;
// Do the lengthy operation
_canSave = true;
}
private void OnChange(string p)
{
PropertyChangedEventHandler handler = PropertyChanged;
if (handler != null)
{
handler(this, new PropertyChangedEventArgs(p));
}
}
}
Then you could bind the IsEnabled property of the button to the CanSave property, and it will automatically be enabled/disabled. An alternative method, and one I would go with would be to use the Command CanExecute to sort this, but the idea is similar enough for you to work with.
You can accomplish this by the following code..
Thread workerThread = null;
void Save(object sender, ExecutedRoutedEventArgs e)
{
workerThread = new Thread(new ThreadStart(doWork));
SaveButton.isEnable = false;
workerThread.start();
}
do all your lengthy process in dowork() method
in some other method...
workerThread.join();
SaveButtton.isEnable = true;
This will cause to run save lengthy process in another thread and will not block your UI, if you want to show an animation while user click on save button then show some progress bar like iPhone etc... give me feedback i'll try to help you even more.
Late answer, but I figured it'd be good to input a bit as well.
Instead of creating your own new thread, it would probably be better to leave it up to the threadpool to run the save. It doesn't force it to run instantly like creating your own thread, but it does allow you to save threading resources.
The way to do that is:
ThreadPool.QueueUserWorkItem(Save);
The problem with using this approach, as well, is that you're required to have your "Save()" method take in an object that will act as a state. I was having a similar problem to yours and decided to go this route because the place that I'm working is very Resource-Needy.