Framework freezes on control access?

[Rab Hallett]

In certain situations, accessing a simple control property can cause our
entire application to freeze. On inspection, it has always frozen inside a
framework call, such as Control.Visible.

system.windows.forms.dll!System.Windows.Forms.Control.SetVisibleCore(bool
value = false) + 0x47e bytes

system.windows.forms.dll!System.Windows.Forms.Control.set_Visible(bool
value = false) + 0x18 bytes
MTController.exe!MTApplication.cLabelSafe.set_Visible(Boolean bValue =
False) Line 55 + 0x10 bytes Basic

The only thing I can think of is that there is a Windows message pump
deadlock inside the control.

My initial thought was that it was because the application was accessing
controls in a worker thread. I don't know why this is bad in .NET, but I
understand it is, so I wrapped everything with invoked delegates. This
stopped it happening inside worker threads, but now it's happening in the
main thread. The main thread is not using invoke.

Is this a known problem? Is there a common solution?

Cheers
Rab

 

[Rab Hallett]

C'mon experts - there must be an answer to this?

This seems to be a framework problem, as it is freezing inside the framework
in so many different places. There must be someone with some idea of why the
framework would do this. Has *anyone* heard of anything like this before in
framework 1.1?

Cheers
Rab

 

[Guest]

I am seeing a very similar issue - it would appear to be a Win32 deadlock of
some kind (in SetWindowPos maybe?) - if you figure this out, please post an
answer
Andrew

 

[Guest]

FWIW, I figured out my issue - I had an event handler that occasionally
executed before the control handle was created. If the control handle is not
created, InvokeRequired returns false and this in turn lead to a deadlock
situation when the thread tried to muck with the control
Andrew