WPF Dispatcher

[d000hg]

Tosser.

DP did have a point, until you clarified. It hurts to say it, mind.

[DimPrawn]

Can BackgroundWorker update any or all GUI elements from within its own thread? It seems that it can report progress via callbacks, but can it change other elements like text on GUI?

The background worker cannot access the GUI thread directly, but can access the controls using the Threading.Dispatcher


http://www.diranieh.com/NET_WPF/Threading.htm

In otherwords the worker thread or threads dispatch updates to the GUI thread using a queue. The worker thread can either wait for the update to occur or dispatch the GUI updates asynchronously.

http://msdn.microsoft.com/en-us/library/ms741870.aspx

So yes, the background worker can update any GUI element, but only safely and easily via the Dispatcher.

[AtW]

The background worker cannot access the GUI thread directly, but can access the controls using the Threading.Dispatcher

How is it easier than having a single Timer thread that will update GUI safely and at regular intervals by checking currently run background tasks (they can still use Backgroundworker) that will update their own internal class variables?

Either way the fact that you can't update GUI from another thread is rubbish design of .NET - should have been fixed in 2.0, though personally I prefer to have single point of GUI updating with business logic not knowing about GUI at all: with background worker you'll be mixing business with GUI, OR creating extra layer (Background worker itself) between GUI and business logic.

Conclusion - your suggestion is a flower that is commonly associated with Holland.

And on this point I flush you down my newly rebuild expensive toilet piping. Or should I say my landlady's?

HTH

[DimPrawn]

You are confusing me with somone WGAS.

[AtW]

You are confusing me with somone WGAS.

I confused you with someone WKAS

[d000hg]

How is it easier than...

Since when is the proper design the easiest one? It's easier to have all class members public... though being able to do GUI stuff cross-thread would be nice, are there design issues such as performance to think about?

[AtW]

though being able to do GUI stuff cross-thread would be nice, are there design issues such as performance to think about?

We are not talking about here games performance - it's bonkers that non-GUI thread can't update text label with current value, if they are so worked out about it then Microsoft should have implemented internal locking to do the job.

The whole WinForms implementation in .NET is poor - it was clearly done by very different people (quality wise) than CLR team who were excellent.

Personally I think simple timer callback that will update GUI that is necessary is much easier and faster (coding time and performance wise) than using DimPrawn's approach, though I admit my way might have negative effect on amount of money earned from the same coding task

[d000hg]

Personally I think simple timer callback that will update GUI that is necessary is much easier and faster (coding time and performance wise) than using DimPrawn's approach, though I admit my way might have negative effect on amount of money earned from the same coding task

To me, a polling loop updating GUI from stored state is a horrible design, it's just plain bad. However, it's not that uncommon so it depends where you draw the line between 'perfect design' (virtually impossible in most software) and 'whatever I can get in faster' (which leads to crappy code). Everyone has their own place on that spectrum.

[AtW]

To me, a polling loop updating GUI from stored state is a horrible design, it's just plain bad. However, it's not that uncommon so it depends where you draw the line between 'perfect design' (virtually impossible in most software) and 'whatever I can get in faster' (which leads to crappy code). Everyone has their own place on that spectrum.

GUI update function in underlieing object can be called by the Timer thread which is ok to change GUI, so if you want you can keep your GUI update implementation inside your classes.

[suityou01]

We are not talking about here games performance - it's bonkers that non-GUI thread can't update text label with current value, if they are so worked out about it then Microsoft should have implemented internal locking to do the job.

The whole WinForms implementation in .NET is poor - it was clearly done by very different people (quality wise) than CLR team who were excellent.

Personally I think simple timer callback that will update GUI that is necessary is much easier and faster (coding time and performance wise) than using DimPrawn's approach, though I admit my way might have negative effect on amount of money earned from the same coding task

Got to agree with ATW here. I found the dispatcher object was the recommended solution, although I am not ruling out Dimbo Prawn's solution, that needs careful thought and if that has more merit then I shall implement that. As DP pointed out, the robustness and maintainability of the end product is key here. I am grateful for the feedback as it gives me a well rounded poll of opinions and I can add better value to the customer by not being afraid to ask.

Perhaps DP was having a bad day, or perhaps he took my binding an array to a datagrid thread far too seriously. I can see that my posts being my only input into his otherwise dull existence he would get a bad opinion of me and don't blame him for that. I have good underpinning knowledge and experience of C, C++, C# and multithreading.

I had just not realised what a c<nt WPF is when it comes to handling this tulip. I fully agree with ATW that each object should have a better implementation of cross thread chat for something as simple as updating a label caption FFS.

Praps

MyBstardLabel.Caption.UpdateByDispatcher(Value)

I dunno but would cut out a lot of the ball ache.