"Mcmullan, Andy (Andrew)" <[EMAIL PROTECTED]> wrote: > What you are asking here is quite a lot. Every GUI object > would need to check on entry to every method call whether > the calling thread is the thread that created the object. Big > overhead in terms of code to be written, and big performance > overhead at runtime.
I'll buy the code writing overhead, but definitely not the performance overhead. Bear in mind that a high proportion of the methods and properties of Control end up calling into SendMessage. This has different behaviour depending on whether you call it on the thread that owns the HWND or some other thread. (For the former it bypasses the message queue, for the latter it dumps the message in the queue and then waits for it to be serviced.) This means that the thread ID test is already being done anyway at the Win32 layer. What exactly is so expensive about testing a thread ID? The Win32 GetCurrentThreadID method is all of 3 instructions in Windows XP, one of which is RET... So it's that and a comparison. This is pretty small beer compared to anything that has some visible effect on the UI. So I really don't understand the performance argument. And as for the code writing overhead... Well you could make that argument about any parameter checking - why bother throwing exceptions when invalid arguments are passed in when you can just exhibit unpredictable behaviour?.. This is not a strong argument for not checking that entry conditions have been met. -- Ian Griffiths DevelopMentor -----Original Message----- From: Jeff Roberts [mailto:[EMAIL PROTECTED]] It sure would have saved me a lot of time if an exception had been thrown ! You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
