Framework freezes on control access?

  • Thread starter Thread starter Rab Hallett
  • Start date Start date
R

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
Click to expand...
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
 
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
 
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
 
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
 
Back
Top