Reply to: .NET 2.0/.NET 1.1/Com Interop

[DimPrawn]

I told you. .NET was written by one guy in India who was paid $50 a day.

[AtW]

The fact that one is not provided is, ultimately, complete pants.

Well said.


Now confession time - DimPrawn while at M$, did you work on .NET GUI? Be honest...

[ASB]

You CAN update the controls on a different thread.

I don't think that is in dispute. But the fact is it is write only. you can't get to any of the properties since they are not thread safe.

In 1.1 in practice this doesn't seem to be a problem, but for those you do need access to you have to override them and put the access in a lock block (or more typically just hope for the best judging by the reivews I have done ).

In 2.0 it appears to be worse. AIUI property access from a thread other than the owning thread just throws a "ha ha wrong thread" type exception.

Generally then it does become necessary to maintain a copy of the property locally and acess the copy via a lock block. But this still becomes a pain because methods which update the property will also need to be overridden to update the local copy. Then of course there is the issue of the fact that some control visual representations are only controlled by property access. Although there is usually a workaround (e.g. text box 'text' -> can use ClearText then AppendText but this gives more flicker).

I am sure there is some visual element somewhere in one of the control the control that can only be updated by property access. So now you are truly stuffed. This then does involve a timer callback opr similar.

It would appear you can solve a lot of these issues in 2.0 with a backgroundworker. But that is only going to work if the second thread occurs as a result of user interaction. How will it help when the second thread is independant? Perhaps it's monitoring a device on the RS232 and needs to give some feedback as to how it is working.

Ultimately if you have a multi thread app (and one is encouraged to use other threads rather than timers etc) then you do need a threadsafe UI. The fact that one is not provided is, ultimately, complete pants.

[AtW]

If you use only certain properties such as text value for text label, it means that you can always return current most up to date (changed immediately after all) internal value, and actual representation on screen can be updated later: this in principle is no different to dirty reads in the database - it is faster but there may be small risk of reading old data, even though since this is GUI we talking about its not something very critical.

[Cowboy Bob]

or put it into queue of updates

That's definitely something you don't want to do, especially on a canvas type component. Say one thread adds something to the queue which then blocks (since you want it to be threadsafe), then you get a whole load of other additions to the queue from other threads. When the blocking thread finally lets go, you'll get a strobe effect as all the other updates happen. Not good. At least if you use the event dispatcher this problem goes away as the component will be updated on it's own timer thread (and may miss out certain events altogether if new ones have come in). Finally, don't even think about doing double buffering if you have an update queue, meaning all animation (at least smooth animation) will be out of the window as well.

The toolkit needs to handle all components homogeneously, not treat buttons differently for example. And if you consider all the various types of components you can have, your solution really wouldn't work.

[DimPrawn]

Ignore AtW.

You CAN update the controls on a different thread.

You just have to call Invoke or BeginInvoke. Simple stuff. I don't really see the problem.

AtW really likes to make a mountain out of a molehill.

However, there is a bug in 1.1 that causes Invoke to hang intermittently on multi core/cpu machines

http://support.microsoft.com/kb/896665/

[AtW]

If the .NET GUI controls can't do this then I retract my statement.

Its possible they can do it, but my point is that I don't want to know specifics of that - I just want to set Control's value to new value and it should update it in a way that is right - either directly if its the same thread, or put it into queue of updates: either way there is no need to make programmer worry about stuff like that, they seriously goofed up about it because for Windows GUI work is bread and butter, it should be perfect - Java is expected to have problem on that front, but .NET should have been perfect. Thanksfully I don't do much of GUI in .NET anyway.

[Cowboy Bob]

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

Ahhh, maybe this is the difference. In Swing you can join your update thread to the event dispatcher and tell it to either update immediately, or wait until the joining thread has finished. If the .NET GUI controls can't do this then I retract my statement.

The SwingUtilities class provides two methods to help you run code in the event-dispatching thread:

* invokeLater(): Requests that some code be executed in the event-dispatching thread. This method returns immediately, without waiting for the code to execute.

* invokeAndWait(): Acts like invokeLater(), except that this method waits for the code to execute. As a rule, you should use invokeLater() instead of this method.

[DimPrawn]

Microsoft are taking a Sharia law view on upgrades.

Anyone who doesn't quickly upgrade to Vista will be beheaded.

[AtW]

There are a handful of properties that you would want to access from another thread that does the real job - this would be stuff like Text for labels, text fields, Value for progress indicators and stuff like that - probably less than 10 in total would cover 98% of cross- thread-access requirement. Therefore it makes sense to workaround those in controls and say explicitly that THESE properties are okay to use from other threads. Given how much resources Microsoft has got it is really inexcusable not to do so.

As for Vistas stuff one would have to be insane to target it exclusively for at least 2-3 years.

[DimPrawn]

WinForms is going away soon anyway. It's all XAML and Avalon.

[ASB]

Why would the owning thread be busy, apart from servicing the user clicking on controls?

All other work should be done on non-GUI threads?

Granted it shouldn't be, but maybe the guy writing the UI has done something silly. Perhaps popped up a modal form saying "press the cancel button when you get bored waiting. I agree this would be bad practice, but maybe they thought "hey this is an easy way to deal with it while I wait". Of course the other issue is that you can acess the method on the other thread through invoke. But that doesn't help with the properties.

[AtW]

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

What I want to do is simple, suppose oPI is a ProgressIndicator object that shows progress from 0 to 100, it has got property called Value that is updated by the program to show progress, simple right?

What I want to do is that I can access Value property from any thread, and if control detects that access is done from any other thread than GUI, then the control itself would does all the dirty stuff that needs to be done in order for safe increase of that value - its much cheaper to do it once in that control, and to make it simpler only handful of properties could be declared thread safe, say for labels its text, for checkboxes its state etc.

And that's it - this would make .NET provide time savings to developers, and if Java does not do it then even better - its competitive advantage. I swear of I was Bill Gates and Microsoft programmer told me to call that Syncroniseable crap or use separate timer thread (like I have to do now) then I'd give him 24 hours to fix the crap or clear up the desk.

The way I have to do now is to save values that needs to be updated into array or hashtable and Timer object calls timer thread that is on GUI itself and does all the updating. This could have been done internally ffs!

[DimPrawn]

Why would the owning thread be busy, apart from servicing the user clicking on controls?

All other work should be done on non-GUI threads?

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