.NET 2.0/.NET 1.1/Com Interop

[AtW]

Some clown at Microsoft thought it was a good idea to kill whole app just because one thread dies - it was much more correct to kill that thread, thankfully they had that backwards compatibility switch.

And yes ASB - the problem I had was because exception was happening in async callback outside of my control (which is bad design IMO), I solved the issue by using that config file with backwards compatibility setting that made .net 2.0 use same exception handling as in .net 1.1

Yes, btw GUI update from other thread - was bad idea in .net 1.1, but it causes exception in .net 2.0 - its annoying to have to workaround that manually, they really should have thought of chaining such updates in their own thread and executing them quickly and threadsafely rather than making programmer do that all manually, annoying, but thankfully I dont do much GUI.

I suspect the actual GUI bit of .NET was done by pure Microsoft programmers, where as FrameWork itself and C# were done by new ex-Borland guys who certainly did a very good job.

[AtW]

An unhandled exception on the non main thread still goes to the installed unhandled exception handler (famous last words ).

That's the real problem - this unhandled exception handler was designed to supress such thread failurs to avoid having whole app being killed, but in .net 2.0 by default changed behavior meant that even if you catch that unhandled exception in handler it was still killing app, so in effect unhandled exception handler was not supressing the exception!

[ASB]

Yes, btw GUI update from other thread - was bad idea in .net 1.1, but it causes exception in .net 2.0

I'm not sure if that's better or worse! In 1.1 the argument was that it was wanted to be as performance optimal as possible. The results are that some things work, some things dont and other general weirdness. [Frankly I think it is rare a UI is going to need this sort of performance, the overhead is only to check the current thread id against the main thread id]

Now, if in V2 they throw an exception this means that they must check they are on the right thread. Thus that would be an ideal opportunity to do it the slow way, I feel sure this could easily be built into the controls. I suppose it would be easy enough to inherit the controls and override each method doing it the invoke way if the exception is thrown. But surely that should come out of the box.,

[AtW]

In 1.1 I had to rewrite very carefully how I updated GUI controls - in SOME configs, I think on Multi CPU machiens it was causing real weird problems and hang ups, in .NET 2.0 they started trapping such calls to cause clean exception - this is better than previous behavior which it taking unknown risk that your app may not perform, but better solution would be to make GUI thread safe: this certainly should have been done and available out of the box, perhaps with caveat that performance will be worse (but it should not be much worse), still in many cases updating GUI is not something expensive in terms of CPU.

[DimPrawn]

Everything is sorted in .NET 5.0 so don't worry.

HTH

[TheMonkey]

Everything is sorted in .NET 5.0 so don't worry.

HTH

Useless but insightful.

I'm delving into Cocoa and Objective C at the moment in an effort to escape the constraints that .Net is enforcing on my brain.

As for the Winforms problems, I've not actually experienced that yet! Thank god I primarily talk mid-tier, console and web stuff!

[DimPrawn]

The winforms threading issue is really a problem with the underlying Windows Win32 controls architecture.

Blame the Windows numpties at MS, not the .NET team.

[ASB]

Everything is sorted in .NET 5.0 so don't worry.

HTH

No it won't be. Not divisible by 3 you see.....

[Cowboy Bob]

GUI controls should never be threadsafe internally. It should be up to the programmer to implement thread safety in the manner that is required for their app. Otherwise you'd be cursing even more when controls became unresponsive when a particular thread is running, for example.

See here for a discussion on how and why Sun decided to implement threading in Swing - http://java.sun.com/products/jfc/tsc.../threads1.html

For all of it's drawbacks (and there are many) multi-threading isn't an issue with Swing.

[AtW]

GUI controls should never be threadsafe internally. It should be up to the programmer to implement thread safety

No - it should be up to the framework designer to ensure that millions of programmers don't waste time workarounding the fact that I can't update text of the GUI label from any other thread than the one in which GUI control was created. 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. So, you can make your work easy and not include this in very base framework and make many people reinvent the wheel losing productivity while chasing stupid bugs related to GUI refresh, OR you can implement it once and for all in framework and be done with it.

Microsoft screwed up - they bolted on WinForms on top of Win32 and were too lazy to include internal mechanism to ensure that if non-GUI thread wants to update control, then this update is deferred until internal GUI thread does the job.