We Keep Coding

Keep focus on main window while doing lengthy operations

I have a WPF application that calls a dll when user clicks on a button. This dll does very lengthy operations and while it does that, I cannot interact with the MainWindow, e.g scroll down the Datagrid logging some update messages, switch tabs etc.
How can I keep the MainWindow activated while the dll is running ? I thought about a BackgroundWorker that constantly calls the .Activate() method whenever Window.Deactivated occurs, but wouldn't that be terribly resource-consuming and slow down the other dll that already takes a lot of time ?
I'm waiting for suggestions :)
Thank you

It seems like you are running that lengthy operation in the UI thread. Try running it in a separate thread.
private void Button_Click(object sender, RoutedEventArgs e)
{
Task.Factory.StartNew(CallLengthyDllMethod);
}
private void CallLengthyDllMethod()
{
Thread.Sleep(10000); // simulating lengthy operations
MessageBox.Show("Done!");
}

Time-consuming task in MainForm, progress bar in another form

I have a main UI that doing some time-consuming work. When it is executing, I would like to open a second form with a progress bar (marquee style) to indicate "working on it".
I have seen people putting the time-consuming task in the BackgroundWorker, however, I would like to run in the main UI thread.
The time-consuming task will be executed in MainForm. I would like to reuse the progress bar for various process, so I am writing a second form ProgressBarForm with BackgroundWorker in it, that would start the _mainWork at the same time as showing progress bar, and will stop and close the ProgressBarForm when _mainWork is done.
Because forms are modals, I am thinking of showing ProgressBarForm in the BackgroundWorker in order not to block MainForm.
Please note that I am not running mainForm in BackgroundWorker. My backgroundWorker just show the form and perhaps report a timer.
public partial class ProgressBarFom : UControl
{
public delegate void MainWork();
private MainWork _mainWork;
private void backgroundWorker_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
{
//progressBar.Hide();
this.OnClose(sender, e);
//
backgroundWorker.Dispose();
}
private void backgroundWorker_DoWork(object sender, DoWorkEventArgs e)
{
//show this ProgressBarForm
this.ShowDialog();
//stop backgroundWorker
//calling this.Close() in RunWorkerComplete
if (backgroundWorker.CancellationPending == true)
{
e.Cancel = true;
return;
}
}
public void CallProgressBar(object sender, EventArgs e)
{
//progressBar.Show();
backgroundWorker.RunWorkerAsync();
_mainWork();
if (backgroundWorker.IsBusy)
backgroundWorker.CancelAsync();
}
}
In MainForm, I am passing mainwork and call ExecWithProgressBar
private void ExecWithProgressBar()
{
ProgressBarFom .MainWork mainWork = new ProgressBarFom .MainWork(ProgressBarMainWork);
ProgressBarFom prBar = new ProgressBarFom (mainWork);
prBar.CallProgressBar(null, null);
}
Some problems I encoutered
Inside DoWork, the same modal issue occurs. ShowDialog() will block the thread and therefore I never get to check CancellationPending to close ProgressBarForm.
ProgressBarForm starts later then the mainWork. I thought when I called CallProgressBar, the backgroundWorker should start well before my mainWork.
Is worker.Dispose() necessary in RunWorkerComplete?
Would it be a better choice to run mainWork in Worker? And why? I decided to let the main thread run this to not disturb the normal flow, what in Main thread will remain in Main thread, Progress bar is like an addon. If we bring it to the worker, would we need another thread to for progress bar itself?

Unless you do some very ugly hacks (like running more than one message loop inside your application) you cannot display a dialog if the thread running the main window is busy. All dialogs use the same thread to do the display update stuff in WinForms. In fact, they even must be running on the same thread.
There's one (sometimes acceptable) hack using Application.DoEvents(), but I wouldn't use it either, because it gets you into a lot of problems as well.
So the simple answer is: This doesn't work. Use a background worker to do lengthy processing.

Minimize form to system tray

I want to hide my form while keeping my application running in background.
I've used notifyIcon and it remains always visible.
I've used "this.Hide();" to hide my form but unfortunately my application gets close (no exception).
I am also using threading and this form is on second thread.
Please tell me how can I solve it.

I am also using threading and this form is on second thread.
My crystal ball says that you've used ShowDialog() to show the form. Yes, calling Hide() on a modal dialog will close it. Necessarily so, a modal dialog normally disables all of the windows in the application. If you hide it then there's no way for the user to get back to the program, there are no windows left to activate. That this form runs on another thread otherwise doesn't factor into the behavior.
You'll need to call Application.Run(new SomeForm()) to avoid this. Now it isn't modal and you can hide it without trouble. But really, do avoid showing forms on non-UI threads. There's no reason for it, your main thread is already quite capable.

