Layouts: The Tab key can send the cursor anywhere

[Keith_Culotta]

Feedback Case Number: 78428, 74145, 64312, and various forum discussions

After scanning some of the Forum’s history, it looks like making layout’s tab order work for data entry layouts has not been a priority. After some point in a layout’s evolution, after adding, removing, and reordering objects, pressing the tab key at runtime can send the cursor almost anywhere in the layout. It can get stuck rotating between only a portion of the form’s tab-able objects or light up the focus ring on a button marked not tab-able or focusable.

Interestingly, shift-tabbing in these affected layouts has so far worked flawlessly to get from one entry object to another.

Still, it would probably be easier to write some sort of fix for this than to try to reprogram all the users to enter their data in reverse order. Before attempting that (working on a fix), I wanted to ask if there is already there a commonly used work around for this problem?

[Tim_Parnell]

These three buttons. The first one lets you manually define your tab order with drag / rearrange. The middle one fixes your tab order and can recover controls that have been removed from the tab order.

I’m sorry there’s no longer a PDF manual for you. This resource remains however: Using the IDE — Xojo documentation

Please start making use of the “Getting Started” category rather than “Bugs and Feature Requests”.

[Keith_Culotta]

Alas, the buttons do not work. The issue has already been declared a bug (check out https://tracker.xojo.com/xojoinc/xojo/-/issues/78428). I’m just hoping there is an already discovered workaround.

[Patrick_Salo]

Agreed, tabbing can be very haphazard under Xojo and sometimes it works just fine and other times it’s extremely problematic. You’re absolutely correct in that in my experience, Shift+Tab generally works fine, but this isn’t what users are going to use.

You already referenced one of my tickets…

74145: Tab Order Can Become Broken in Container Controls

…but I also have this one out there as well:

74802: Double Tab Required To Tab To Next Control

Unfortunately some of the workarounds and “fixes” within, no longer seem to work these days.

The only reliable workaround that I’ve found, that’s quite a PITA especially if you have lots of controls, is to capture the KeyDown event, check for a Tab and Shift+Tab, and manually place the focus.

[Keith_Culotta]

@Patrick_Salo

The only reliable workaround that I’ve found, that’s quite a PITA especially if you have lots of controls, is to capture the KeyDown event, check for a Tab and Shift+Tab, and manually place the focus.

It looks like KeyDown in each control is the … key. Too bad the TAB can’t be caught at the Window level (without the need to add an event in each object anyway).

But, the other question that the low priority of fixing a fundamental feature like tabbing around a layout in a desired order raises, is Xojo not expecting to be used to create data entry type apps?

It looks to me like it would be perfect for that. It is a really impressive and flexible environment, and a lot easier to learn than I had imagined, but I can see where a newcommer could walk away with the impression their intended use for the platform was not one of its design targets.

[Patrick_Salo]

@Keith_Culotta

It looks like KeyDown in each control is the … key. Too bad the TAB can’t be caught at the Window level (without the need to add an event in each object anyway).

Yup, you hit the nail on the head and why this is such a PITA. An alternative would be to create a module with a method that for all intensive purposes, recreates the first button mentioned above, “Show Tab Order” programmatically, in order to make things easier to manage long term. You’re still stuck with KeyDown events everywhere though but the code within would be much more streamlined and call out the module and method.

It hasn’t been high on my list to make this happen within my own code and knowing how Murphy works, I know the moment I spend hours heading down this road, Xojo will find the bug(s) and fix things.

I agree and I personally see these bugs as much bigger issues than they might appear at first blush due to the accessibility implications involved. But there’s also many, myself included, that prefer keyboard manipulation of interfaces versus heavy mouse usage.

P.S. Many might question my recommendation of a module and method here, but considering how often I run into this across projects, it would make a nice way of having a more universal solution that could be plugged into any project and also have logic within to work across windows, containers, etc.

[Keith_Culotta]

I think this code would be the logic, but it does not help things. It looks like the Tab key gets processed by the window anyway. Is there a way to supress a keystroke?

Also, a non-focusable button keeps getting the focus, with or without this method. So, I delete this button and replace it. Now another button has adopted the role of getting the focus when it’s not supposed to.
Also, the tab order and focus settings of this button shown in the debugger match the settings in the IDE. They are just getting ignored.

// Private Sub TabOrder(LeavingName as string, keyDown as String)
// put names of objects to be controlled by this method in the space-delimited nameString below
// put this method in objects' KeyDown events: TabOrder(Me.Name,key)

// Containers don't have a Name? 
// Var hasShift As Boolean=Keyboard.AsyncShiftKey  // Shift key not seen when TAB & Shift down, Shift/Tab works anyway

If keyDown=Chr(9) Then
  
  Var nameString As String = "Search_ID Search_Category Search_Name Search_PlainText DataList CardCat CardName"
  Var names() As String = nameString.Split(" ")
  Var NextControl As DesktopUIControl
  Var EControl As Object
  Var pos As Integer = names.IndexOf(LeavingName)
  
  If pos <>-1 Then 
    pos=If(pos=names.LastIndex,0,pos+1) // next control
    For Each EControl In Self.Controls
      If EControl IsA DesktopUIControl Then
        NextControl=DesktopUIControl(EControl)
        If NextControl.Name = names(pos)  Then // if this is the next to get focus
          NextControl.SetFocus 
          Exit
        End If
      End If
    Next
  End If
  
End If

[Patrick_Salo]

Within your KeyDown event, you need to…

Return True

…for the Tab and/or Shift+Tab, otherwise…

Return False

The docs explain this the best:

Returning True means the key is intercepted, preventing the key from actually reaching the control at all. This would be useful if you want to override the behavior of the tab key for example. Returning False means the key reaches the control.

[Emile_Schwarz]

@Keith_Culotta

78428

You wrote that Focus disappears, but you forget to mention the used OS you’ve seen that. The documentation said for DesktopTextArea:

AllowFocusRing As Boolean

If True, the control indicates that it has the focus with a ring around its border; if False, the appearance of the control does not change when it has the focus.

Important

This property is not supported for Linux or Windows.

NB: I am on macOS and the Focus ring does not appears in a DesktopTextArea… that have Allow Focus Ring in design mode.

Have you tried:

[Arnaud_N]

@Patrick_Salo

The only reliable workaround that I’ve found, that’s quite a PITA especially if you have lots of controls, is to capture the KeyDown event, check for a Tab and Shift+Tab, and manually place the focus.

So I’m assuming you tried the window’s FocusNext and FocusPrevious methods, and they don’t help.

[Beatrix_Willius]

What is wrong with editing the tab stops directly?

[Emile_Schwarz]

I prefer using the menu or the button:

[Keith_Culotta]

Thanks for the suggestions. I tried them again, but the strange behavior is persistent.

Auto-adjust Tab order buttons:
Horizontal: leaves some fields out of the travel order
Vertical: leaves different fields out of the travel order

Tab Stops and Tab Index set in the Inspector or by the View list, seem to get ignored in some fields, but not others.

In either case a non-focusable button gets the focus at some point and some fields will get visited once, but not again.

All settings changes have an effect on the travel of the cursor, but the underlying bug still has precedence.
The bug does not affect shift-tabbing. That travels in the expected order.

[Emile_Schwarz]

@Keith_Culotta

Auto-adjust Tab order buttons:

Of course !

NB: I never had seen the problem you’re reporting.

Btu, if the Control #25 is set now to #12, something is done in the background and if you code using these (how ?), you are having troubles.

And there isalso the case where, in KeyDown Event, you add something like:

If Key = Tab Then
  // Something like “Go to ControlName
  // and ControlName ID is not the next one
  ControlName.Focus = True
End If

Go Figure !

If I recall properly, a Text Entry Control (TextField for ex.) prevals on a Non Text Entry Control (Vanvas for ex. when you give focus. How Xojo deals with that?)

[Patrick_Salo]

In my experience these DesktopWindow methods also don’t function properly when this bug is present.

[Keith_Culotta]

Here is a sample that acts up for me. Others may have a different experience?

The Tab Order is not set in any particular way, but I see different travel paths when Tabbing and Shift-Tabbing.
Different fields get skipped when Tabbing than when Shift-Tabbing and some will get skipped only after the first tab cycle.

The combination of macOS 15.3.1 and Xojo 2024 4.2 may be a problem?

20250212_TabTest.zip (10.5 KB)

[Emile_Schwarz]

This is a macOS behavior.

It would be good to set the focus order from top to bottom or to told us what you expect.

The focus must follow this order (from top to bottom:

If yuou want your DesktopBevelButton get the Focus, change the behavior inacOS OR set it able to receive text. As you use it, they are in the DesktopPushButton and cannot get the focus…

Is it possible to have TWO DesktopSearchField in the same Window ?

Lbel5.Height = 176: there are objects in that area. None of them can be edited: the text cannot be changed. Why do you want to place the curse-or there with tabs ?
I’m also on Xojo 2024r.4.2 / Sequoia (last).

I must stop here because I do not have a good vision now. Maybe tomorrow it will be better… (I cannot see the MouseCursor.

BTW: Container1 will never have the Focus (it is False, and one of the TextEdit too.

This looks like a demonstration of how bad a software is vs there is something wrong.
A good compare is… You lock a file in the FINDER, SELECT IT AND SOME OTHERS, create a zip, then complain the locked file is not in the archive.
Variant: you move the file to the trash ans complain you cannot delete ALL the files.
In both cases, the solution is to unlock the file.
I am awaiting tomorrow to read what the Forum people have to say on the matter.

I loaded the binary project, not the text version (if that matters).

Have-you tried this feature:

I cannot type anything in the controls that are in Container1 even after allowind it to get the focus and allow focus ring = True.

Label.Caption is ReadOnly. You do not even made them selectable, so you cannot copy its value. There is no Focus Property in Caption.
Are you searching bugs ?
or…
Do you want to reach bugs ?

It is your use, but I think it is not kosher at all.

Good night.

[Patrick_Salo]

At least to me, your example mirrors the tab bugs that have been reported. Also to your question on macOS & Xojo combinations, in my experience this goes back many years of Xojo and many macOS versions. I also can replicate the problem in Windows 11 and IIRC Windows 10. My guess is that it’s some kind of Xojo framework bug.

IMHO this is either the same bug or set of bugs where I had to implement this KeyDown workaround back in REALbasic (or was it Real Studio?) 15+ years ago now. So either the bugs have remained or they got fixed and these are recent regressions over the last couple of years.

[Emile_Schwarz]

I checked the ID for the TextArea from the Container, and it was 0.
TextFoeld2 also have an ID=0.
So, I changed the TextArea ID and now we can access it while running the application.

[Keith_Culotta]

I did not know that buttons do not get the focus, but I’m OK with that, being a Mac user. However, I would not have suspected it because I have a layout with a bevel button that does get the highlight (when tabbing in the forward direction).

I am trying to reach bugs, to learn where things break, and to figure out how to recover. The example I sent is wonky because I was using it to learn about the behaviors of several different things.

Attached is a trimmed down example that works when tabbing in the forward direction, but is broken when shift-tabbing. TextField1 gets skipped when shift-tabbing. That seems beyond the control of the available settings.

The main form in my production app is more complex and the odd tab behavior is more apparent. I have not stumbled on a way to adequately shield the user from that. So I’m hoping that a fix for the simple layout, either at my level or at the Xojo level, will apply to more complex layouts.

20250221_TabTest.zip (18.4 KB)