Frame not able to regain focus

wxPython Users
1

I’m using a moving frame to represent information on the screen (in the simple example attached it’s just a moving red box). I’ve set up a simple app to test it and take input, and to ensure I keep control I’ve set it to catch wxEVT_KILL_FOCUS events and return the focus to the moving frame. This works perfectly the first time it happens, but on all subsequent times when focus is lost, although it is detected fine, the frame does not get back input and inputs do not work.
I’ve attached a simplified example below. Space bar starts and stops the frame and escape closes it, but as I say, after clicking away from the frame twice I have to click back on it in order for these commands to work. Is there some problem with giving focus multiple times?

example_problem.py (1.86 KB)

2

Adam Barnett wrote:

I'm using a moving frame to represent information on the screen (in
the simple example attached it's just a moving red box). I've set up
a simple app to test it and take input, and to ensure I keep control
I've set it to catch wxEVT_KILL_FOCUS events and return the focus to
the moving frame. This works perfectly the first time it happens, but
on all subsequent times when focus is lost, although it is detected
fine, the frame does not get back input and inputs do not work.
I've attached a simplified example below. Space bar starts and stops
the frame and escape closes it, but as I say, after clicking away from
the frame twice I have to click back on it in order for these commands
to work. Is there some problem with giving focus multiple times?

One of the issues here is that there are two windows involved: the
frame, and the panel within the frame. Application focus is actually
slightly different than keyboard focus. You get EVT_FILL_FOCUS events
for both of them, but you don't differentiate between them. Change your
print statement to this, and you'll see that in action:

    print 'focus shift detected', event.GetEventObject()

I'm spewing a lot of words here, but I'm still having a bit of
difficulty coming up with a coherent explanation for the actual results
you get. Overall, it's very difficult for an application to steal the
keyboard focus and retain it indefinitely, for obvious reasons of
usability. You might consider whether you would be better served by
EVT_CHAR_HOOK.

···

--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

3

Thanks a lot Tim, that actually cleared up many confusions I had which I’d not mentioned. Sadly I’ve still not figured out why this is happening, but as you say having one application steal the focus indefinitely isn’t a great idea anyway.
This was primarily a problem because I am using two very thin frames as a reticle of sorts to select a point on the screen (as a result if they lose focus, they are very hard to click on to give the focus back). As a result I will be solving this most likely by adding a third frame off to the side which is larger to allow a user to manually return the focus.

4

Adam Barnett wrote:

Thanks a lot Tim, that actually cleared up many confusions I had which
I'd not mentioned. Sadly I've still not figured out why this is
happening, but as you say having one application steal the focus
indefinitely isn't a great idea anyway.

It's not just the focus involved here, but also the concept of foreground application and/or active window. And unfortunately these days the native UIs tend to not like applications that raise their windows over the windows of other applications and stealing the focus, unless it was some direct user event that caused it.

It's kinda hacky but you can give the system the user interaction it wants, and get the results you're looking for with the action simulator. You just have to deal with the mouse cursor jumping around possibly causing some confusion.

             def _takeItBack(frame):
                 frame.Raise()
                 pos = frame.GetPosition() + (10,10)
                 sim = wx.UIActionSimulator()
                 sim.MouseMove(pos)
                 sim.MouseClick()

···

--
Robin Dunn
Software Craftsman

5

Thanks a lot Robin, I can see how that would work (though as you say, I imagine it might get a bit annoying, even if I return the mouse to where it was).

···

On Wed, Jan 21, 2015 at 9:20 PM, Robin Dunn robin@alldunn.com wrote:

Thanks a lot Tim, that actually cleared up many confusions I had which

I’d not mentioned. Sadly I’ve still not figured out why this is

happening, but as you say having one application steal the focus

indefinitely isn’t a great idea anyway.
Adam Barnett wrote:

It’s not just the focus involved here, but also the concept of foreground application and/or active window. And unfortunately these days the native UIs tend to not like applications that raise their windows over the windows of other applications and stealing the focus, unless it was some direct user event that caused it.

It’s kinda hacky but you can give the system the user interaction it wants, and get the results you’re looking for with the action simulator. You just have to deal with the mouse cursor jumping around possibly causing some confusion.

        def _takeItBack(frame):

            frame.Raise()

            pos = frame.GetPosition() + (10,10)

            sim = wx.UIActionSimulator()

            sim.MouseMove(pos)

            sim.MouseClick()

–

Robin Dunn

Software Craftsman

http://wxPython.org

–

You received this message because you are subscribed to a topic in the Google Groups “wxPython-users” group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/wxpython-users/RcvUvYvViuc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to wxpython-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

6

Why not just use the Frame style STAY_ON_TOP

?

···

On Tuesday, December 23, 2014 at 9:43:34 AM UTC-8, Adam Barnett wrote:

I’m using a moving frame to represent information on the screen (in the simple example attached it’s just a moving red box). I’ve set up a simple app to test it and take input, and to ensure I keep control I’ve set it to catch wxEVT_KILL_FOCUS

7

Thanks for the suggestion Nathan, I think that I am using that style. The problem I ran into was that the frames I was using are quite small and moving. As far as I recall this meant if I lost focus then I couldn’t input keyboard commands without chasing the frame around to click on it manually (which made testing and terminating the frame an issue).

···

On Thu, Jan 22, 2015 at 2:38 PM, Nathan McCorkle nmz787@gmail.com wrote:

On Tuesday, December 23, 2014 at 9:43:34 AM UTC-8, Adam Barnett wrote:

I’m using a moving frame to represent information on the screen (in the simple example attached it’s just a moving red box). I’ve set up a simple app to test it and take input, and to ensure I keep control I’ve set it to catch wxEVT_KILL_FOCUS

Why not just use the Frame style STAY_ON_TOP

?

–

You received this message because you are subscribed to a topic in the Google Groups “wxPython-users” group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/wxpython-users/RcvUvYvViuc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to wxpython-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.