"Rab Hallett" <withheld> wrote in message
news:%23E0rR1AyFHA.2516@TK2MSFTNGP12.phx.gbl...
> 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" wrote:

> 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
>
>
> "Rab Hallett" <withheld> wrote in message
> news:%23E0rR1AyFHA.2516@TK2MSFTNGP12.phx.gbl...
> > 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
> >
>
>
>

"AndrewEames" wrote:

> 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
>
> "Rab Hallett" wrote:
>
> > 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
> >
> >
> > "Rab Hallett" <withheld> wrote in message
> > news:%23E0rR1AyFHA.2516@TK2MSFTNGP12.phx.gbl...
> > > 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
> > >
> >
> >
> >