.NET 2.0/.NET 1.1/Com Interop

[DimPrawn]

In .NET 2.0 they introduced the Backgroundworker class just for the example you mention AtW.

http://www.knowdotnet.com/articles/b...undworker.html

All easy peasy now.

[AtW]

Background worker is almost certainly another name for using Timer callback that will be done on GUI thread and thus its safe to update GUI controls: what this approach effectively does is storing some variables used to update GUI, and then update GUI from those variables. The problem is that if you have lots of GUI controls it means you need todo a lot of manual assigning, which facilitates copy/paste approach where you will inevitable miss or mistake some vars. Very annoying and waste of development time.

What they needed to do is detect if control is being updated from another thread, then save this value internally and do actual update when GUI itself gets its own internal timer call. This way all updates will be done regardless from which thread they were accessed and programmers can focus on real work, not primitive wasteful coding.

By the way I found that usage of lock{} command causes weird problems even though in theory I used it legitimately.

[hyperD]

In .NET 2.0 they introduced the Backgroundworker class just for the example you mention AtW.

http://www.knowdotnet.com/articles/b...undworker.html

All easy peasy now.

Cool. Almost as good as Master Templates.

hyperD in "Drag n Drop Controls in the Designer" mode

[Cowboy Bob]

I mean - the whole point of multiple threads in GUI programs is to ensure that GUI is not locked while something heavy is going on, thus some results are almost always done in other than GUI thread, and GUI needs to be updated.

Which is what an event dispatcher thread is for - as mentioned in the article I linked earlier. Once you've used an event based model of GUI design you won't want to go back I can assure you. As I said, there's a lot of things wrong with Swing, but the thread model isn't one of them.

[DimPrawn]

Sorry I don't get your point. How is Swing any different from native Win32 controls? Both can only be updated by one thread, the thread they were created on.

To my (non Java) eyes, Swing is almost identical to .NET Winforms and vice versa????

[Cowboy Bob]

Sorry I don't get your point. How is Swing any different from native Win32 controls? Both can only be updated by one thread, the thread they were created on.

To my (non Java) eyes, Swing is almost identical to .NET Winforms and vice versa????

I never said it was different, just that I've only used Swing and know where to find the articles. What I'm saying is that this is the correct way to code a GUI toolkit with regard to multi-threading IMO. If they are indeed the same, then I fail to see what AtW is complaining about.

[AtW]

If they are indeed the same, then I fail to see what AtW is complaining about.

ok, here is in other shorter words:

1) Applications with GUI have to be multi-threaded in order to avoid GUI being frozen while some work is done (like IO wait for URL to be retrieved)

2) Since work is done in separate from GUI thread it means that GUI needs to be updated

3) You cant update .NET GUI from another thread - in .NET 1.1 it would lead to weird situations in some cases and in .NET 2.0 they throw exception to avoid such rare but real situations

So, programmer would either have to create bad software that would use GUI thread for work that may freeze it for no reason (users will think program did hang), or store changes they wanted to make to GUI controls in variables, and then assign GUI controls with values of those variables in GUI thread itself - for this I use timer control, all works fine.

What's my problem? My problem is that I had to waste time writing that primitive code, why should I and many others do it when it could have been done by Microsoft ONCE? They already can detect if control is being updated from another thread, in this case instead of throwing exception like they do now, they should have behind the scenes put those values for deferred update that could have happened in 0.1 second, completely transparent to the programmer - no time wasted. This is .NET team's issue - I appreciate that Win32 is not thread safe, but who prevented Microsoft from making some controls that are most likely to be updated from other threads like Progress Indicator to do such deferred updates without requiring each .NET programmer to do that manually?

There is no reason - its a big flaw on Microsoft's behalf, IMO worth firing some people for not recognising their responsibility of making sure threads work very well with GUI.

[DimPrawn]

ignore AtW. He wants to rewrite .net in assembler in his spare time.

[DimPrawn]

AtW you don't have to use this strange timer and variables nonsense.

You can update the GUI controls by calling the methods on the ISynchronizeInvoke interface on the GUI control

[ASB]

AtW you don't have to use this strange timer and variables nonsense.

You can update the GUI controls by calling the methods on the ISynchronizeInvoke interface on the GUI control

I must admit that was my view and what I implemented, i.e. check invokerequired, build delegate and call invoke (like AtW I beleive this should happen automatically though). But - and it is a big but - this is only OK if the owning thread is not blocked for any reason. so if the control is created on the main thread and the gui is quiescent - i.e. everything is on worker threads or the processes involved are short then it is OK. However if the owning thread is busy its hang time for the second thread.

One possible way round is to create an async delegate and call begininvoke, this is going the be simple enough for outbound only.

I'll check the backgroundworker thing thet HyperD posted up too.