Vista - Trial Version of WinForms Controls Break WPF App

I had to test out some third party WinForms controls in a WPF context for
work. I installed a 30-day trial of DevComponent's DotNetBar and used
severak WindowsFormsHost element to host some controls. Since the controls
are being used on trial, they always pop up a dialog stating that "these
controls are a trial version, do you want to buy them, etc." This is the
standard for 3rd party controls being used on a trial basis.

The problem is that the WPF immediately throws an InvalidOperationException
when the app loads. Here's the call stack:

System.InvalidOperationException: Dispatcher processing has been suspended,
but messages are still being processed.
at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32
msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam,
IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate
callback, Object args, Boolean isSingleParameter)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source,
Delegate callback, Object args, Boolean isSingleParameter, Delegate
catchHandler)
at System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority
priority, TimeSpan timeout, Delegate method, Object args, Boolean
isSingleParameter)
at System.Windows.Threading.Dispatcher.Invoke(DispatcherPriority
priority, Delegate method, Object arg)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr
wParam, IntPtr lParam)
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
at
System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32
dwComponentID, Int32 reason, Int32 pvLoopData)
at
System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32
reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32
reason, ApplicationContext context)
at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
at System.Windows.Forms.Form.ShowDialog()
at DevComponents.DotNetBar.RibbonControl.OnHandleCreated(EventArgs e)
at System.Windows.Forms.Control.WmCreate(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.ContainerControl.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg,
IntPtr wparam, IntPtr lparam)

***
After I dismiss that exception window via the 'Continue' button, the app is
frozen. All WPF elements in the app do not respond to user gestures or
repaint. The app is basically dead, except for the WinForms control.

Here's the XAML for the UI:

<Window x:Class="PocWithRibbonBar.Window1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

xmlns:dnb="clr-namespaceevComponents.DotNetBar;assembly=DevComponents.DotNetBar2"

xmlns:wfi="clr-namespace:System.Windows.Forms.Integration;assembly=WindowsFormsIntegration"
Title="PocWithRibbonBar" Height="300" Width="300"
>
<Grid>
<Grid.RowDefinitions>
<RowDefinition Height="Auto" />
<RowDefinition Height="*" />
</Grid.RowDefinitions>

<wfi:WindowsFormsHost>
<dnb:RibbonControl x:Name="ribbonControl" />
</wfi:WindowsFormsHost>

<ListBox Grid.Row="1">
<ListBoxItem>A</ListBoxItem>
<ListBoxItem>B</ListBoxItem>
<ListBoxItem>C</ListBoxItem>
</ListBox>
</Grid>
</Window>

***
I assume that the bug has to do with the fact that the 3rd party controls
are trying to show their licensing message box. I have no idea how to work
around this, but if WPF is going to support WinForms interop, then I think
that this is a pretty important issue to iron out.

Thanks,
Josh Smith

I believe that this exception indicates re-entrancy. Typically, this occurs
when code which is nested within the WPF dispatcher's message loop causes
the message loop to iterate. This in turn is often caused when code calls
"lock" (the CLR lock), since this lock can cause the message loop to pump.
I'm sorry that I don't have a solution personally, but I'll see what I can
do to bring this issue to the attention of the the folks who own the
Dispatcher code.

-Adam Smith [MS]


