[osg-users] osgViewer::GraphicsWindowWin32 stack overflow crash

Peter Amstutz peter.amstutz at tseboston.com
Wed Mar 4 13:54:27 PST 2009


Yes, embedding osgViewer into a .NET control is exactly what I am doing, 
and I have been using it this way successfully for a long time.  I just 
remembered another wrinkle --  for some reason, the code works fine when 
run with an NVIDIA GeForce chip, and it only crashes with the infinite 
recursion problem when running on a different computer with an ATI 
Radeon chip.  Very peculiar (but not the only peculiar thing about osg 
and ATI, but that's the subject for another post.)

It is a little bit tricky because the user control hierarchy in Windows 
Forms are all supposed to be owned/accessed by a single thread (and will 
raise exceptions on cross-thread access) but I want to render in a 
separate thread from the main application thread.  This is a large part 
of the reason why having osg processing its own window messages is so 
problematic for me, because those events *must* be processed by the main 
application thread in order for event propagation, focus management, 
hotkeys and so forth to work properly.

At any rate, I'm probably going to go with Stephan Huber's suggestion 
and add a flag to GraphicsWindowWin32::WindowData.  Seeing that such a 
flag already exists for the OS X Carbon implementation, it is an easy 
case to make that the Windows implementation should have a similar option.

Peter

Jason Beverage wrote:
> Hi Peter,
>
> We've also used the GraphicsWindowWin32 successfully by creating a 
> custom User Control in .NET.
>
> We're using the code from this FAQ entry with no problems:
> http://www.openscenegraph.org/projects/osg/wiki/Support/FAQ#HowdoIembedanOSGviewerina.NETcontrol
>
> Thanks!
>
> Jason
>
> On Wed, Mar 4, 2009 at 3:14 PM, Peter Amstutz 
> <peter.amstutz at tseboston.com <mailto:peter.amstutz at tseboston.com>> wrote:
>
>     That sounds like the right thing to do.  I'll give that a try.
>
>     Stephan Huber wrote:
>
>         Hi Peter,
>
>
>         Another idea would be to extend
>         GraphicsWindowWin32::WindowData to add a
>         flag or something similar, so GraphicsWindowWin32 can query
>         this flag an
>         decide if it's allowed to call registerWindowProcedure.
>
>         This is what we have done for the OS X carbon implementation,
>         and it
>         doesn't pollute the cross-plattform traits-structure.
>
>
>         just my 2 cents,
>         Stephan
>         _______________________________________________
>         osg-users mailing list
>         osg-users at lists.openscenegraph.org
>         <mailto:osg-users at lists.openscenegraph.org>
>         http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>          
>
>
>     _______________________________________________
>     osg-users mailing list
>     osg-users at lists.openscenegraph.org
>     <mailto:osg-users at lists.openscenegraph.org>
>     http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>   




More information about the osg-users mailing list