I'm using an AUI framework much like the wxPython demo provides. And figuring out how to manage focus is something I haven't figured out.
Two situations are dogging me: From a menu, I call show() on a pane which exposes a dialog to set some parameters. On the Win32 platform, when I close it, focus does not return to the other docked AUI panes behind it, but rather to my Eclipse PyDev environment, and I have to manually mouse click the AUI stuff to get focus on it again.
Second situation - I took a pane that was previously docked and made it a floating pane instead. It comes up in front of the other docked AUI panes, but to interact with it, e.g. to click a wxButton on the pane, I have to click once to get the focus and click again to hit the button. If I had focus on it to start, a single click would be more user friendly and expected.
Googling thru documentation I find very little reference to "Focus" - Does wxPython use some other term instead of 'focus'? Any pointer someone can offer to where it is discussed?
In terms of coding, is there some method equiv. of:
self._mgr.GetPane("myPane").HasFocus(True) # not real code!
I'm using an AUI framework much like the wxPython demo provides. And figuring out how to manage focus is something I haven't figured out.
Two situations are dogging me: From a menu, I call show() on a pane which exposes a dialog to set some parameters. On the Win32 platform, when I close it, focus does not return to the other docked AUI panes behind it, but rather to my Eclipse PyDev environment, and I have to manually mouse click the AUI stuff to get focus on it again.
Second situation - I took a pane that was previously docked and made it a floating pane instead. It comes up in front of the other docked AUI panes, but to interact with it, e.g. to click a wxButton on the pane, I have to click once to get the focus and click again to hit the button. If I had focus on it to start, a single click would be more user friendly and expected.
Googling thru documentation I find very little reference to "Focus" - Does wxPython use some other term instead of 'focus'? Any pointer someone can offer to where it is discussed?
In terms of coding, is there some method equiv. of:
self._mgr.GetPane("myPane").HasFocus(True) # not real code!
There are two concepts in play here, and I think you may be confusing them, or combining them. First is the focus. That is the widget that currently receives the key and char events when something is pressed on the keyboard. This will almost always *not* be the active frame or other top-level window, but some widget contained within it.
The second concept is the "active" window. This is usually the top-level window that is currently at the top of the stack of windows on your screen (where the bottom is the desktop background.) Sometimes this is also referred to as the foremost window. (However there are some situations on some platforms where the active window is not necessarily the foremost window...)
There are two methods that correspond to these two concepts: Raise() and SetFocus(). Raise can be used to raise a particular TLW to be the foremost for your application and activate it, although depending on platform policies it may or may not be able to raise it above windows of another application if the other application has the active window at the time. SetFocus moves the keyboard focus to the widget if it is able to accept it. If that widget is not contained within the active window then it will have any effect.
Does this help?
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Thanks Robin - yes that makes good sense - Focus for widgets and Raise to make a top-level window. Thanks for clarifying for me.
So I experimented a bit to solve my second situation below, but without luck :*( I'll ignore the 1st issue until I have to wrangle with a winpc again.
Working with a floating pane that is on top of everything else (so I assume its the Top level Window) I still have to click the mouse twice on the button two activate it. I even SetFocus to the wxButton on that page, and still no improvement.
I would have thought that in the active window, of the active application, I could click on a widget once to get it to respond with the single click.
Am I missing something else?
Ross.
···
On 21-Oct-08, at 1:23 PM, Robin Dunn wrote:
Ross wrote:
I'm using an AUI framework much like the wxPython demo provides. And figuring out how to manage focus is something I haven't figured out.
Two situations are dogging me: From a menu, I call show() on a pane which exposes a dialog to set some parameters. On the Win32 platform, when I close it, focus does not return to the other docked AUI panes behind it, but rather to my Eclipse PyDev environment, and I have to manually mouse click the AUI stuff to get focus on it again.
Second situation - I took a pane that was previously docked and made it a floating pane instead. It comes up in front of the other docked AUI panes, but to interact with it, e.g. to click a wxButton on the pane, I have to click once to get the focus and click again to hit the button. If I had focus on it to start, a single click would be more user friendly and expected.
Googling thru documentation I find very little reference to "Focus" - Does wxPython use some other term instead of 'focus'? Any pointer someone can offer to where it is discussed?
In terms of coding, is there some method equiv. of:
self._mgr.GetPane("myPane").HasFocus(True) # not real code!
There are two concepts in play here, and I think you may be confusing them, or combining them. First is the focus. That is the widget that currently receives the key and char events when something is pressed on the keyboard. This will almost always *not* be the active frame or other top-level window, but some widget contained within it.
The second concept is the "active" window. This is usually the top-level window that is currently at the top of the stack of windows on your screen (where the bottom is the desktop background.) Sometimes this is also referred to as the foremost window. (However there are some situations on some platforms where the active window is not necessarily the foremost window...)
There are two methods that correspond to these two concepts: Raise() and SetFocus(). Raise can be used to raise a particular TLW to be the foremost for your application and activate it, although depending on platform policies it may or may not be able to raise it above windows of another application if the other application has the active window at the time. SetFocus moves the keyboard focus to the widget if it is able to accept it. If that widget is not contained within the active window then it will have any effect.
Does this help?
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Thanks Robin - yes that makes good sense - Focus for widgets and Raise to make a top-level window. Thanks for clarifying for me.
A bit more clarification: In wx terminology a top-level window is any window whose class is or derives from wx.Frame or wx.Dialog. In other words, it is any window that the user can drag around and that is not contained in another window. An application can have multiple TLWs, and one of them may or may not be the foreground/foremost/active/top-of-the-z-order (or whatever) window.
So I experimented a bit to solve my second situation below, but without luck :*( I'll ignore the 1st issue until I have to wrangle with a winpc again.
Working with a floating pane that is on top of everything else (so I assume its the Top level Window) I still have to click the mouse twice on the button two activate it. I even SetFocus to the wxButton on that page, and still no improvement.
Focus doesn't make any difference for clicking, just for keyboard events.
I would have thought that in the active window, of the active application, I could click on a widget once to get it to respond with the single click.
This is on Windows, right? This behavior is standard on OS X for left-clicks, but on Windows I wouldn't expect it to be that way. It is possible to not pass clicks through to non-active windows, but it takes a change at a fairly low level to the Window Class (in the win32 API sense of the word class) and wx doesn't use that flag on their window classes. Could there be some 3rd-party software on that PC that is altering things?
Am I missing something else?
Please make a small-as-possible runnable sample that shows the problem.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Thanks Robin - yes that makes good sense - Focus for widgets and Raise to make a top-level window. Thanks for clarifying for me.
A bit more clarification: In wx terminology a top-level window is any window whose class is or derives from wx.Frame or wx.Dialog. In other words, it is any window that the user can drag around and that is not contained in another window. An application can have multiple TLWs, and one of them may or may not be the foreground/foremost/active/top-of-the-z-order (or whatever) window.
Okay - good to know. I'll look to read up on that a bit to figure out who has the attention of my system.
So I experimented a bit to solve my second situation below, but without luck :*( I'll ignore the 1st issue until I have to wrangle with a winpc again.
Working with a floating pane that is on top of everything else (so I assume its the Top level Window) I still have to click the mouse twice on the button two activate it. I even SetFocus to the wxButton on that page, and still no improvement.
Focus doesn't make any difference for clicking, just for keyboard events.
I would have thought that in the active window, of the active application, I could click on a widget once to get it to respond with the single click.
This is on Windows, right? This behavior is standard on OS X for left-clicks, but on Windows I wouldn't expect it to be that way. It is possible to not pass clicks through to non-active windows, but it takes a change at a fairly low level to the Window Class (in the win32 API sense of the word class) and wx doesn't use that flag on their window classes. Could there be some 3rd-party software on that PC that is altering things?
No - its Mac OSX 10.4. So it sounds like I'd be stuck with two left clicks to get my button to work?
I wonder if there's something I can do to capture mouse-rollover to skip one of them...Just thinking out loud?
Am I missing something else?
Please make a small-as-possible runnable sample that shows the problem.
will try to do so if I can't sort it out....
Thx again!
···
On 21-Oct-08, at 5:34 PM, Robin Dunn wrote:
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
This is on Windows, right? This behavior is standard on OS X for left-clicks, but on Windows I wouldn't expect it to be that way. It is possible to not pass clicks through to non-active windows, but it takes a change at a fairly low level to the Window Class (in the win32 API sense of the word class) and wx doesn't use that flag on their window classes. Could there be some 3rd-party software on that PC that is altering things?
No - its Mac OSX 10.4. So it sounds like I'd be stuck with two left clicks to get my button to work?
Yeah, that's one of my few gripes about OS X, that the left-clicks on a non-active window don't pass through after the activation. The really weird part to me is that other mouse events do get sent to the non-active windows. Go figure.
I wonder if there's something I can do to capture mouse-rollover to skip one of them...Just thinking out loud?
IIRC there is a window style that can be used to make it so clicks on tool windows pass through as expected, but I don't remember what it is off the top of my head. It wouldn't help much in this case anyway since AUI is making the floating frames itself and doesn't let you control how it is done.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!