"Josh Smith" <JoshSmith@discussions.microsoft.com> wrote in message
news:59CA77E4-11A3-422B-8C52-30169AD4EE09@microsoft.com...
>I had to test out some third party WinForms controls in a WPF context for
> work. I installed a 30-day trial of DevComponent's DotNetBar and used
> severak WindowsFormsHost element to host some controls. Since the
> controls
> are being used on trial, they always pop up a dialog stating that "these
> controls are a trial version, do you want to buy them, etc." This is the
> standard for 3rd party controls being used on a trial basis.
>
> The problem is that the WPF immediately throws an
> InvalidOperationException
> when the app loads. Here's the call stack:
>
> System.InvalidOperationException: Dispatcher processing has been
> suspended,
> but messages are still being processed.
> at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32
> msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
> at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam,
> IntPtr lParam, Boolean& handled)
> at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
> at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate
> callback, Object args, Boolean isSingleParameter)
> at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source,
> Delegate callback, Object args, Boolean isSingleParameter, Delegate
> catchHandler)
> at System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority
> priority, TimeSpan timeout, Delegate method, Object args, Boolean
> isSingleParameter)
> at System.Windows.Threading.Dispatcher.Invoke(DispatcherPriority
> priority, Delegate method, Object arg)
> at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr
> wParam, IntPtr lParam)
> at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
> at
> System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32
> dwComponentID, Int32 reason, Int32 pvLoopData)
> at
> System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32
> reason, ApplicationContext context)
> at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32
> reason, ApplicationContext context)
> at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
> at System.Windows.Forms.Form.ShowDialog()
> at DevComponents.DotNetBar.RibbonControl.OnHandleCreated(EventArgs e)
> at System.Windows.Forms.Control.WmCreate(Message& m)
> at System.Windows.Forms.Control.WndProc(Message& m)
> at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
> at System.Windows.Forms.ContainerControl.WndProc(Message& m)
> at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message&
> m)
> at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
> at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg,
> IntPtr wparam, IntPtr lparam)
>
> ***
> After I dismiss that exception window via the 'Continue' button, the app
> is
> frozen. All WPF elements in the app do not respond to user gestures or
> repaint. The app is basically dead, except for the WinForms control.
>
> Here's the XAML for the UI:
>
> <Window x:Class="PocWithRibbonBar.Window1"
> xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
> xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>
> xmlns:dnb="clr-namespaceevComponents.DotNetBar;assembly=DevComponents.DotNetBar2"
>
> xmlns:wfi="clr-namespace:System.Windows.Forms.Integration;assembly=WindowsFormsIntegration"
> Title="PocWithRibbonBar" Height="300" Width="300"
> >
> <Grid>
> <Grid.RowDefinitions>
> <RowDefinition Height="Auto" />
> <RowDefinition Height="*" />
> </Grid.RowDefinitions>
>
> <wfi:WindowsFormsHost>
> <dnb:RibbonControl x:Name="ribbonControl" />
> </wfi:WindowsFormsHost>
>
> <ListBox Grid.Row="1">
> <ListBoxItem>A</ListBoxItem>
> <ListBoxItem>B</ListBoxItem>
> <ListBoxItem>C</ListBoxItem>
> </ListBox>
> </Grid>
> </Window>
>
> ***
> I assume that the bug has to do with the fact that the 3rd party controls
> are trying to show their licensing message box. I have no idea how to
> work
> around this, but if WPF is going to support WinForms interop, then I think
> that this is a pretty important issue to iron out.
>
> Thanks,
> Josh Smith

The underlying issue is described on
http://blogs.msdn.com/nickkramer/arc...06/591252.aspx , although
given that you control neither the HwndHost (which WindowsFormsPost uses) or
the WinForms control popping up the dialog, I can't think of a solution.

--
-Nick Kramer [MSFT]
http://blogs.msdn.com/nickkramer

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Adam Smith [MS]" <Adam.Smith@microsoft.com> wrote in message
news:%23fsyjXSoGHA.3532@TK2MSFTNGP04.phx.gbl...
>I believe that this exception indicates re-entrancy. Typically, this
>occurs when code which is nested within the WPF dispatcher's message loop
>causes the message loop to iterate. This in turn is often caused when code
>calls "lock" (the CLR lock), since this lock can cause the message loop to
>pump. I'm sorry that I don't have a solution personally, but I'll see what
>I can do to bring this issue to the attention of the the folks who own the
>Dispatcher code.
>
> -Adam Smith [MS]
>
>
> "Josh Smith" <JoshSmith@discussions.microsoft.com> wrote in message
> news:59CA77E4-11A3-422B-8C52-30169AD4EE09@microsoft.com...
>>I had to test out some third party WinForms controls in a WPF context for
>> work. I installed a 30-day trial of DevComponent's DotNetBar and used
>> severak WindowsFormsHost element to host some controls. Since the
>> controls
>> are being used on trial, they always pop up a dialog stating that "these
>> controls are a trial version, do you want to buy them, etc." This is the
>> standard for 3rd party controls being used on a trial basis.
>>
>> The problem is that the WPF immediately throws an
>> InvalidOperationException
>> when the app loads. Here's the call stack:
>>
>> System.InvalidOperationException: Dispatcher processing has been
>> suspended,
>> but messages are still being processed.
>> at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32
>> msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
>> at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam,
>> IntPtr lParam, Boolean& handled)
>> at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
>> at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate
>> callback, Object args, Boolean isSingleParameter)
>> at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object
>> source,
>> Delegate callback, Object args, Boolean isSingleParameter, Delegate
>> catchHandler)
>> at System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority
>> priority, TimeSpan timeout, Delegate method, Object args, Boolean
>> isSingleParameter)
>> at System.Windows.Threading.Dispatcher.Invoke(DispatcherPriority
>> priority, Delegate method, Object arg)
>> at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr
>> wParam, IntPtr lParam)
>> at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
>> at
>> System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32
>> dwComponentID, Int32 reason, Int32 pvLoopData)
>> at
>> System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32
>> reason, ApplicationContext context)
>> at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32
>> reason, ApplicationContext context)
>> at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
>> at System.Windows.Forms.Form.ShowDialog()
>> at DevComponents.DotNetBar.RibbonControl.OnHandleCreated(EventArgs e)
>> at System.Windows.Forms.Control.WmCreate(Message& m)
>> at System.Windows.Forms.Control.WndProc(Message& m)
>> at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
>> at System.Windows.Forms.ContainerControl.WndProc(Message& m)
>> at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message&
>> m)
>> at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
>> at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg,
>> IntPtr wparam, IntPtr lparam)
>>
>> ***
>> After I dismiss that exception window via the 'Continue' button, the app
>> is
>> frozen. All WPF elements in the app do not respond to user gestures or
>> repaint. The app is basically dead, except for the WinForms control.
>>
>> Here's the XAML for the UI:
>>
>> <Window x:Class="PocWithRibbonBar.Window1"
>> xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
>> xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>>
>> xmlns:dnb="clr-namespaceevComponents.DotNetBar;assembly=DevComponents.DotNetBar2"
>>
>> xmlns:wfi="clr-namespace:System.Windows.Forms.Integration;assembly=WindowsFormsIntegration"
>> Title="PocWithRibbonBar" Height="300" Width="300"
>> >
>> <Grid>
>> <Grid.RowDefinitions>
>> <RowDefinition Height="Auto" />
>> <RowDefinition Height="*" />
>> </Grid.RowDefinitions>
>>
>> <wfi:WindowsFormsHost>
>> <dnb:RibbonControl x:Name="ribbonControl" />
>> </wfi:WindowsFormsHost>
>>
>> <ListBox Grid.Row="1">
>> <ListBoxItem>A</ListBoxItem>
>> <ListBoxItem>B</ListBoxItem>
>> <ListBoxItem>C</ListBoxItem>
>> </ListBox>
>> </Grid>
>> </Window>
>>
>> ***
>> I assume that the bug has to do with the fact that the 3rd party controls
>> are trying to show their licensing message box. I have no idea how to
>> work
>> around this, but if WPF is going to support WinForms interop, then I
>> think
>> that this is a pretty important issue to iron out.
>>
>> Thanks,
>> Josh Smith
>
>

