#14142: wxOSX-cocoa: No EVT_KILL_FOCUS events
17 views
Skip to first unread message
wxTrac
Mar 26, 2012, 11:33:09 PM3/26/12
to wx-...@googlegroups.com
Ticket URL: <http://trac.wxwidgets.org/ticket/14142>
#14142: wxOSX-cocoa: No EVT_KILL_FOCUS events
-----------------------------+----------------------------------------------
Reporter: robind | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: wxOSX-Cocoa | Version: 2.9-svn
Keywords: OSX cocoa focus | Blockedby:
Patch: 0 | Blocking:
-----------------------------+----------------------------------------------
It seems that at least for some types of widgets there are no
EVT_KILL_FOCUS events being generated. One way to see the issue is to run
the stc sample, it should turn off the flashing of the caret when the stc
gets the lost focus event.
--
Ticket URL: <http://trac.wxwidgets.org/ticket/14142>
wxTrac
Oct 6, 2012, 1:53:12 PM10/6/12
to wx-...@googlegroups.com
Ticket URL: <http://trac.wxwidgets.org/ticket/14142#comment:1>
#14142: wxOSX-cocoa: No EVT_KILL_FOCUS events
-----------------------------+----------------------------------------------
Reporter: robind | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: wxOSX-Cocoa | Version: 2.9-svn
Keywords: OSX cocoa focus | Blockedby:
Patch: 0 | Blocking:
-----------------------------+----------------------------------------------
Comment(by DoZo1971):
Same problem here, notably with wxTextCtrls. I've attached a small demo
program showing the problem, clicking outside of the frame (on the desktop
for instance) doesn't give a kill focus event on the wxTextCtrl *until*
the window containing the wxTextCtrl is made active again. Then the
delayed kill focus event is received, together with a set focus event.
--
Ticket URL: <http://trac.wxwidgets.org/ticket/14142#comment:1>
#14142: wxOSX-cocoa: No EVT_KILL_FOCUS events
-----------------------------+----------------------------------------------
Reporter: robind | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: wxOSX-Cocoa | Version: 2.9-svn
Keywords: OSX cocoa focus | Blockedby:
Patch: 0 | Blocking:
-----------------------------+----------------------------------------------
Same problem here, notably with wxTextCtrls. I've attached a small demo
program showing the problem, clicking outside of the frame (on the desktop
for instance) doesn't give a kill focus event on the wxTextCtrl *until*
the window containing the wxTextCtrl is made active again. Then the
delayed kill focus event is received, together with a set focus event.
--
Ticket URL: <http://trac.wxwidgets.org/ticket/14142#comment:1>
wxTrac
Oct 7, 2012, 4:02:30 AM10/7/12
to wx-...@googlegroups.com
Ticket URL: <http://trac.wxwidgets.org/ticket/14142#comment:2>
#14142: wxOSX-cocoa: No EVT_KILL_FOCUS events
-----------------------------+----------------------------------------------
Reporter: robind | Owner:
Type: defect | Status: infoneeded_new
* status: new => infoneeded_new
Comment:
is the leaving of the window unchanged - just switching to another app -
itself really a focus lost situation ?
--
Ticket URL: <http://trac.wxwidgets.org/ticket/14142#comment:2>
#14142: wxOSX-cocoa: No EVT_KILL_FOCUS events
-----------------------------+----------------------------------------------
Reporter: robind | Owner:
Priority: normal | Milestone:
Component: wxOSX-Cocoa | Version: 2.9-svn
Keywords: OSX cocoa focus | Blockedby:
Patch: 0 | Blocking:
-----------------------------+----------------------------------------------
Changes (by csomor):
Component: wxOSX-Cocoa | Version: 2.9-svn
Keywords: OSX cocoa focus | Blockedby:
Patch: 0 | Blocking:
-----------------------------+----------------------------------------------
* status: new => infoneeded_new
Comment:
is the leaving of the window unchanged - just switching to another app -
itself really a focus lost situation ?
--
Ticket URL: <http://trac.wxwidgets.org/ticket/14142#comment:2>
wxTrac
Oct 7, 2012, 4:11:42 AM10/7/12
to wx-...@googlegroups.com
Ticket URL: <http://trac.wxwidgets.org/ticket/14142#comment:3>
#14142: wxOSX-cocoa: No EVT_KILL_FOCUS events
-----------------------------+----------------------------------------------
Reporter: robind | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: wxOSX-Cocoa | Version: 2.9-svn
Keywords: OSX cocoa focus | Blockedby:
Patch: 0 | Blocking:
-----------------------------+----------------------------------------------
Changes (by DoZo1971):
* status: infoneeded_new => new
Comment:
The problem is not limited to app switching. If you have two windows with
wxTextCtrls within the same wxWidgets application and you activate a
wxTextCtrl of the second window, the previously active wxTextCtrl of the
first window doesn't receive a kill focus either.
--
Ticket URL: <http://trac.wxwidgets.org/ticket/14142#comment:3>
#14142: wxOSX-cocoa: No EVT_KILL_FOCUS events
-----------------------------+----------------------------------------------
Reporter: robind | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: wxOSX-Cocoa | Version: 2.9-svn
Keywords: OSX cocoa focus | Blockedby:
Patch: 0 | Blocking:
-----------------------------+----------------------------------------------
* status: infoneeded_new => new
Comment:
The problem is not limited to app switching. If you have two windows with
wxTextCtrls within the same wxWidgets application and you activate a
wxTextCtrl of the second window, the previously active wxTextCtrl of the
first window doesn't receive a kill focus either.
--
Ticket URL: <http://trac.wxwidgets.org/ticket/14142#comment:3>
wxTrac
Oct 7, 2012, 4:39:01 AM10/7/12
to wx-...@googlegroups.com
Ticket URL: <http://trac.wxwidgets.org/ticket/14142#comment:4>
#14142: wxOSX-cocoa: No EVT_KILL_FOCUS events
-----------------------------+----------------------------------------------
Reporter: robind | Owner: csomor
Type: defect | Status: accepted
* owner: => csomor
* status: new => accepted
Comment:
ok, I found the reason for the seeming late kill focus, it isn't related
to the deactivating of the window
(which IMHO wouldn't have to trigger a kill focus, since I might be in a
partial edit, having to look something up in a different app and come back
to finish editing in the same field, only when really leaving the field, a
validation would make sense, but I'll bow to crossplatform behavior here -
so I'll model it after msw if this behaves differently)
the reason for focus kill is the wxFrame::OnActivate when coming back
which sets the focus explicitly, therefore triggering a focus kill... I'll
run the same on msw and compare ...
--
Ticket URL: <http://trac.wxwidgets.org/ticket/14142#comment:4>
#14142: wxOSX-cocoa: No EVT_KILL_FOCUS events
-----------------------------+----------------------------------------------
Type: defect | Status: accepted
Priority: normal | Milestone:
Component: wxOSX-Cocoa | Version: 2.9-svn
Keywords: OSX cocoa focus | Blockedby:
Patch: 0 | Blocking:
-----------------------------+----------------------------------------------
Changes (by csomor):
Component: wxOSX-Cocoa | Version: 2.9-svn
Keywords: OSX cocoa focus | Blockedby:
Patch: 0 | Blocking:
-----------------------------+----------------------------------------------
* owner: => csomor
* status: new => accepted
Comment:
ok, I found the reason for the seeming late kill focus, it isn't related
to the deactivating of the window
(which IMHO wouldn't have to trigger a kill focus, since I might be in a
partial edit, having to look something up in a different app and come back
to finish editing in the same field, only when really leaving the field, a
validation would make sense, but I'll bow to crossplatform behavior here -
so I'll model it after msw if this behaves differently)
the reason for focus kill is the wxFrame::OnActivate when coming back
which sets the focus explicitly, therefore triggering a focus kill... I'll
run the same on msw and compare ...
--
Ticket URL: <http://trac.wxwidgets.org/ticket/14142#comment:4>
wxTrac
Oct 7, 2012, 5:16:06 AM10/7/12
to wx-...@googlegroups.com
Ticket URL: <http://trac.wxwidgets.org/ticket/14142#comment:5>
#14142: wxOSX-cocoa: No EVT_KILL_FOCUS events
-----------------------------+----------------------------------------------
Great that you are looking into it.
If you manage to fix it, is there some way for me to get to the modified
code? (i'm new to wxWidgets) A nightly build or something. I'm using 2.9.4
at the moment.
Isn't the definition of focus simply "where the keyboard events go"? Then
the widget should receive the kill focus because key events are no longer
routed to that widget. Even if you change to another window for a brief
moment. I could imagine a third focus "state" though.. "would have focus
if the window was active". But that seems to be implemented already in
another way, since windows "remember" where the focus was previously and
return to it when the window is reactivated.
--
Ticket URL: <http://trac.wxwidgets.org/ticket/14142#comment:5>
#14142: wxOSX-cocoa: No EVT_KILL_FOCUS events
-----------------------------+----------------------------------------------
Reporter: robind | Owner: csomor
Type: defect | Status: accepted
Type: defect | Status: accepted
Priority: normal | Milestone:
Component: wxOSX-Cocoa | Version: 2.9-svn
Keywords: OSX cocoa focus | Blockedby:
Patch: 0 | Blocking:
-----------------------------+----------------------------------------------
Comment(by DoZo1971):
Component: wxOSX-Cocoa | Version: 2.9-svn
Keywords: OSX cocoa focus | Blockedby:
Patch: 0 | Blocking:
-----------------------------+----------------------------------------------
Great that you are looking into it.
If you manage to fix it, is there some way for me to get to the modified
code? (i'm new to wxWidgets) A nightly build or something. I'm using 2.9.4
at the moment.
Isn't the definition of focus simply "where the keyboard events go"? Then
the widget should receive the kill focus because key events are no longer
routed to that widget. Even if you change to another window for a brief
moment. I could imagine a third focus "state" though.. "would have focus
if the window was active". But that seems to be implemented already in
another way, since windows "remember" where the focus was previously and
return to it when the window is reactivated.
--
Ticket URL: <http://trac.wxwidgets.org/ticket/14142#comment:5>
wxTrac
Oct 7, 2012, 7:07:22 AM10/7/12
to wx-...@googlegroups.com
Ticket URL: <http://trac.wxwidgets.org/ticket/14142#comment:6>
#14142: wxOSX-cocoa: No EVT_KILL_FOCUS events
-----------------------------+----------------------------------------------
yes, looking at it from a keyboard-focus view it clearly needs a focus-
kill, looking at it from a form-field processing view, the notion of a
'editing ended' concept as cocoa has makes more sense, since it allows to
escape the 'modality' of form entry, without sacrificing validation. But
I've checked both situations on msw since, and I'll have to get to the
same behaviour - focus lost as soon as the toplevel window gets
deactivated
You should get a subversion client, and then download trunk, if and when
I'm able to fix it...
--
Ticket URL: <http://trac.wxwidgets.org/ticket/14142#comment:6>
#14142: wxOSX-cocoa: No EVT_KILL_FOCUS events
-----------------------------+----------------------------------------------
Reporter: robind | Owner: csomor
Type: defect | Status: accepted
Type: defect | Status: accepted
Priority: normal | Milestone:
Component: wxOSX-Cocoa | Version: 2.9-svn
Keywords: OSX cocoa focus | Blockedby:
Patch: 0 | Blocking:
-----------------------------+----------------------------------------------
Comment(by csomor):
Component: wxOSX-Cocoa | Version: 2.9-svn
Keywords: OSX cocoa focus | Blockedby:
Patch: 0 | Blocking:
-----------------------------+----------------------------------------------
yes, looking at it from a keyboard-focus view it clearly needs a focus-
kill, looking at it from a form-field processing view, the notion of a
'editing ended' concept as cocoa has makes more sense, since it allows to
escape the 'modality' of form entry, without sacrificing validation. But
I've checked both situations on msw since, and I'll have to get to the
same behaviour - focus lost as soon as the toplevel window gets
deactivated
You should get a subversion client, and then download trunk, if and when
I'm able to fix it...
--
Ticket URL: <http://trac.wxwidgets.org/ticket/14142#comment:6>
wxTrac
Nov 27, 2012, 8:33:26 AM11/27/12
to wx-...@googlegroups.com
Ticket URL: <http://trac.wxwidgets.org/ticket/14142#comment:10>
#14142: wxOSX-cocoa: No EVT_KILL_FOCUS events
-----------------------------+----------------------------------------------
-----------------------------+----------------------------------------------
Comment(by csomor):
with r73043 at least the window switches now trigger a focus lost as
expected
--
Ticket URL: <http://trac.wxwidgets.org/ticket/14142#comment:10>
#14142: wxOSX-cocoa: No EVT_KILL_FOCUS events
-----------------------------+----------------------------------------------
Reporter: robind | Owner: csomor
Type: defect | Status: accepted
Type: defect | Status: accepted
Priority: normal | Milestone:
Component: wxOSX-Cocoa | Version: 2.9-svn
Keywords: OSX cocoa focus | Blockedby:
Patch: 0 | Blocking: 13495, 13495, 13495
Component: wxOSX-Cocoa | Version: 2.9-svn
Keywords: OSX cocoa focus | Blockedby:
-----------------------------+----------------------------------------------
Comment(by csomor):
with r73043 at least the window switches now trigger a focus lost as
expected
--
Ticket URL: <http://trac.wxwidgets.org/ticket/14142#comment:10>
wxTrac
May 17, 2014, 7:24:32 AM5/17/14
to wx-...@googlegroups.com
#14142: wxOSX-cocoa: No EVT_KILL_FOCUS events
--------------------------+-----------------------------
Reporter: robind | Owner: csomor
Type: defect | Status: closed
Priority: normal | Milestone:
Component: wxOSX-Cocoa | Version: stable-latest
Resolution: duplicate | Keywords: OSX cocoa focus
Blocked By: | Blocking: 13495
Patch: 0 |
--------------------------+-----------------------------
Changes (by vadz):
* status: accepted => closed
* resolution: => duplicate
* blocking: 13495, 13495, 13495, 13495, 13495 => 13495
Comment:
This looks to be the same as #14269 but the other one has patches, so
let's close this one and keep the other one.
--
Ticket URL: <http://trac.wxwidgets.org/ticket/14142#comment:13>
Reply all
Reply to author
Forward
0 new messages