>>Hi,
>>This is WPF but I think the same would apply to WinForms. I have a piece of code (opening a SQL connection) that can take a while to execute so want to show a progress bar with .Indeterminate set true (I think the WinForms equivalent is setting Style to Marquee?)
>>So

Waiting = true;
>>LongRunningThing();
>>Waiting = false;

- where 'Waiting' is wired up to the ProgressBar.IsIndeterminate. The obvious problem with this is that the UI doesn't get updated during LongRunningThing() so I tried using a BackgroundWorker:

Waiting = true;
>>BackgroundWorker _bgw = new BackgroundWorker();
>> _bgw.DoWork += OpenDb;
>> _bgw.RunWorkerCompleted += WorkDone;
>> _bgw.RunWorkerAsync();
>>
>>void OpenDb(object sender, DoWorkEventArgs args)
>>        {  LongRunningThing(); }
>>
>>void WorkDone(object sender, RunWorkerCompletedEventArgs e)
>>        { Waiting = false; }

which works fine BUT I don't really want the main thread to plough on regardless. But anything I can think of that waits for the worker thread to complete re-introduces the original problem - i.e whilst it is waiting the UI doesn't get updated. I tried using AutoResetEvent with the above and also tried creating my own thread and using Thread.Join()
>>
>>Is there any answer to this or is it a Catch 22 situation ?
>
>
>Viv,
>
>Is the background thread responsible for updating the progress bar ? If yes - take a look here for some ideas http://weblogs.asp.net/cschittko/archive/2008/05/14/wpf-ui-update-from-background-threads.aspx
>
>If not, you may still want to take a look, may be you can sort it out with a timer in the main thread that updates the UI whilst the background thread is running

Hi,
Thanks for the link - I'll look at it properly tomorrow.
Anyway:
The background thread is opening the SQL connection. Setting the ProgressBar.IsIndeterminate to true means it doesn't need any specific instructions to show progress. It just keeps rolling along - providing the main thread isn't blocked.
Also, I'm using MVVM pattern and the code above is in the VM so any direct manipulation of UI via the Dispatcher is a no-no...

I've got this working by also binding the IsEnabled property of critical UI controls to the Waiting property on the VM.
I don't think I'd really thought through on my original plan because, logically, I probably needed to do this anyway - if the UI thread is getting processing time to update the ProgressBar then, by definition, it could also use those slices to accept button clicks, etc. - which is exactly what I was trying to avoid.