Thanks for the info about this issue, Nick. I worked around for the problem
by simply adding the 3rd party WinForms control to the WindowsFormsHost in a
Window.Loaded event handling method.

Thanks,
Josh Smith

"Nick Kramer [MSFT]" wrote:

> The underlying issue is described on
> http://blogs.msdn.com/nickkramer/arc...06/591252.aspx , although
> given that you control neither the HwndHost (which WindowsFormsPost uses) or
> the WinForms control popping up the dialog, I can't think of a solution.
>
> --
> -Nick Kramer [MSFT]
> http://blogs.msdn.com/nickkramer
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
> Use of included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm
>
> "Adam Smith [MS]" <Adam.Smith@microsoft.com> wrote in message
> news:%23fsyjXSoGHA.3532@TK2MSFTNGP04.phx.gbl...
> >I believe that this exception indicates re-entrancy. Typically, this
> >occurs when code which is nested within the WPF dispatcher's message loop
> >causes the message loop to iterate. This in turn is often caused when code
> >calls "lock" (the CLR lock), since this lock can cause the message loop to
> >pump. I'm sorry that I don't have a solution personally, but I'll see what
> >I can do to bring this issue to the attention of the the folks who own the
> >Dispatcher code.
> >
> > -Adam Smith [MS]
> >
> >
> > "Josh Smith" <JoshSmith@discussions.microsoft.com> wrote in message
> > news:59CA77E4-11A3-422B-8C52-30169AD4EE09@microsoft.com...
> >>I had to test out some third party WinForms controls in a WPF context for
> >> work. I installed a 30-day trial of DevComponent's DotNetBar and used
> >> severak WindowsFormsHost element to host some controls. Since the
> >> controls
> >> are being used on trial, they always pop up a dialog stating that "these
> >> controls are a trial version, do you want to buy them, etc." This is the
> >> standard for 3rd party controls being used on a trial basis.
> >>
> >> The problem is that the WPF immediately throws an
> >> InvalidOperationException
> >> when the app loads. Here's the call stack:
> >>
> >> System.InvalidOperationException: Dispatcher processing has been
> >> suspended,
> >> but messages are still being processed.
> >> at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32
> >> msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
> >> at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam,
> >> IntPtr lParam, Boolean& handled)
> >> at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
> >> at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate
> >> callback, Object args, Boolean isSingleParameter)
> >> at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object
> >> source,
> >> Delegate callback, Object args, Boolean isSingleParameter, Delegate
> >> catchHandler)
> >> at System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority
> >> priority, TimeSpan timeout, Delegate method, Object args, Boolean
> >> isSingleParameter)
> >> at System.Windows.Threading.Dispatcher.Invoke(DispatcherPriority
> >> priority, Delegate method, Object arg)
> >> at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr
> >> wParam, IntPtr lParam)
> >> at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
> >> at
> >> System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32
> >> dwComponentID, Int32 reason, Int32 pvLoopData)
> >> at
> >> System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32
> >> reason, ApplicationContext context)
> >> at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32
> >> reason, ApplicationContext context)
> >> at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
> >> at System.Windows.Forms.Form.ShowDialog()
> >> at DevComponents.DotNetBar.RibbonControl.OnHandleCreated(EventArgs e)
> >> at System.Windows.Forms.Control.WmCreate(Message& m)
> >> at System.Windows.Forms.Control.WndProc(Message& m)
> >> at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
> >> at System.Windows.Forms.ContainerControl.WndProc(Message& m)
> >> at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message&
> >> m)
> >> at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
> >> at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg,
> >> IntPtr wparam, IntPtr lparam)
> >>
> >> ***
> >> After I dismiss that exception window via the 'Continue' button, the app
> >> is
> >> frozen. All WPF elements in the app do not respond to user gestures or
> >> repaint. The app is basically dead, except for the WinForms control.
> >>
> >> Here's the XAML for the UI:
> >>
> >> <Window x:Class="PocWithRibbonBar.Window1"
> >> xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
> >> xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
> >>
> >> xmlns:dnb="clr-namespaceevComponents.DotNetBar;assembly=DevComponents.DotNetBar2"
> >>
> >> xmlns:wfi="clr-namespace:System.Windows.Forms.Integration;assembly=WindowsFormsIntegration"
> >> Title="PocWithRibbonBar" Height="300" Width="300"
> >> >
> >> <Grid>
> >> <Grid.RowDefinitions>
> >> <RowDefinition Height="Auto" />
> >> <RowDefinition Height="*" />
> >> </Grid.RowDefinitions>
> >>
> >> <wfi:WindowsFormsHost>
> >> <dnb:RibbonControl x:Name="ribbonControl" />
> >> </wfi:WindowsFormsHost>
> >>
> >> <ListBox Grid.Row="1">
> >> <ListBoxItem>A</ListBoxItem>
> >> <ListBoxItem>B</ListBoxItem>
> >> <ListBoxItem>C</ListBoxItem>
> >> </ListBox>
> >> </Grid>
> >> </Window>
> >>
> >> ***
> >> I assume that the bug has to do with the fact that the 3rd party controls
> >> are trying to show their licensing message box. I have no idea how to
> >> work
> >> around this, but if WPF is going to support WinForms interop, then I
> >> think
> >> that this is a pretty important issue to iron out.
> >>
> >> Thanks,
> >> Josh Smith
> >
> >
>
>
>

