WPF Dispatcher

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

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

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

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

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

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

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

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