There is a systems setting to change this behavior and the buttons will show focus.
Got it. Keyboard Navigation. I had that turned off.
I never paid attention to it because the development environment I came from (4D) overrode that with the focus setting in each control.
In the case of this one layout I have that keeps sending the focus to a non-focusable bevel button, the Keyboard Navigation on/off setting did not change the behavior for that button. It gets the focus either way.
In general, provide the os version. Why, in this specific case, the Toogle does not works on several macOS versions. Pre-m1 I think, but I am unsure.
This can be seen on web pages / books screen shots on several years.
On the other way, I never understand why a Control who cannot receive text (user edited) can have the Focus.
My question here is “What For ?”.
Last advice: in doubt (in fact when I do not know or recall a feature, something), I check in the FInder and some other applications: I follow the majority (if 4 applications on 5 do it a certain way, I adopt it).
You can eventually ask here.
A good read: search “Human Interface Guidelines” on the Internet and go to the one that came from Apple. The same document exists now for Linux and Windows.
When a button has the focus, the user can “click” it by pressing the space bar.
I’m using macOS 15.3.1 and Xojo 2024 4.2
This one I do not know. Probably a recent addition./
I forgot the Return Key: in Alberto’s example, a key press on the Return Key execute the code in the (OK) Button.
Have you read the introduction books ? Type introduction in the Documentation and you will have them.
“Introduction to Xojo Programming” is nice too.
It’s off on any default macOS installation.
If you consider 20 years as recent, then yes.
It was 20 years after my debuts with Macintosh 
Yes, I’ve been through the intro docs and they are a good launching pad. I’m also finding the docs easy to navigate and really benefitting from the code examples.
I’m especially impressed with how the folks at Xojo have made my transition into the world of OOP so smooth. I’m reaping expert benefits of that without being an expert.
But, I’m still feeling somewhat urgent about the bugs in the Tab Order system. It’s like using a really capable word processor that doesn’t always honor its ruler settings. There are ways to make a document look correctly formatted, but you can’t change the font size without having to revisit the formatting workaround. It’s a little unexpected for such a mature product.
The bug appears when you zdd z DrztchField. When removing nboth of them, the Tab works foine n both ways (Tab and Shift-Tab)
It is not related to Tab ID or the order you add the controls nor where you place it (IMHO).
@Patrick_Salo: can you confirm that ?
1 Like
I created a cluttered layout full of text fields that tabbed correctly after alternately using both Auto Adjust Tab buttons. Introducing a SearchField made pressing the tab key skip one of the TextFields. Individually introducing more search fields would at some point cause more text fields to be skipped.
Removing the search fields, not just making them invisible and disabled, also fixed the problem of a non-focusable button getting the focus, as well as a problem not being able to set the focus on a field at window opening: https://tracker.xojo.com/xojoinc/xojo/-/issues/78527.
It looks like introducing SearchFields is the culprit. Brings to mind my fantasy bug fix of telling the customer, “Well, don’t do that”.
I found the guilty when I started to remove a Control / Run / Undo / Remove another control…
For strange reason, I haf the SearchField(s) on my eye (they dislike me). Then !
I just learned that a SearchField inside a DesktopContainer in the layout can intercept Me.SetFocus in the Opening event of a text field in the layout and cause a rectangle to display the focus ring instead. Fortunately, changing the Super of the DesktopSearchFields to DesktopTextField required almost no code modifications.
Great find @Emile_Schwarz and I can confirm that this is indeed the case with the DesktopSearchField causing tab order issues. The good news is that the root cause can be found but the bad news is that there appears to be several tab related bugs here as my other tab related sample projects without DesktopSearchFields still exhibit the same behavior under Xojo 2024r4.2. Here’s the breakdown…
74145 - https://tracker.xojo.com/xojoinc/xojo/-/issues/74145
- Root Cause Found (Has Search Fields)
- Root Cause Unknown (No Search Fields)
#74802 - Double Tab Required To Tab To Next Control
- Root Cause Unknown (No Search Fields)
@Keith_Culotta I’m not following your fix as simply changing the super means that you no longer have an actual DesktopSearchField. Are you implying that your workaround is to just use a DesktopTextField without the DesktopSearchField look and feel while replicating the functionality?
Yes. Just changing the Super to DesktopTextField changed the appearance of the button, but searching worked the same. It doesn’t look as neat without the Magnifying Glass and xClear button, but I can supply visual cues as to the purpose of the fields.
I did need to change code in the one instance where I converted the field from a DesktopControl after finding it in a Window.Controls:
For Each obj In Self.Controls
If obj IsA DesktopTextField Then
DTTF=DesktopTextField(obj)…
Ah okay and I just wanted to make sure I wasn’t missing something.
Root Cause
DesktopSearchField breaks tabbing.
Workaround
Don’t use the DesktopSearchField.
Just to verify for macOS 15.3.1 Xojo 2024 4.2
In: Container Control Focus Issue 1.1.1.xojo_binary_project
Mac Keyboard Navigation on - all objects are visited
Mac Keyboard Navigation off - no object is visited
In: Double Tab Required To Tab To Next Control
Mac Keyboard Navigation on - the double-tab is required in the first tab cycle - same with shift-tabbing
Mac Keyboard Navigation off - the focus never leaves the Canvas - same with shift-tabbing
1 Like
Write Issue(s). Doing that here does nothing. It’s aForum discussion, not a formal bug report to Xojo.
I will never ever change Keyboard Navigation: I’ve dont that once and know (I get it active for years…). I do not need it.
Whatis Focus / What do ut do ?
Google:
Focus means you have selected the particular GUI element.
I don’t get the use to set the focus to a Label, PopupMenu, etc.
I do not get the use of a Container that tooks the whole window size that holds all controls.
Oh, yes, I know: you like verbose programming:
You need to write (If I understand Container):
Container1.TextArea1.Text = "I love typing text on my keyboard"
instead of:
TextArea1.Text = "I love typing text on my keyboard"
Also:
I do not get the need to make a bug quest: at least, you will find some bug. Will it impact your developent ? I do not know? but remember: “who search will find”
You want:
change the Label Contents whent it got the Focus ?
execute an action when it gor the Focus ?
Explain, in another thread, this one is marked as Solution is set to True, whay you want to do in your software that needs to ser the Focus on these Controls…
Not true within the container, where you continue to code as before.
This is the important word in the sentence.
But the point is not there.
What do you think about placing a Container covering the whole window and place Controls there ?