Glad you found a solution! thinking about it a little more, WinForms has
this nifty Handle property, which creates the hwnd. Anything that directly
or indirectly calls Handle before the layout pass should solve the
problem -- adding the element to a live tree being one example of this,
simply calling the Handle property yourself at a strategic place could be
another approach.


--
-Nick Kramer [MSFT]
http://blogs.msdn.com/nickkramer

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Josh Smith" <JoshSmith@discussions.microsoft.com> wrote in message
news:7D2096DB-BCDC-43B6-8E34-C1F5F9224FD6@microsoft.com...
> Thanks for the info about this issue, Nick. I worked around for the
> problem
> by simply adding the 3rd party WinForms control to the WindowsFormsHost in
> a
> Window.Loaded event handling method.
>
> Thanks,
> Josh Smith
>
> "Nick Kramer [MSFT]" wrote:
>
>> The underlying issue is described on
>> http://blogs.msdn.com/nickkramer/arc...06/591252.aspx ,
>> although
>> given that you control neither the HwndHost (which WindowsFormsPost uses)
>> or
>> the WinForms control popping up the dialog, I can't think of a solution.
>>
>> --
>> -Nick Kramer [MSFT]
>> http://blogs.msdn.com/nickkramer
>>
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> Use of included script samples are subject to the terms specified at
>> http://www.microsoft.com/info/cpyright.htm
>>
>> "Adam Smith [MS]" <Adam.Smith@microsoft.com> wrote in message
>> news:%23fsyjXSoGHA.3532@TK2MSFTNGP04.phx.gbl...
>> >I believe that this exception indicates re-entrancy. Typically, this
>> >occurs when code which is nested within the WPF dispatcher's message
>> >loop
>> >causes the message loop to iterate. This in turn is often caused when
>> >code
>> >calls "lock" (the CLR lock), since this lock can cause the message loop
>> >to
>> >pump. I'm sorry that I don't have a solution personally, but I'll see
>> >what
>> >I can do to bring this issue to the attention of the the folks who own
>> >the
>> >Dispatcher code.
>> >
>> > -Adam Smith [MS]
>> >
>> >
>> > "Josh Smith" <JoshSmith@discussions.microsoft.com> wrote in message
>> > news:59CA77E4-11A3-422B-8C52-30169AD4EE09@microsoft.com...
>> >>I had to test out some third party WinForms controls in a WPF context
>> >>for
>> >> work. I installed a 30-day trial of DevComponent's DotNetBar and used
>> >> severak WindowsFormsHost element to host some controls. Since the
>> >> controls
>> >> are being used on trial, they always pop up a dialog stating that
>> >> "these
>> >> controls are a trial version, do you want to buy them, etc." This is
>> >> the
>> >> standard for 3rd party controls being used on a trial basis.
>> >>
>> >> The problem is that the WPF immediately throws an
>> >> InvalidOperationException
>> >> when the app loads. Here's the call stack:
>> >>
>> >> System.InvalidOperationException: Dispatcher processing has been
>> >> suspended,
>> >> but messages are still being processed.
>> >> at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd,
>> >> Int32
>> >> msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
>> >> at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr
>> >> wParam,
>> >> IntPtr lParam, Boolean& handled)
>> >> at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
>> >> at
>> >> System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate
>> >> callback, Object args, Boolean isSingleParameter)
>> >> at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object
>> >> source,
>> >> Delegate callback, Object args, Boolean isSingleParameter, Delegate
>> >> catchHandler)
>> >> at System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority
>> >> priority, TimeSpan timeout, Delegate method, Object args, Boolean
>> >> isSingleParameter)
>> >> at System.Windows.Threading.Dispatcher.Invoke(DispatcherPriority
>> >> priority, Delegate method, Object arg)
>> >> at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg,
>> >> IntPtr
>> >> wParam, IntPtr lParam)
>> >> at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG&
>> >> msg)
>> >> at
>> >> System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32
>> >> dwComponentID, Int32 reason, Int32 pvLoopData)
>> >> at
>> >> System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32
>> >> reason, ApplicationContext context)
>> >> at
>> >> System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32
>> >> reason, ApplicationContext context)
>> >> at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
>> >> at System.Windows.Forms.Form.ShowDialog()
>> >> at DevComponents.DotNetBar.RibbonControl.OnHandleCreated(EventArgs
>> >> e)
>> >> at System.Windows.Forms.Control.WmCreate(Message& m)
>> >> at System.Windows.Forms.Control.WndProc(Message& m)
>> >> at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
>> >> at System.Windows.Forms.ContainerControl.WndProc(Message& m)
>> >> at
>> >> System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message&
>> >> m)
>> >> at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message&
>> >> m)
>> >> at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32
>> >> msg,
>> >> IntPtr wparam, IntPtr lparam)
>> >>
>> >> ***
>> >> After I dismiss that exception window via the 'Continue' button, the
>> >> app
>> >> is
>> >> frozen. All WPF elements in the app do not respond to user gestures
>> >> or
>> >> repaint. The app is basically dead, except for the WinForms control.
>> >>
>> >> Here's the XAML for the UI:
>> >>
>> >> <Window x:Class="PocWithRibbonBar.Window1"
>> >> xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
>> >> xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>> >>
>> >> xmlns:dnb="clr-namespaceevComponents.DotNetBar;assembly=DevComponents.DotNetBar2"
>> >>
>> >> xmlns:wfi="clr-namespace:System.Windows.Forms.Integration;assembly=WindowsFormsIntegration"
>> >> Title="PocWithRibbonBar" Height="300" Width="300"
>> >> >
>> >> <Grid>
>> >> <Grid.RowDefinitions>
>> >> <RowDefinition Height="Auto" />
>> >> <RowDefinition Height="*" />
>> >> </Grid.RowDefinitions>
>> >>
>> >> <wfi:WindowsFormsHost>
>> >> <dnb:RibbonControl x:Name="ribbonControl" />
>> >> </wfi:WindowsFormsHost>
>> >>
>> >> <ListBox Grid.Row="1">
>> >> <ListBoxItem>A</ListBoxItem>
>> >> <ListBoxItem>B</ListBoxItem>
>> >> <ListBoxItem>C</ListBoxItem>
>> >> </ListBox>
>> >> </Grid>
>> >> </Window>
>> >>
>> >> ***
>> >> I assume that the bug has to do with the fact that the 3rd party
>> >> controls
>> >> are trying to show their licensing message box. I have no idea how to
>> >> work
>> >> around this, but if WPF is going to support WinForms interop, then I
>> >> think
>> >> that this is a pretty important issue to iron out.
>> >>
>> >> Thanks,
>> >> Josh Smith
>> >
>> >
>>
>>
>>

