wxCocoa and focus events

[Armel]

(nearly wxtrunk)

 

Hi,

 

I am attempting to use wxCocoa for my to-be-released version and I have a hard time with focus.

First, the becomeFirstResponder/resignFirstResponder are called in a way by Cocoa that makes it impossible to know the "old window" easily (becomes it first resigns then give the focus), so the existing code using FindFocus is simply false: all the focus events currently have 'this == otherWindow'...

Second, the trick to avoid  bad KILL_FOCUS events on combos when giving focus to the inner editor is so powerful that combo never get a single KILL_FOCUS event at all...

 

Now, I'm pretty bad with Cocoa and Objective C stuff, so I cannot fix it. The only way I think of this would be to catch a "focus about to be given to this view" event and keep the view pointer for the KILL_FOCUS  otherWindow value, and track all "focus about to be removed from the view" events as well to be able to provide the otherWindow to SET_FOCUS events... maybe NSApplication::becomeFirstResponder is overridable? I don't know if possible and how...

 

Could a Cocoa guru take a look at this? the focus events are pretty unusable in the current state unfortunately.

 

Best regards

Armel

[David Connet]

Just as an FYI - I just discovered that relying on kill focus events on OSX is not a good thing. On Windows, my edit control always gets a kill event when you click on a button. Not so on OSX. Watching the window closely, it was evident why - clicking on a button does not set focus there, hence the edit control never loses focus. Quite an eye-opener to a hard-core windows dude... (luckily, I should be able to easily refactor and key off text-change events instead)

Dave

---

From: Armel <armel....@elliecomputing.com>
To: wx-...@googlegroups.com
Sent: Tuesday, May 22, 2012 8:33 AM
Subject: [wx-dev] wxCocoa and focus events

--
To unsubscribe, send email to wx-dev+un...@googlegroups.com
or visit http://groups.google.com/group/wx-dev

[Armel]

Le mardi 22 mai 2012 18:15:54 UTC+2, Dave a écrit :

Just as an FYI - I just discovered that relying on kill focus events on OSX is not a good thing. On Windows, my edit control always gets a kill event when you click on a button. Not so on OSX. Watching the window closely, it was evident why - clicking on a button does not set focus there, hence the edit control never loses focus. Quite an eye-opener to a hard-core windows dude... (luckily, I should be able to easily refactor and key off text-change events instead)

 

 my case is a bit different, I use the kill focus event to simply put back some "user friendly" value in the text field when the user did not actually edited it (i.e. on_set_focus puts an "editable" version of the text).

 

nonetheless the events don't really works :(

 

Regards

Armel

PS: please take care not to put my email address when replying :-/

[John Roberts]

On 23/05/2012 1:13 AM, Armel wrote:
>
> Le mardi 22 mai 2012 18:15:54 UTC+2, Dave a �crit :

>
> Just as an FYI - I just discovered that relying on kill focus events
> on OSX is not a good thing. On Windows, my edit control always gets
> a kill event when you click on a button. Not so on OSX. Watching the
> window closely, it was evident why - clicking on a button does not
> set focus there, hence the edit control never loses focus. Quite an
> eye-opener to a hard-core windows dude... (luckily, I should be able
> to easily refactor and key off text-change events instead)

I found the same thing with dialogs and stdbuttonsizer and had to
explicitly set focus to the button in an onclick handler to remove focus
from whatever control had focus.

> my case is a bit different, I use the kill focus event to simply put
> back some "user friendly" value in the text field when the user did not
> actually edited it (i.e. on_set_focus puts an "editable" version of the
> text).
> nonetheless the events don't really works :(
> Regards
> Armel

I gave up on wxComboBox for my autocomplete and add user new values for
similar reasons and used a wxListCtrl/wxComboCtrl combination which does
work.

The zoom wxComboBox in the wxPrintPreview frame doesn't work in
OSX-Cocoa as another example.

Regards, John

[Armel]

so far my understanding of the problem is that we cannot catch becomeFirstResponder/resignFirstResponder for the so called "field editor" of the current NSWindow (without forcing usage of our own NSTextView derived class in all widgets).

 

the good news is that we get textDidEndEditing notification for NSComboBox as well as we do on a wxNSTextView, and sending a focus lost event from there seems to do the job.

 

I overloaded wxNSWindow::makeFirstResponder, noting which responder is about to resign (from the key window), and which is about to gain first responder status, it seems that we can set the "otherWindow" mostly correct with that. this is independent from the other fixes BTW.

 

When testing with the "text" sample, I realized that:

- I get two "focus lost" event on controls with wxTE_MULTILINE... probably because m_hasEditor is not set for wxNSTextViewControl

- the multiline field does not process Enter nor TAB neither until m_hasEditor is set.

 

Regards

Armel

 

 

[John Roberts]

On 23/05/2012 7:24 AM, John Roberts wrote:
> The zoom wxComboBox in the wxPrintPreview frame doesn't work in
> OSX-Cocoa as another example.
>

I was wrong about the above, it was MSW where I had noticed that only
the zoom buttons worked. I must take another look at why.
Regards, John

[John Roberts]

Found it. Only seen on win64 where I had used the following
{{{
preview->SetZoom( zoom );
wxPreviewFrame *frame = new wxPreviewFrame( preview ...)
frame->InitializeWithModality( ... );
frame->GetControlBar()->SetZoomControl( zoom );
frame->Show( true );
}}}
The call to SetZoomControl() when used after SetZoom() caused a
re-entrance to CreateButtons(). I twigged when previewing a landscape
page where the frame was wider. There were 2 Close buttons visible. The
other controlbar controls were duplicated as well but perfectly overlaid
and hence not obviously twins.

Setting the zoom via the gui always returned the choice ctrl value for
the unchanged first choice ctrl created but the second one showed the
changed value on screen.

Fixed by commenting the call to SetZoomControl() but weird it was ok in
win32. I can't reproduce the error in the sample so I assume it was
dependent on my code.

Regards, John