Himar Carmona wrote:
I have done this manner and it functions like a charm. You don't have to
provide your own handling of the events. Why? Because GraphicsWindowWin32
register his own WindowProcedure if you provides it a Handle. (see
registerWindowProcedure).
Ah! I didn't notice that it was taking over the window procedure, so I
avoided this route. That said, it would seem appropriate for OSG to
have a notion of parent/child windows. Clearly things like keyboard
focus aren't handled properly for child windows, since OSG attempts to
call SetForegroundWindow which is not valid for child windows. As well,
it's easier for the user to point OSG at a child window handle than to
create a window yourself, especially if you will need to deal with
multiple windowing systems.
I think this is what Win32 knows as Subclassing.
In this case, GraphicsWindowWin32 sublclasses your window (the one
created
in step 2) and take control of the window procedure. If you want to
process
any messages, do it in your WindowProc, because GWWin32 call it after
processing the messages.
I see. Unfortunately would have to subclass again if you wanted to
handle messages before the GWWin32 WindowProc gets at them.
Of course, embedding the viewer inside a parent window force you to
handle the focus (you can lose it and have the viewer not responding
to keys
or mouse wheel).
I've been forwarding keyboard messages and calling SetFocus on the
viewer class whenever the parent window gains focus. I'm not sure if
this is the most appropriate way to deal with this but it appears to work.
- Eron
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