add the following event handlers for form resize and notify icon click event
private void Form_Resize(object sender, EventArgs e)
{
if (WindowState == FormWindowState.Minimized)
{
this.Hide();
}
}
private void notifyIcon_Click(object sender, EventArgs e)
{
this.Show();
this.WindowState = FormWindowState.Normal;
}
but this is not close you application

WPF form should resize to show its content

When WPF window appear first time, its content seem frozen. To refresh content I need to resize form, then it will be fixed. Or I hit the TAB then find a listbox -it's not visible- and click it and viola! Form updates its content again.
What do you think? Weird huh? Thanks in advance!
Edit:
private void Window_Loaded(object sender, RoutedEventArgs e)
{
this.Show();
while (!AppMain.needClose)
{
System.Windows.Forms.Application.DoEvents();
DoThings();
}
}

Resizing the window would force the internals to invalidate and re-paint. You could try invalidating the form when it's loaded to force it to do the same:
private void Window_Loaded(object sender, RoutedEventArgs e)
{
this.Show();
this.Invalidate();
while (!AppMain.needClose)
{
System.Windows.Forms.Application.DoEvents();
DoThings();
}
}
Unless you're doing some sort of custom message pumping though, the standard forms message pump should do that while loop for you. You might well find that because you're intercepting the window loaded event you're stopping initialisation from completing.
Calling DoEvents is a bad code smell in my experience. If you need to do something periodically, it's better to trigger it from a timer of some sort.

When your window is loaded it's already shown, why are you calling this.show() again??

Popping a MessageBox for the main app with Backgroundworker in WPF

In a WPF app, I am using a BackgroundWorker to periodically check for a condition on the server. While that works fine, I want to pop a MessageBox notifing the users if something fails during the check.
Here's what I have:
public static void StartWorker()
{
worker = new BackgroundWorker();
worker.DoWork += DoSomeWork;
worker.RunWorkerAsync();
}
private static void DoSomeWork(object sender, DoWorkEventArgs e)
{
while (!worker.CancellationPending)
{
Thread.Sleep(5000);
var isOkay = CheckCondition();
if(!isOkay)
MessageBox.Show("I should block the main window");
}
}
But this MessageBox does not block the main window. I can still click on my WPF app and change anything I like with the MessageBox around.
How do I solve this? Thanks,
EDIT:
For reference, this is what I ended up doing:
public static void StartWorker()
{
worker = new BackgroundWorker();
worker.DoWork += DoSomeWork;
worker.ProgressChanged += ShowWarning;
worker.RunWorkerAsync();
}
private static void DoSomeWork(object sender, DoWorkEventArgs e)
{
while (!worker.CancellationPending)
{
Thread.Sleep(5000);
var isOkay = CheckCondition();
if(!isOkay)
worker.ReportProgress(1);
}
}
private static void ShowWarning(object sender, ProgressChangedEventArgs e)
{
MessageBox.Show("I block the main window");
}

Replace
MessageBox.Show("I should block the main window");
with
this.Invoke((Func<DialogResult>)(() => MessageBox.Show("I should block the main window")));
that will cause the message box to be on the main thread and will block all access to the UI until it gets a response. As a added bonus this.Invoke will return a object that can be cast in to the DialogResult.

It doesn't only not block the main window, it is also very likely to disappear behind it. That's a direct consequence of it running on a different thread. When you don't specify an owner for the message box then it goes looking for one with the GetActiveWindow() API function. It only considers windows that use the same message queue. Which is a thread-specific property. Losing a message box is quite hard to deal with of course.
Similarly, MessageBox only disables windows that belong to the same message queue. And thus won't block windows created by your main thread.
Fix your problem by letting the UI thread display the message box. Use Dispatcher.Invoke or leverage either the ReportProgress or RunWorkerCompleted events. Doesn't sound like the events are appropriate here.

Call ReportProgress and pass this to MessageBox.Show.

As Stephen and Hans have said, use the ReportProgress event, and pass data to the UI thread. This is especially important if you want to do anything other tha a MessageBox (for isntance, update a control) because the background thread can't do this directly. You'll get a cross-thread exception.
So whatever you need to do (update progress bar, log messages to the UI, etc.), pass data to the UI thread, tell the UI thread what needs to be done, but let the UI thread do it.

I modified it like this and worked fine for me
return Application.Current.Dispatcher.Invoke(() => MessageBox.Show(messageBoxText, caption, button, icon));