Greetings!
We noticed in the source code that the head of the repository has added a setParentWindow method to the WindowProperties class. It appears to be designed to take an HWND (like what is returned via wxPython’s getHandle() call) and set the parent-child relationship. I was curious what the status of this extension is? How close is this to being functional, and how would one use it?
Thank you for the help!
-Mark
It is functional. It is exactly as you surmise: it receives a HWND, such as returned by getHandle(). Simply assign this to the WindowProperties before you create the window (and pass that WindowProperties into the base.openWindow() call), and your new window should be created as a child of the specified window.
David
Excellent! That’s exactly what we can use.
I’m looking at the implementation, and I’m not yet sure how (under Windows specifically) the parent/child relationship will be handled. It was mentioned in this thread that we should be handling our own focus if we are going to make use of this feature; however, the Panda API currently doesn’t give me access to a GraphicsWindow’s focus to my knowledge.
I’m thinking it would be helpful to extend the API in two ways. First, giving GraphicsWindows a getHandle method to return an underlying handle object (for passage to wxPython, reparenting, etc). Second, adding some kind of mechanism to manage keyboard focus for child windows. I believe the first should be relatively simple to do (in the WinGraphicsWindow implementation, for example, I can see the _hWnd; I assume something similar could happen on other OSes).
Setting focus (keyboard focus, specifically) is probably a little more complicated, and I welcome any input on both design and implementation of this feature. We did an exploratory pass in Windows by simply adding a wrapper for the Windows API “SetFocus” method. The method is implemented in GraphicsWindow (and overridden in WinGraphicsWindow) and simply calls SetFocus immediately. This seems to be a step in the right direction, but it has the undesirable side-effect of causing a massive explosion of key-up events on the first keypress after focus is received.
Also, I notice that very few other things I could do to a GraphicsWindow are implemented this way (i.e. a direct call on the GraphicsWindow object itself); most modifications seem to go through the WindowProperties class. Is there a specific reason to consolidate window property changes in the mechanism of creating a class to pass to the GraphicsWindow (i.e. am I likely to trip over something foul because I’m making this immediate call instead of getting focus as a requested property change)?
Thank you for all the help on this issue!
-Mark
We require the indirection of WindowProperties to support threading, particularly on platforms (e.g. Linux) where all of the calls into the windowing system must be performed by the same thread.
As for keyboard focus, this is intended to be handled by WindowProperties also, but there is currently a bit of confusion in that structure since we mash the concepts of “keyboard focus” and “foreground” into the same bit. Our plan is eventually to straighten this confusion out when we get the chance. In the meantime, you can try setting focus by setting the foreground flag:
wp = WindowProperties()
wp.setForeground(1)
base.win.requestProperties(wp)I’m not sure whether that will achieve the effect you want, since I’m not 100% sure what effect you want. 
As to the explosion of key-up messages, that’s caused by the underlying Panda code being paranoid about tracking key-up’s and key-down’s. Again, some of our window code is a bit clumsy, and hasn’t been doing a good job of tracking all key events properly. Since it’s possible to lose key “up” events when the window doesn’t have focus, we conservatively send every key “up” when the window returns to focus, to ensure that the application remains in sync with the actual keyboard state. Normally this explosion of events doesn’t cause any problem, since unhandled events just fall on the floor. Is it actually causing you problems?
David
Thank you for the clarification David; that’s extremely helpful.
We have Panda’s main window embedded within a wxPython frame in our application. When we were using Panda 1.2.3, we did this with a bit of trickery in a DLL that we imported; now that Panda supports parent windows, we can use that system. But our old mechanism handled keyboard focus; the new code in Panda to support parent windows seems to interfere with our old keyboard focus control solution, a phenomenon that we are currently investigating.
Mostly, it’s the way we programmed things. Since Panda 1.2.3 didn’t send paranoid key-up events, we coded under the assumption that every key-up would be preceded by a key-down (i.e. our keyboard handlers aren’t necessarily all wrapped in binary-state switches; some handle all instances of key-up under the assumption that the corresponding key-down handler has already fired). This worked in 1.2.3 (though we suffered from the problem of sticky keys that I believe the paranoid send fixes; we’d been working on addressing that issue). So basically, it’s just on us to address this design change and fix our code 
Thank you for the help!
-Mark