Control.Handle, is this a bug ?

[Guest]

Hi,

[ Using C# in .Net 1.1 ].

I've been struggling with a "hang" in my application all day and I think I
have just worked out why the problem occurs. Please read through and see if
u think this is a bug.

I have a few UI controls that are being updated on a TimerThread ( I check
the "InvokeRequired" and perform the Invoke if required, when I want to
update the control when Im in the TimerThread ). However I was noticing
problems when this occurred as my app would hang. In the debugger I noticed
that just before the hang, the InvokeRequired was returning "False" when it
was being called from the TimerThread - when it should have being returning
"True".

After much swearing etc.. and many hours, I eventually managed to determine
that the "_CreateThreadId" property for my controls was changing **after**
that control was accessed by the TimerThread. I think that this may all be
being caused by the Control.Handle property. It seems as though the handle
isnt actually assigned until you request it, and when you do it overwrites
the "_CreateThreadId" with the ThreadID of the thread that was running when
the Handle was requested. As such this causes the InvokeRequired method to
return the wrong value and then the app gets screwed when the control is
attempted to be updated from the 2 different threads.

Is this a bug ?

As a very simple workaround I request "myControl.Handle" straight after
creating the control and this gets rid of the problem - even though I am not
actually doing anything with it!! A quick workaround, but a horrid problem!!

RichS

NB: Sorry for double post, accidentally posted on "dotnet.framework" first,
when this is a windowsforms problem!

 

[Guest]

Most WinForms controls are designed to lazily create their handles. This
means that the handle isn't created until it is actually needed. Often this
doesn't happen until the control is added to a form which is visible.

Explicitly reading the Handle property causes the handle to be created if it
has not been already.

Your solution of reading the handle property on your main thread is a good
choice if you don't want to make the control visible.

 

[Mehdi]

I think that this may all be
being caused by the Control.Handle property. It seems as though the handle
isnt actually assigned until you request it[...] As such this causes the InvokeRequired method to
return the wrong value and then the app gets screwed when the control is
attempted to be updated from the 2 different threads.

I've had the exact same problem and it also took me ages to find out what
was wrong as i was assuming that i was in the proper thread since i did my
homework, read the doc and therefore took care to always call Invoke before
accessing a UI element from a worker thread.

Is this a bug ?

As Andrew said, this is not a bug but a feature In my opinion though,
this is definitely a documentation bug. This issue should be mentioned in
bold, red and size 30 font in the Control.Invoke and Control.BeginInvoke
methods. I wonder how many months of work have been lost by people trying
to solve this stupid issue.