Why is there no method to remove the focus from a text control?
skywind MailingLists
And as there is no method what is the best workaround? Disabling and enabling the control?
Igor Korot
On Mon, Jul 17, 2023 at 2:19 PM skywind MailingLists
<mailin...@skywind.eu> wrote:
>
> I would like to remove the focus of a text control but there does not seem to be a method for it, why?
However I'm not sure it will generate the focus_lost event...
Thank you.
>
> And as there is no method what is the best workaround? Disabling and enabling the control?
>
> You received this message because you are subscribed to the Google Groups "wx-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to wx-dev+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/wx-dev/14F096BF-C8D1-4AEC-B900-C94C7E987C9F%40skywind.eu.
Vadim Zeitlin
sM> I would like to remove the focus of a text control but there does not
sM> seem to be a method for it, why?
Because the focus must always be somewhere, so you can't just remove it,
but you have to give it to something else.
sM> And as there is no method what is the best workaround? Disabling and
sM> enabling the control?
Please try to think where your users would expect the focus to be, if the
text control doesn't have it, and set it there instead.
Regards,
VZ
skywind MailingLists
If the focus must always be somewhere wxWindow::FindFocus() should never return nullptr but it does (macOS), e.g. after creating a dialog in macOS wxWindow::FindFocus() returns NULL when trying to find the focused window during handling an update UI event. Additionally, no control visually has the focus. Only when clicking with the mouse in a text control FindFocus() finds a window (in this case a wxTextCtrl).
Therefore, how can I get back to the initial situation?
PS: In macOS I should be able to call resignFirstResponder on a responder object but I am dealing with wxWidgets.
Regards,
Hardy
Vadim Zeitlin
sM> If the focus must always be somewhere wxWindow::FindFocus() should
sM> never return nullptr but it does (macOS), e.g. after creating a dialog
sM> in macOS wxWindow::FindFocus() returns NULL when trying to find the
sM> focused window during handling an update UI event. Additionally, no
sM> control visually has the focus. Only when clicking with the mouse in a
sM> text control FindFocus() finds a window (in this case a wxTextCtrl).
I think this is a bug as the first focusable control should have focus
after the dialog creation. Unfortunately I don't know how to fix it, but
any fixes would be welcome.
sM> PS: In macOS I should be able to call resignFirstResponder on a
sM> responder object but I am dealing with wxWidgets.
Again, IMO some control should always have focus if at all possible, and I
think we should rather (try to) ensure that this is the case than do
anything else, but nothing prevents you from using Mac-specific code to
call resignFirstResponder if you really want to.
Regards,
VZ
skywind MailingLists
The issue is that in macOS there is not necessarily a window that has a focus. And what about dialogs that do not have text controls at all, only buttons for example? Buttons cannot get a focus under macOS, I believe (I haven’t seen it and tried it though).
Furthermore, IMHO wxWidgets should be as close as possible to the native OS (otherwise you can also use QT). And if macOS users do not necessarily expect it, why force them?
Therefore, it should rather be the other way round. Unsetting a focus might not be possible when using other operating systems but it should be implemented for macOS.
Regards,
Hardy
Vadim Zeitlin
sM> Furthermore, IMHO wxWidgets should be as close as possible to the
sM> native OS (otherwise you can also use QT). And if macOS users do not
sM> necessarily expect it, why force them?
sM>
sM> Therefore, it should rather be the other way round. Unsetting a focus
sM> might not be possible when using other operating systems but it should
sM> be implemented for macOS.
Sorry, but I'm still not convinced: in your examples, when there is no
control capable of taking focus, things should already work as expected,
i.e. nothing should indeed be focused. But if there is a control that can
take focus, wouldn't it still make sense to give it to it? I.e. why
wouldn't macOS users expect it?
Regards,
VZ
skywind MailingLists
One example is the Maps app that is delivered by Apple. Theoretically, the field to enter a location could have the focus after starting the app (it is the only field that can receive a focus) but it has not. And this is the case for a lot of apps or situations. I think that you should not be distracted by the focus from the main thing, namely the map.
In cases where an app expects user input (like a find dialog), there is nearly a 100% chance that the field for entering the search term is focused.
Regards,
Hardy
Stefan Csomor
Hi
>One example is the Maps app that is delivered by Apple. Theoretically, the field to enter a location could have the focus after starting the app (it is the only field that can receive a focus)
but it >has not. And this is the case for a lot of apps or situations. I think that you should not be distracted by the focus from the main thing, namely the map.
I wouldn’t take apps that are ported back from the iOS world (where keyboard focus has a different priority) using Catalyst as reference (in macOS 11 Big Sur this started for maps, imessage etc.). They have IMHO a sub-par experience to ‘true’ desktop apps. Apple Maps used to focus on the search field. Now its keyboard focus is on the map itself… the arrow keys can be used there, if you set the focus on the search field then you can tab to the results list and then keyboard focus runs havoc because it’s reacting to the item selected by default and popping up floating windows which get the focus or suddenly the map itself gets the focus again and so sooner or later it’s not possible anymore to move through the results list via arrow keys …
Using the same app on pre-Big-Sur systems the keyboard focus performs predictably and remains stable
Best,
Stefan
skywind MailingLists
--
You received this message because you are subscribed to the Google Groups "wx-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wx-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wx-dev/GV0P278MB02433B2DEEFB04B82E64B174DD39A%40GV0P278MB0243.CHEP278.PROD.OUTLOOK.COM.
Vadim Zeitlin
sM> PS: But let’s stop the discussion if there is no intention to change it.
Just to be clear, I'm not against adding some Mac-specific function (i.e.
one with a "OSX" prefix) to do it if people think it can be helpful. But as
long as there is no support for doing this under the other platforms, I
don't see any point in adding it to the portable wx API.
Regards,
VZ
Stefan Csomor
Hi Hardy
Anyway, fact is that in macOS there is a way to disable the focus.
Yes, at least to set it to the toplevel window itself
- but not with resignFirstResponder which is a callback method, the OS notifies a control that it intends to give the keyboard focus to another control, you can veto it be returning false.
https://developer.apple.com/documentation/appkit/nsresponder/1532115-resignfirstresponder/ The docs explicitly say “Never invoke this method directly”
- I think the way to implement this would be to call makeFirstResponder on the toplevel NSWindow with an NSResponder of nil, resetting it to the NSWindow itself.
Right now when a SetFocus event is sent to a control that cannot really be focused (canBecomeKeyView returning false) I check whether the window is not yet visible, if this is the case I’m preparing the NSWindow with setInitialFirstResponder, otherwise I return false and let the focus be where it was. This could of course be changed to setting the focus to the NSWindow itself, but I’m reluctant to do this, because of the platform differences about which controls can be focused at all, and this change would perhaps lead to more surprises for users on macOS when the app itself is not aware of these differences.
So an explicit implementation would be better IMHO, which could set the focus to the toplevel window itself, if this works the same across the platforms then this could be the place to hook makeFirstResponder: nil into …
Best,
Stefan