Nick,

If you get a chance, please elaborate on that. I'm not sure what you mean
by "before the layout pass" nor why a control's handle must be created before
it. I'm curious what you mean.

Thanks for any insights.

"Nick Kramer [MSFT]" wrote:

> Glad you found a solution! thinking about it a little more, WinForms has
> this nifty Handle property, which creates the hwnd. Anything that directly
> or indirectly calls Handle before the layout pass should solve the
> problem -- adding the element to a live tree being one example of this,
> simply calling the Handle property yourself at a strategic place could be
> another approach.
>
>
> --
> -Nick Kramer [MSFT]
> http://blogs.msdn.com/nickkramer
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
> Use of included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm
>
> "Josh Smith" <JoshSmith@discussions.microsoft.com> wrote in message
> news:7D2096DB-BCDC-43B6-8E34-C1F5F9224FD6@microsoft.com...
> > Thanks for the info about this issue, Nick. I worked around for the
> > problem
> > by simply adding the 3rd party WinForms control to the WindowsFormsHost in
> > a
> > Window.Loaded event handling method.
> >
> > Thanks,
> > Josh Smith
> >
> > "Nick Kramer [MSFT]" wrote:
> >
> >> The underlying issue is described on
> >> http://blogs.msdn.com/nickkramer/arc...06/591252.aspx ,
> >> although
> >> given that you control neither the HwndHost (which WindowsFormsPost uses)
> >> or
> >> the WinForms control popping up the dialog, I can't think of a solution.
> >>
> >> --
> >> -Nick Kramer [MSFT]
> >> http://blogs.msdn.com/nickkramer
> >>
> >> This posting is provided "AS IS" with no warranties, and confers no
> >> rights.
> >> Use of included script samples are subject to the terms specified at
> >> http://www.microsoft.com/info/cpyright.htm
> >>
> >> "Adam Smith [MS]" <Adam.Smith@microsoft.com> wrote in message
> >> news:%23fsyjXSoGHA.3532@TK2MSFTNGP04.phx.gbl...
> >> >I believe that this exception indicates re-entrancy. Typically, this
> >> >occurs when code which is nested within the WPF dispatcher's message
> >> >loop
> >> >causes the message loop to iterate. This in turn is often caused when
> >> >code
> >> >calls "lock" (the CLR lock), since this lock can cause the message loop
> >> >to
> >> >pump. I'm sorry that I don't have a solution personally, but I'll see
> >> >what
> >> >I can do to bring this issue to the attention of the the folks who own
> >> >the
> >> >Dispatcher code.
> >> >
> >> > -Adam Smith [MS]
> >> >
> >> >
> >> > "Josh Smith" <JoshSmith@discussions.microsoft.com> wrote in message
> >> > news:59CA77E4-11A3-422B-8C52-30169AD4EE09@microsoft.com...
> >> >>I had to test out some third party WinForms controls in a WPF context
> >> >>for
> >> >> work. I installed a 30-day trial of DevComponent's DotNetBar and used
> >> >> severak WindowsFormsHost element to host some controls. Since the
> >> >> controls
> >> >> are being used on trial, they always pop up a dialog stating that
> >> >> "these
> >> >> controls are a trial version, do you want to buy them, etc." This is
> >> >> the
> >> >> standard for 3rd party controls being used on a trial basis.
> >> >>
> >> >> The problem is that the WPF immediately throws an
> >> >> InvalidOperationException
> >> >> when the app loads. Here's the call stack:
> >> >>
> >> >> System.InvalidOperationException: Dispatcher processing has been
> >> >> suspended,
> >> >> but messages are still being processed.
> >> >> at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd,
> >> >> Int32
> >> >> msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
> >> >> at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr
> >> >> wParam,
> >> >> IntPtr lParam, Boolean& handled)
> >> >> at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
> >> >> at
> >> >> System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate
> >> >> callback, Object args, Boolean isSingleParameter)
> >> >> at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object
> >> >> source,
> >> >> Delegate callback, Object args, Boolean isSingleParameter, Delegate
> >> >> catchHandler)
> >> >> at System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority
> >> >> priority, TimeSpan timeout, Delegate method, Object args, Boolean
> >> >> isSingleParameter)
> >> >> at System.Windows.Threading.Dispatcher.Invoke(DispatcherPriority
> >> >> priority, Delegate method, Object arg)
> >> >> at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg,
> >> >> IntPtr
> >> >> wParam, IntPtr lParam)
> >> >> at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG&
> >> >> msg)
> >> >> at
> >> >> System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32
> >> >> dwComponentID, Int32 reason, Int32 pvLoopData)
> >> >> at
> >> >> System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32
> >> >> reason, ApplicationContext context)
> >> >> at
> >> >> System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32
> >> >> reason, ApplicationContext context)
> >> >> at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
> >> >> at System.Windows.Forms.Form.ShowDialog()
> >> >> at DevComponents.DotNetBar.RibbonControl.OnHandleCreated(EventArgs
> >> >> e)
> >> >> at System.Windows.Forms.Control.WmCreate(Message& m)
> >> >> at System.Windows.Forms.Control.WndProc(Message& m)
> >> >> at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
> >> >> at System.Windows.Forms.ContainerControl.WndProc(Message& m)
> >> >> at
> >> >> System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message&
> >> >> m)
> >> >> at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message&
> >> >> m)
> >> >> at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32
> >> >> msg,
> >> >> IntPtr wparam, IntPtr lparam)
> >> >>
> >> >> ***
> >> >> After I dismiss that exception window via the 'Continue' button, the
> >> >> app
> >> >> is
> >> >> frozen. All WPF elements in the app do not respond to user gestures
> >> >> or
> >> >> repaint. The app is basically dead, except for the WinForms control.
> >> >>
> >> >> Here's the XAML for the UI:
> >> >>
> >> >> <Window x:Class="PocWithRibbonBar.Window1"
> >> >> xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
> >> >> xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
> >> >>
> >> >> xmlns:dnb="clr-namespaceevComponents.DotNetBar;assembly=DevComponents.DotNetBar2"
> >> >>
> >> >> xmlns:wfi="clr-namespace:System.Windows.Forms.Integration;assembly=WindowsFormsIntegration"
> >> >> Title="PocWithRibbonBar" Height="300" Width="300"
> >> >> >
> >> >> <Grid>
> >> >> <Grid.RowDefinitions>
> >> >> <RowDefinition Height="Auto" />
> >> >> <RowDefinition Height="*" />
> >> >> </Grid.RowDefinitions>
> >> >>
> >> >> <wfi:WindowsFormsHost>
> >> >> <dnb:RibbonControl x:Name="ribbonControl" />
> >> >> </wfi:WindowsFormsHost>
> >> >>
> >> >> <ListBox Grid.Row="1">
> >> >> <ListBoxItem>A</ListBoxItem>
> >> >> <ListBoxItem>B</ListBoxItem>
> >> >> <ListBoxItem>C</ListBoxItem>
> >> >> </ListBox>
> >> >> </Grid>
> >> >> </Window>
> >> >>
> >> >> ***
> >> >> I assume that the bug has to do with the fact that the 3rd party
> >> >> controls
> >> >> are trying to show their licensing message box. I have no idea how to
> >> >> work
> >> >> around this, but if WPF is going to support WinForms interop, then I
> >> >> think
> >> >> that this is a pretty important issue to iron out.
> >> >>
> >> >> Thanks,
> >> >> Josh Smith
> >> >
> >> >
> >>
> >>
> >>
>
>
>

