.NET 2.0/.NET 1.1/Com Interop

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

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

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

[DimPrawn]

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

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

Microsoft are taking a Sharia law view on upgrades.

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

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

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

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

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