Refer to an interface object name with a variable (string)

[anda_skoa]

See documentation for QList and QVector.

Cheers,
_

[d_stranz]

Creating the line edits by code would get too complicated for me, I'm using a few stacked widgets.

As wysota and others have said, if you don't want to create the widgets in code, you can still retrieve their pointers and store them in a list or vector:

// In the constructor for each widget in the stack:
 
ui->setupUi( this );
 
pVector = new QVector< QLineEdit * >( 100 );
 
pVector[ 0 ] = ui->t000;
pVector[ 1 ] = ui->t001;
// etc. for the next 98 line edits
 
// Then, you still retrieve the text for each widget using the vector
 
t[n] = pVector[n]->text().toDouble();

// In the constructor for each widget in the stack:

ui->setupUi( this );

pVector = new QVector< QLineEdit * >( 100 );

pVector[ 0 ] = ui->t000;
pVector[ 1 ] = ui->t001;
// etc. for the next 98 line edits

// Then, you still retrieve the text for each widget using the vector

t[n] = pVector[n]->text().toDouble();

To copy to clipboard, switch view to plain text mode 

Edit: You could avoid the cut-and-paste if you are consistent in your names for the line edits. You can then use findChild, as Lesiok suggests:

pVector = new QVector< QLineEdit * >( 100 );
 
for ( int i = 0; i < 100; i++ )
{
   QString name = QString( "t%1" ).arg( i, 3, '0' );
   pVector[ i ] = findChild< QLineEdit * >( name );
}

pVector = new QVector< QLineEdit * >( 100 );

for ( int i = 0; i < 100; i++ )
{
   QString name = QString( "t%1" ).arg( i, 3, '0' );
   pVector[ i ] = findChild< QLineEdit * >( name );
}

To copy to clipboard, switch view to plain text mode 

This assumes the line edits are named "t000", "t001", ... "t099".

[wysota]

Just remember, despite having to write less lines of code to use findChild this is actually slower to execute than 100 copy&paste of the manual code that retrieves a single pointer. So all in all it is a matter of balance between the number of lines of code you have to write (once) and the amount of code that needs to be executed (every time you run your app).

[guiismiti]

Just remember, despite having to write less lines of code to use findChild this is actually slower to execute than 100 copy&paste of the manual code that retrieves a single pointer. So all in all it is a matter of balance between the number of lines of code you have to write (once) and the amount of code that needs to be executed (every time you run your app).

Yea, I thought about that.

I had the code written and ready just before I started the thread, but in my honest opinion I don't really like the idea of doing this kind of manual job when it can be avoided.

I said I have 100 elements but I actually have 3 stacked widgets with 100 each - but that doesn't affect anything, so I decided to make it simple to present the problem. All elements are essential to the app - they are results of a laboratory experiment that must be informed as float (or double, I don't really know the difference).

I haven't got much time right now (couldn't even open Qt today ), but I think that the list is the best option for me.
But still, does anybody know what's wrong here? I'm trying to use findChild. I have tried to use parentWidget instead of centralWidget, but no difference.

QLineEdit *lineedit = centralWidget->findChild<QLineEdit *>("t01");

QLineEdit *lineedit = centralWidget->findChild<QLineEdit *>("t01");

To copy to clipboard, switch view to plain text mode 

The error message I get is this

'->QObject::findChild' : left operand has " type, use '.'


Edited: This may be helpful

structure.png

[d_stranz]

Perhaps you need ui->centralWidget->findChild< QLineEdit * >( "t01" ) ? The compiler is probably complaining about the dereferencing because it can't find a variable named "centralWidget" in the current scope.

And you probably don't want to use centralWidget in any case - findChild will get only the first of the QLineEdit widgets it finds with a matching name in one of the stacked widgets, probably the first one in the stack. (Assuming that the line edits on each page have the same names - eg. "t01" is the first line edit on each page). You will want to retrieve each set of 100 from each stacked widget separately and store them in three separate vectors / lists.

[guiismiti]

Assuming that the line edits on each page have the same names - eg. "t01" is the first line edit on each page

Not the case - it's tn for time, vn for volume and cn for concentration.

[d_stranz]

Not the case - it's tn for time, vn for volume and cn for concentration.

Then you're lucky Even so, I would still retrieve the line edit pointers from their most immediate parent (eg. the individual page widgets inside the stack widget).

It's an encapsulation thing. The main window (and indeed, the rest of your app) doesn't need to know that there are 100 line edits buried down on a page somewhere in a stack widget. What it needs to know is when the array of time values has been updated. What I would do in that case is to keep all the code that retrieves the line edit pointers and keeps track of when the user changes things encapsulated within the parent widget that contains the line edits. When the user changes a value, you update it in the vector or list (which is held by the parent widget containing the line edits), and then emit a custom signal ("timeValuesChanged( const QVector< double > & )" ) with the new array of time values. Likewise volume and concentration.

This way, you can do whatever you want to change the widgets inside the stack, the only thing the main window will know is that it should expect a signal like that when the values change. You could even substitute an object that reads time, volume, and concentration values from a file (or sensor array), and as long as it emits the same signal, the app won't know the difference.

[wysota]

I said I have 100 elements but I actually have 3 stacked widgets with 100 each - but that doesn't affect anything, so I decided to make it simple to present the problem. All elements are essential to the app - they are results of a laboratory experiment that must be informed as float (or double, I don't really know the difference).

I would have a configuration file (e.g. xml) that would list all the parameters and at runtime I would read the file, create the widgets based on it and so on. Should be really easy. If at any time you decide to modify the widgets, it is enough to modify the configuration file and the program will follow.

[guiismiti]

Things seem to be working fine right now.

Although, I've got this little problem going on with the interface - the first page of the stacked widget is always fully displayed, but all the others are not (like in the images). It doesn't matter which is the first page, all the other ones will be like in the second image, with a huge gray square on the right side.

Here is the first page:
01.png

Here is the second page:
02.png

Please let me know if you need any more info.


Again, thank you very much, I really appreciate it.

[anda_skoa]

Does each page widget have a proper layout?
Is the stack widget part of a layout?

Cheers,
_

[guiismiti]

The size of each page is the same, 711x366.

stackedWidget is part of centralWidget.

I just measured the app window in pixels, and it looks that something is reducing the pages (except the first page, like I said) to have 640 pixels of width.
Not sure if I was clear, but the first page is always the selected one when compiling the program - so, it is gonna be the only page that is fully displayed.

Here is centralWidget configuration:
centralwidget.jpg

And here is MainWindow (centralWidget is under MainWindow):
mainwindow.jpg


Edited: I just tried bringing stackedWidget to front, didn't work.

Edited #2: I also tried to change the app width to 1000 px, it is still cutting everything inside the window to 640.

[wysota]

You were asked a simple question -- whether your pages have a layout set on them. If you do not know what a layout is then just say so or look it up in the docs.

Layout Management

[guiismiti]

no
10char10char

[wysota]

no

Now you know your problem and you can fix it easily by applying a layout to each page and also putting your stacked widget in one.