Implementing Photoshop-like focus policy

[Bill Baxter]

Thanks!  That does the trick.

I wonder why top level frames don't get the same sort of "last chance"
access to key events that happen inside of them?  Seems like that's
generally what you'd want rather than handling them at the App level.
Anyway, I seem to be able to get that kind of behavior with this as my
key up/down handler in the App (wxPython):

    def onAppRedirectEvent(self, event):
        # redirect event back down to frame's handler
        if self.freeze_redirect:
            # prevents infinite recursion
            return
        frame = event.GetEventObject().GetTopLevelParent()
        self.freeze_redirect = True
        frame.GetEventHandler().ProcessEvent(event)
        self.freeze_redirect = False

Please let me know if anything seems obviously wrong about this approach.

--bb

On 6/30/07, Vadim Zeitlin <vadim at wxwidgets.org> wrote:
> On Sat, 30 Jun 2007 10:07:28 +0900 Bill Baxter <wbaxter at gmail.com> wrote:
>
> BB> wx.EVT_CHAR_HOOK seems like it might be able to help, but on Windows
> BB> it doesn't trap plain alpha-numeric keys, just special ones.
>
>  This is clearly done on purpose (there is a test in wxKeyboardHook
> function which filters out all alphanumeric keys) but I have no idea why.
> But then the design of wxEVT_CHAR_HOOK has always been a bit of a mystery
> to me.
>
> BB> So what's a reasonable way to make all key events find their way to
> BB> the main app handler?
>
>  Process them at wxApp level -- all unprocessed events finish up there.
> wxEVT_CHAR_HOOK is not the right way to do what you want anyhow as it's a
> hook, i.e. it has priority compared to the focused window and so it would
> steal the keys from your text widget. But wxApp only gets the events which
> hadn't been processed by someone else before so it's the right place to do
> all global post-processing (and, for completeness, to pre-process
> absolutely all events you can use wxApp::FilterEvent()).
>
>  Regards,
> VZ
>