Is there any method of referencing each of the controls on a form?

[Kent-Dorfman]

yes. look at the docs for QWidget. Then look at layout().

[Chris Kawa]

const auto combos = yourFormWidget->findChildren<QComboBox*>();
for (auto combo : combos)
{
    //do stuff with combo
}

[JonB]

@Alexandre-Camelo
@Chris-Kawa's findChildren<QComboBox*>() is indeed the neatest way to pick up just one class of children, like QComboBox.

FYI, if you later find you want to do things to different child classes, instead of writing multiple findChildren<SomeSpecificClass*>() you can alternatively follow pattern [EDIT but see @Chris-Kawa's responses below]:

const auto widgets = yourFormWidget->findChildren<QWidget *>();
for (auto widget: widgets )
{
    QComboBox *combo;
    QLineEdit *line;
    QPushButton *button;
    ...
    if ((combo = qobject_cast<QComboBox *>(widget)))
        ...
    else if ((line = qobject_cast<QLineEdit *>(widget)))
        ...
    else if ((button = qobject_cast<QPushButton *>(widget)))
        ...
}

[Chris Kawa]

@JonB It's unlikely there are a lot of combo boxes so it should be ok to use findChildren() for that, but I wouldn't use that for a plain QWidget. It will do a lot of tests that you already know will pass, because usually most of the children objects are widgets.

For that case I would go with plain children() (recursively if needed), which would result in a lot less copying and testing.

Also the pattern you proposed is not really good - you should do casts only if the previous ones failed, not all of them beforehand. Keep in mind that any dynamic casting is relatively expensive so you should try to do as little of it as possible.

[JonB]

@Chris-Kawa
I was trying to show a way of doing a single-pass findChildren(). Whether there are many or few QCombBoxes is not the issue, it's if there is a large hierarchy to visit I didn't want to recurse more than once. If there are 100 descendants, of which 1 is a combo, 2 are lines and 3 are buttons, it offends my sensibilities to do 3 separate descents through the tree of 100. (I don't think findChildren<>(QComboBox*) has any internal quicker way of picking them out other than looking at every descendant, does it?) Horses for courses.

The pre-casts at the top were to make the code shorter as an example, yes in practice I would only do qobject_casts as necessary as the ifs unfurl. [EDIT I have now rewritten that bit to remove unnecessary pre-casts.] Similarly using children() would have meant showing the necessary recursion, and I wanted to keep it short.

I maintain this is a useful principle for the OP to at least be aware of as an FYI, but he should respect your comments about efficiency.

[Chris Kawa]

@JonB said:

it offends my sensibilities to do 3 separate descents through the tree of 100

Fully agreed. What I meant was that findChildren does the tree traversal and casts each object to the type you give it (QWidget here). It then copies them out to a list and then you traverse it again and do the casting to your target types. What I'm saying is in that case it's better to skip those casts and copying that findChildren() does and traverse the tree yourself without copying and do the target casts directly, without the QWidget cast mid-step.

[JonB]

@Chris-Kawa
You're right. I'm too lazy to write the necessary for a recursive children() example (I don't even do C++ these days!), so we'll leave that as an exercise for the potential interested reader ;)

[Chris Kawa]

I'm too lazy to write the necessary for a recursive children() example

<tin foil hat on> Admit it. You're just an alien lizard in disguise trying to drain our batteries so we can't look at cat videos on a long distance bus trips :)

[JonB]

@Chris-Kawa

<tin foil hat on> Admit it. You're just an alien lizard in disguise trying to drain our batteries so we can't look at cat videos on a long distance bus trips :)

Whatever that is reference to I'm afraid it's completely beyond me? :(

[JKSH]

@JonB said in Is there any method of referencing each of the controls on a form?:

@Chris-Kawa

<tin foil hat on> Admit it. You're just an alien lizard in disguise trying to drain our batteries so we can't look at cat videos on a long distance bus trips :)

Whatever that is reference to I'm afraid it's completely beyond me? :(

• Tin foil hat - The armour of choice for conspiracy theorists.
• Alien (from outer space) - A common subject among conspiracy theorists.
• Drain batteries - A consequence of a smartphone running inefficient code. Interferes with the smartphone's ability to play cat videos.
• Cat videos - One of the top productivity killers in today's society. Often consumed via smartphones.
• Long distance bus trips - A death trap for batteries that power smartphones that play cat videos. Can be counteracted by uber-modern busses that contain built-in phone chargers.

[JonB]

@JKSH
Errr, OK, but are you saying using a C-style cast will run out batteries?? ;-)

[Chris Kawa]

@JonB said in:

but are you saying using a C-style cast will run out batteries?? ;-)

Well, to play devil's advocate - kinda yes. A C-style cast in C++ is not the same as a cast in C. The compiler does some logic to determine which type of C++ cast to do underneath, so while the end result in the binary is the same the explicit C++ cast is cheaper in terms of compilation overhead (whatever microscopic amount that is). So if you're compiling on a battery powered laptop - yes, technically C-style casts in C++ will drain your battery more :D

[JonB]

@Chris-Kawa
To play devil's advocate back: please give me any (correct) example of where a C-style cast (compared to, say, static_cast<>()) could lead to battery-drain? Any example would do, I'm truly interested. Assuming you don't mean: a completely incorrect C-cast (like (int)some_struct or anything like that). Because I can't think of one....

[Chris Kawa]

@JonB It was a joke. We might end it here :) But I'll play along:

int a = 42;

float expensive  = (int)a;
float cheap = static_cast<int>(a);

The resulting binary and thus runtime performance are exactly the same. I meant compiler performance. (int)a makes the compiler check stuff to see which cast - const, static, reinterpret or some combination it needs to apply. Explicit C++ cast skips those checks so it's faster to compile. Again - It's not a difference that matters at all. It's extremely small so treat what I said as an (failed I admit) attempt at being funny. I bet glowing one pixel on your screen for a second takes more power than all the casts in your app.

[JonB]

@Chris-Kawa
Oh, you mean compile-time battery power? I thought you meant run-time.

(int)a makes the compiler check stuff to see which cast - const, static, reinterpret or some combination it needs to apply.

I could be wrong, but I think C-cast like (int)a always maps to static_cast<>(a), not the others.

Explicit C++ cast skips those checks so it's faster to compile

I'll make a little bet with you. Compiling a C-style cast in a C compiler will be faster than a static_cast<> in a C++ compiler. Not that I'm saying you were comparing against a C-only compiler. Based on nothing other than my suspicions :) But your point taken.

[Chris Kawa]

I'll make a little bet with you. Compiling a C-style cast in a C compiler will be faster than a static_cast<> in a C++ compiler.

I won't take that bet because I agree with you :) C is a lot simpler language to parse in general. Thinking about overload resolution alone leaves me no doubts that compiling the same code in C will always be faster than in C++. Again - talking about compile time performance, not runtime.

I could be wrong, but I think C-cast like (int)a always maps to static_cast<>(a), not the others.

It does in this case, but it needs to do the checklist anyway: explicit cast.
In case of something else, like const int foo = (const int)bar it will map to const_cast<const int>(bar).
I'm saying it's the logic to figure out which cast to use is the slow part.