Reply to: WPF Dispatcher

[Jaws]

So this tulip is still a part of windows development in .NET?

I only recently had the pleasure of this 'updating the GUI on differnet threads' bollox on an old winforms app. I thought that WPF would have solved this. Huh.

I'll stick with ASP.NET then as this seems to have it abstracted away

From what I've seen regarding WPF the idea is to use the Model-View-ViewModel pattern and rely on data binding to update your GUI rather than updating it imperatively.

[AtW]

I only recently had the pleasure of this 'updating the GUI on differnet threads' bollox on an old winforms app. I thought that WPF would have solved this. Huh.

I suspect this tulip is still part of Win32 API, though I've never programmed it deep enough to be sure.

The whole GUI part of .NET is very poorly done. Good thing I don't have to use it much...

[Shimano105]

So this tulip is still a part of windows development in .NET?

I only recently had the pleasure of this 'updating the GUI on differnet threads' bollox on an old winforms app. I thought that WPF would have solved this. Huh.

I'll stick with ASP.NET then as this seems to have it abstracted away

[AtW]

I am not talking about it being difficult. I am saying a polling loop to update GUI from state (which is what using a timer achieves) is fundamentally a bad design in a Windows GUI application.

It's not great, but I'd say much more fundamentally bad design of Windows GUI is its inability (in .NET) to get updated easily from threads other than main GUI thread.

[d000hg]

Eh? Timer calls function that updates GUI elements, it can call actual class functions who know how to do it, only this happens on the GUI thread so no issues. Also function can be smart enough to only update visible components or changed values, trivial to do.

I am not talking about it being difficult. I am saying a polling loop to update GUI from state (which is what using a timer achieves) is fundamentally a bad design in a Windows GUI application.

[Jaws]

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.

I dunno but I expect updating that label via the dispatcher or the backgroundworker would have been a lot simpler than spending the time creating that post. Possibly the most frustrating thing about programming at all is the amount of time some people will spend discussing why they shouldn't change 5 lines of their code as opposed to just doing it!

[suityou01]

Eh? Timer calls function that updates GUI elements, it can call actual class functions who know how to do it, only this happens on the GUI thread so no issues. Also function can be smart enough to only update visible components or changed values, trivial to do.

I've written games long time ago and one lesson I learnt early on was that redrawing whole lot is faster in reality than trying to be too smart - these days even low end computers have powerful graphics accelerators and Windows is smart enough to avoid updating invisible elements.

It should have been possible to have multi-threaded access to GUI - the fact that Microsoft still did not manage to implement it in a clean new project (.NET) is pathetic, but then again the whole of WinForms was poorly designed and WPF seems rather too heavy.

I am actually planing to do more GUI work soon, and still can't decide whether I should stick with rather pathetic WinForms or take huge risk with WPF.

Oh go with WPF, it's wicked man.

[AtW]

Yes that part's fine, it's the whole "run a loop to see what's changed"

Eh? Timer calls function that updates GUI elements, it can call actual class functions who know how to do it, only this happens on the GUI thread so no issues. Also function can be smart enough to only update visible components or changed values, trivial to do.

I've written games long time ago and one lesson I learnt early on was that redrawing whole lot is faster in reality than trying to be too smart - these days even low end computers have powerful graphics accelerators and Windows is smart enough to avoid updating invisible elements.

It should have been possible to have multi-threaded access to GUI - the fact that Microsoft still did not manage to implement it in a clean new project (.NET) is pathetic, but then again the whole of WinForms was poorly designed and WPF seems rather too heavy.

I am actually planing to do more GUI work soon, and still can't decide whether I should stick with rather pathetic WinForms or take huge risk with WPF.

[d000hg]

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.

Yes that part's fine, it's the whole "run a loop to see what's changed" aspect that seems to totally fly in the face of how a GUI app should work... though to be fair an update loop is not that unusual when coders can't find how to make the GUI behave as it should.

[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.

[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.

[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]

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]

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]

You are confusing me with somone WGAS.

I confused you with someone WKAS