http://blogs.msdn.com/nickkramer/arc...06/591252.aspx talks about
this some. The layout pass is a queue item that gets processed sometime
after you do stuff that changes layout.

--
-Nick Kramer [MSFT]
http://blogs.msdn.com/nickkramer

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Josh Smith" <JoshSmith@discussions.microsoft.com> wrote in message
news:0D21294D-9B66-4B9D-9D5D-CBED30938A1F@microsoft.com...
> Nick,
>
> If you get a chance, please elaborate on that. I'm not sure what you mean
> by "before the layout pass" nor why a control's handle must be created
> before
> it. I'm curious what you mean.
>
> Thanks for any insights.
>
> "Nick Kramer [MSFT]" wrote:
>
>> Glad you found a solution! thinking about it a little more, WinForms has
>> this nifty Handle property, which creates the hwnd. Anything that
>> directly
>> or indirectly calls Handle before the layout pass should solve the
>> problem -- adding the element to a live tree being one example of this,
>> simply calling the Handle property yourself at a strategic place could be
>> another approach.
>>
>>
>> --
>> -Nick Kramer [MSFT]
>> http://blogs.msdn.com/nickkramer
>>
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> Use of included script samples are subject to the terms specified at
>> http://www.microsoft.com/info/cpyright.htm
>>
>> "Josh Smith" <JoshSmith@discussions.microsoft.com> wrote in message
>> news:7D2096DB-BCDC-43B6-8E34-C1F5F9224FD6@microsoft.com...
>> > Thanks for the info about this issue, Nick. I worked around for the
>> > problem
>> > by simply adding the 3rd party WinForms control to the WindowsFormsHost
>> > in
>> > a
>> > Window.Loaded event handling method.
>> >
>> > Thanks,
>> > Josh Smith
>> >
>> > "Nick Kramer [MSFT]" wrote:
>> >
>> >> The underlying issue is described on
>> >> http://blogs.msdn.com/nickkramer/arc...06/591252.aspx ,
>> >> although
>> >> given that you control neither the HwndHost (which WindowsFormsPost
>> >> uses)
>> >> or
>> >> the WinForms control popping up the dialog, I can't think of a
>> >> solution.
>> >>
>> >> --
>> >> -Nick Kramer [MSFT]
>> >> http://blogs.msdn.com/nickkramer
>> >>
>> >> This posting is provided "AS IS" with no warranties, and confers no
>> >> rights.
>> >> Use of included script samples are subject to the terms specified at
>> >> http://www.microsoft.com/info/cpyright.htm
>> >>
>> >> "Adam Smith [MS]" <Adam.Smith@microsoft.com> wrote in message
>> >> news:%23fsyjXSoGHA.3532@TK2MSFTNGP04.phx.gbl...
>> >> >I believe that this exception indicates re-entrancy. Typically, this
>> >> >occurs when code which is nested within the WPF dispatcher's message
>> >> >loop
>> >> >causes the message loop to iterate. This in turn is often caused
>> >> >when
>> >> >code
>> >> >calls "lock" (the CLR lock), since this lock can cause the message
>> >> >loop
>> >> >to
>> >> >pump. I'm sorry that I don't have a solution personally, but I'll see
>> >> >what
>> >> >I can do to bring this issue to the attention of the the folks who
>> >> >own
>> >> >the
>> >> >Dispatcher code.
>> >> >
>> >> > -Adam Smith [MS]
>> >> >
>> >> >
>> >> > "Josh Smith" <JoshSmith@discussions.microsoft.com> wrote in message
>> >> > news:59CA77E4-11A3-422B-8C52-30169AD4EE09@microsoft.com...
>> >> >>I had to test out some third party WinForms controls in a WPF
>> >> >>context
>> >> >>for
>> >> >> work. I installed a 30-day trial of DevComponent's DotNetBar and
>> >> >> used
>> >> >> severak WindowsFormsHost element to host some controls. Since the
>> >> >> controls
>> >> >> are being used on trial, they always pop up a dialog stating that
>> >> >> "these
>> >> >> controls are a trial version, do you want to buy them, etc." This
>> >> >> is
>> >> >> the
>> >> >> standard for 3rd party controls being used on a trial basis.
>> >> >>
>> >> >> The problem is that the WPF immediately throws an
>> >> >> InvalidOperationException
>> >> >> when the app loads. Here's the call stack:
>> >> >>
>> >> >> System.InvalidOperationException: Dispatcher processing has been
>> >> >> suspended,
>> >> >> but messages are still being processed.
>> >> >> at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd,
>> >> >> Int32
>> >> >> msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
>> >> >> at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr
>> >> >> wParam,
>> >> >> IntPtr lParam, Boolean& handled)
>> >> >> at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
>> >> >> at
>> >> >> System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate
>> >> >> callback, Object args, Boolean isSingleParameter)
>> >> >> at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object
>> >> >> source,
>> >> >> Delegate callback, Object args, Boolean isSingleParameter, Delegate
>> >> >> catchHandler)
>> >> >> at
>> >> >> System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority
>> >> >> priority, TimeSpan timeout, Delegate method, Object args, Boolean
>> >> >> isSingleParameter)
>> >> >> at System.Windows.Threading.Dispatcher.Invoke(DispatcherPriority
>> >> >> priority, Delegate method, Object arg)
>> >> >> at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg,
>> >> >> IntPtr
>> >> >> wParam, IntPtr lParam)
>> >> >> at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG&
>> >> >> msg)
>> >> >> at
>> >> >> System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32
>> >> >> dwComponentID, Int32 reason, Int32 pvLoopData)
>> >> >> at
>> >> >> System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32
>> >> >> reason, ApplicationContext context)
>> >> >> at
>> >> >> System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32
>> >> >> reason, ApplicationContext context)
>> >> >> at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
>> >> >> at System.Windows.Forms.Form.ShowDialog()
>> >> >> at
>> >> >> DevComponents.DotNetBar.RibbonControl.OnHandleCreated(EventArgs
>> >> >> e)
>> >> >> at System.Windows.Forms.Control.WmCreate(Message& m)
>> >> >> at System.Windows.Forms.Control.WndProc(Message& m)
>> >> >> at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
>> >> >> at System.Windows.Forms.ContainerControl.WndProc(Message& m)
>> >> >> at
>> >> >> System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message&
>> >> >> m)
>> >> >> at
>> >> >> System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message&
>> >> >> m)
>> >> >> at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32
>> >> >> msg,
>> >> >> IntPtr wparam, IntPtr lparam)
>> >> >>
>> >> >> ***
>> >> >> After I dismiss that exception window via the 'Continue' button,
>> >> >> the
>> >> >> app
>> >> >> is
>> >> >> frozen. All WPF elements in the app do not respond to user
>> >> >> gestures
>> >> >> or
>> >> >> repaint. The app is basically dead, except for the WinForms
>> >> >> control.
>> >> >>
>> >> >> Here's the XAML for the UI:
>> >> >>
>> >> >> <Window x:Class="PocWithRibbonBar.Window1"
>> >> >>
>> >> >> xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
>> >> >> xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>> >> >>
>> >> >> xmlns:dnb="clr-namespaceevComponents.DotNetBar;assembly=DevComponents.DotNetBar2"
>> >> >>
>> >> >> xmlns:wfi="clr-namespace:System.Windows.Forms.Integration;assembly=WindowsFormsIntegration"
>> >> >> Title="PocWithRibbonBar" Height="300" Width="300"
>> >> >> >
>> >> >> <Grid>
>> >> >> <Grid.RowDefinitions>
>> >> >> <RowDefinition Height="Auto" />
>> >> >> <RowDefinition Height="*" />
>> >> >> </Grid.RowDefinitions>
>> >> >>
>> >> >> <wfi:WindowsFormsHost>
>> >> >> <dnb:RibbonControl x:Name="ribbonControl" />
>> >> >> </wfi:WindowsFormsHost>
>> >> >>
>> >> >> <ListBox Grid.Row="1">
>> >> >> <ListBoxItem>A</ListBoxItem>
>> >> >> <ListBoxItem>B</ListBoxItem>
>> >> >> <ListBoxItem>C</ListBoxItem>
>> >> >> </ListBox>
>> >> >> </Grid>
>> >> >> </Window>
>> >> >>
>> >> >> ***
>> >> >> I assume that the bug has to do with the fact that the 3rd party
>> >> >> controls
>> >> >> are trying to show their licensing message box. I have no idea how
>> >> >> to
>> >> >> work
>> >> >> around this, but if WPF is going to support WinForms interop, then
>> >> >> I
>> >> >> think
>> >> >> that this is a pretty important issue to iron out.
>> >> >>
>> >> >> Thanks,
>> >> >> Josh Smith
>> >> >
>> >> >
>> >>
>> >>
>> >>
>>
>>
>>