Important: Please read the Qt Code of Conduct -

Showing widgets on Tab and/or button

  • Hello,

    I'm looking for a way to create a widget that displays input controls, let's say line edits. But to simplify it for the users, I don't want to show all of them since only a couple are relevant and others are optional. What I'd like is to initially show all the mandatory fields and then a small button saying "more >>" that would display other fields. I think there was a Qt example with such a functionality but I can't find it at the moment.

    But, along with the button, I would like to also show the remaining widgets when the user presses Tab key on the last mandatory line edit. So the program works in such a way that: widget with 3 line edits and a "more >>" button is displayed (Save and Cancel too of course), focus is on LineEdit_1. User fills in the data, presses tab to switch to LineEdit_2, data, tab, LineEdit_3, data. Now, if the user presses tab again, the widget is extended and a couple of more line edits are shown.

    Any good ideas on how to do it?

  • Hi,

    its the "Expandable dialog example":
    You could derive your button and check,whether the the focus is set there by tab and call expand...

  • Thanks, that's the example I was looking for!

    As for tab - I'd rather not have focus on the button using tab, direct focus switch from the last initially visible line edit to the first one that is hidden is what I'm after.

    But the idea is quite good, thanks! I think I could subclass the last line edit and reimplement QWidget's focusOutEvent, check for reason() == Qt::TabFocusReason and if so, show the extension widget and set focus to the first edit there.

    Correct me if I'm wrong here.

  • That is also a possibility, but I would overwrite keyEvent, not focusOut.

  • Any reasons for that? Faster, more elegant?

  • Then you can catch the key on it's source, emit a signal that can show the new widgets and then set the focus directly to the needed widgets. If you do it on focusOut, the focus already went to another widget (perhaps the button??).
    From my opinion, that is a more clear solution, as you want to react on a key event, not on a focus event. The focus is the result, not the reason, isn't it?

Log in to reply