Open Kinaou opened 9 years ago
Is it relevant that wxAuiFloatingFrame
behaves like a top level window?
Let me explain: in the event loop, events are sent from child to parent recursively, until a top level window is encountered (in fact, until a parent window of which IsTopLevel()
returns true
).
wxAuiFloatingFrame
being a wx[Mini]Frame
, it is de facto a top level window. But I'm not sure it is relevant in our case, in so far as the pane can be respectively floating or docked and have currently a different behavior, regarding to events processing, according to its state.
Thereby, a docked pane will process events up to the main frame, while a floating pane will confine the events to wxAuiFloatingFrame
.
What I propose is to overload IsTopLevel()
in wxAuiFloatingFrame
to return false
, in the aim of aligning behaviors between docked and floating panes.
I have read this, there will have to be tests because I don't know the internals of the event loop or what this may mess up.
You are right, I tested that yesterday and there are border effects in the frame's positioning and potentially a lot of other things. I'm trying to find a way to shortcut the event loop properly but this does not seem quite trivial. It requires some exploration.
See the thread on https://groups.google.com/forum/?fromgroups=#!topic/wx-dev/nxCD5Nn_Zqw
http://trac.wxwidgets.org/ticket/16870
Given the above trac bug, I don't think this is something we can safely settle in the fork... It also isn't dynamic notebook specific though obviously its more of an issue for dynamic notebooks.
Given the above I think this should be a 'postmerge' issue.
In the auidemo add an accelerator in some menu item, eg. in auidemo.cpp l.660:
view_menu->Append(ID_CreateText, _("Create &Text Control\tCTRL+T"));