wrong tab order

[django.Reinhard]

Hi,

recently I reported problems with hidden fields. This time I have issues with visible (and enabled) QLineEdit (highlighted with red border) which has the focusPolicy set to "NoFocus".

When the widget arises to become visible, I set the focus (prgramatically) to LineEdit #1
Hitting tab-key advances focus to combobox (#2) and then it needs two tabkey presses to reach LineEdit #3.
I wanted to know, where the focus went to and tested cursor keys. It appears, that the notebook tabs receive the focus between combobox and LineEdit #3

This is the screenshot from QtCreator:

Any idea for workarounds are very appreciated.

[Thank You]

@django-Reinhard said in wrong tab order:

When the widget arises to become visible, I set the focus (prgramatically) to LineEdit #1

Can you post code how you did it?

[Christian Ehrlicher]

Works fine for me with 5 simple QLineEdits in Qt5.15

[django.Reinhard]

@Thank-You said in wrong tab order:

Can you post code how you did it?

I was unprecise :(
This editor sets the focus at enable (it is disabled by default and will be enabled on start editing)
I show the code anyway:

void ToolEditor::changeEvent(QEvent* e) {
  if (e->type() == QEvent::EnabledChange && this->isEnabled()) {
     ui->eName->setFocus();
     }
  }

... but with a different editor I use the raising into visible state like this:

void FixtureManager::showEvent(QShowEvent* e) {
  DynWidget::showEvent(e);
  qDebug() << "FM: show Event ...";
  if (e->type() == QEvent::Show) activateEditor(0);
  }

@Christian-Ehrlicher said in wrong tab order:

Works fine for me with 5 simple QLineEdits in Qt5.15

Thank you for your attention and your time!
I just updated my repo.
If you'd like to risk a look:

my project
above editor

[Christian Ehrlicher]

Provide a minimal, compilable example with 3 simple QLineEdits so we can see what you're really doing.

[django.Reinhard]

Hi Christian,

@Christian-Ehrlicher said in wrong tab order:

Provide a minimal, compilable example with 3 simple QLineEdits

Why should I repeat a test you already did?
I believe you.

@Christian-Ehrlicher said in wrong tab order:

we can see what you're really doing.

I you really want to know, what I am doing, than you have to look at my repo.

The point is, you have proven, that it won't happen on small samples. Nevertheless I have the described effect and I don't fiddle with tab-order on my own.

So it may be, that the effect is related to the random order that QtCreator uses on xml-creation? I don't know.
Maybe that tab-processing is not that rocksolid than you believe?

I would be happy if you could show me, that I did something wrong. Than the fix would be easy.
But I fear, this time its no me

[SimonSchroeder]

@django-Reinhard said in wrong tab order:

I you really want to know, what I am doing, than you have to look at my repo.

I you really expect someone to help you it is standard courtesy that you provide a minimal compilable example which reproduces your errors. Otherwise we have to guess instead. This is how forums where people voluntarily help work.

[Christian Ehrlicher]

@django-Reinhard said in wrong tab order:

I you really want to know, what I am doing, than you have to look at my repo.

No, you want a behavior fixed so you must provide a simple way to reproduce the issue or go on your own - I won't dig through hundreds loc to do your work.

[Thank You]

@django-Reinhard
My brother is talking like we are working for him brother 🤣🤣🤣
and he is boss
LOL
None here gets money for answering LMAO

[django.Reinhard]

I'm not here to be reminded of etiquette by some currant poopers or to be told that you don't get paid. This is ridiculous! After all, I work in the same context.

With my post I had two goals in mind: once I wanted to report that there is a problem. For the Qt developers. After all, you don't know there's a site until someone comments on it.

The second aspect was that I was looking for the exchange with other experienced developers. In this exchange, every (serious) guess is welcome.

@Christian-Ehrlicher said in wrong tab order:

No, you want a behavior fixed so you must provide a simple way to reproduce the issue

At no point did I expect anyone else to solve my problems.

My time is as precious as yours, so if you have already proven that the problem does not occur with a small program, why should I invest time to get the same result?
Some effects only appear at a certain level of complexity.

Ignoring that does not prevent it from happening.

[VRonin]

Can we all be nice and respectful please?

Some effects only appear at a certain level of complexity.

I agree, unfortunately the problem for us is that it's impossible to reproduce such level of complexity. Christian tried with a basic one but the problem wasn't there

Provide a minimal, compilable example

The Minimal, Reproducible Example is the common way of saying "can you give us some code that we can run and shows the problem so we can work on what's going wrong". The "minimal" part just means "the lesser lines of code the better".

[django.Reinhard]

You're right.

By exchange with developers, I also mean an exchange at eye level, without being taken for stupid right away.
Of course I make mistakes - I have no problem admitting that. On the other hand, if it's unlikely that it's me, I would be very happy if I could get a tip regarding Qt. Something like: have a look at this or that function.

I've specially compiled myself a Qt version with debug info, so I can also dive into Qt in a meaningful way.

Especially with the events and keystrokes it is very hard to find an access on my own. Often the keystrokes don't even make it to my classes.

Qt is huge. Much bigger than my app. So to have a minimal chance to find something meaningful, a tip from experienced developers would be more than appreciated.

Again: At no point did I expect anyone else to solve my problems.

... but some hints or serious guesses are welcome :)

[VRonin]

@django-Reinhard said in wrong tab order:

Something like: have a look at this or that function.

Oh, then even better. The magic of tab ordering happens inside QWidget::focusNextPrevChild. Not super helpful, I know, but it's a starting point I guess

[django.Reinhard]

Thanks a lot!

Although I found that function at the same moment, this kind of hint is Super helpful!

I guess, the source of different behaviour is that "wrappingOccurred"-flag.
I guess, with minimal examples like chris` one no wrapping will happen. In my case, where the ui-file is some kind of bigger and muddle-headed the wrapping will happen - and in that case, the widget might decide to route the tab event to its parent, which then activates the notebook tabs.
Just a guess - far from proven!

I'll try to overwrite that function. May be I can solve the hidden fields issue as well.

Thanks you very much again for your time and your support!

[django.Reinhard]

So, the matter is settled :)

When I found the function, I was not sure if I had found the right approach. Fortunately I then read your tip - and could get started

I had always intended to make the editors so that you can't tab out of an editor. But I didn't know how.
Now the whole thing was a piece of cake:

bool ToolEditor::focusNextPrevChild(bool next) {
  QWidget* w = focusWidget();

  if (w != QApplication::focusWidget()) return false;
  int i;

  // find focus widget in edits
  for (i=0; i < edCount; ++i) if (tabOrder[i] == w) break;

  if (next) {
     do {
        if (++i >= edCount) i=0;
        } while (tabOrder[i]->focusPolicy() == Qt::FocusPolicy::NoFocus
             || !tabOrder[i]->isVisible());
     tabOrder[i]->setFocus(Qt::TabFocusReason);
     }
  else {
     do {
        if (--i < 0) i = edCount - 1;
        } while (tabOrder[i]->focusPolicy() == Qt::FocusPolicy::NoFocus
             || !tabOrder[i]->isVisible());
     tabOrder[i]->setFocus(Qt::BacktabFocusReason);
     }
  return true;
  }

Just for completeness: Editor-Form written by QtCreator

P.S.: the issue with hidden fields is fixed by this method too :)

[JoeJoe_000]

Hello your issue might be because you have something other than NoFocus set in the focusPolicy property. Set it to NoFocus and you should be good to go, no need to code for this fix.