If you want to take the messages before GWWin32 does, you need certainly to
subclass again. But i think its chipier than redefining GWWin32. You can't
derive it and override the window creation. (Thats why i redefine one
completely).
W.r.t to focus, what i do is manage the WM_MOUSEACTIVATE message in the
windowproc for the child window.
/////////////////
case WM_MOUSEACTIVATE:
/////////////////
::SetFocus(hwnd);
break;
If you redirect keyboard messages, then its alright, but take into account
that it depends on the other parent controls. I also manage the Tabbing.
You are right with your comment about inheritedWindowData and
parentWindowData, but 'normally used to' depends on what the receiver does
with it.
I wanted to touch OSG minimal, so my own implementation of GWWin32 is now
deprecated, because i found a 'right way' for me. (Now i didn't have to use
it).
I think this is important, because then i can be updated to the last
version.
Thanks for your appreciations.
2007/7/17, Eron Steger <[EMAIL PROTECTED]>:
> 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/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
