QStackedWidget to QDialog

wasawi2

Hi everyone,

So I have a QStackedWidget with two pages, I have them in a qt designer form. This allows me to read the state of the objects at the first page from the second page. In fact, when it comes to coding, they are all at the same place, I just need to do:

ui.widgetAtPage1.setOrGetProp();
ui.widgetAtPage2.setOrGetProp();

This is very useful because i can read/write in any widget from any page at any time.

Now I wanted to have my page1 in a modal dialog instead of the stacked widget for some important reason. The problem is that there are many places in my code where i read the state of the objects at page1 from page2. As far as I understand, If I use a QDialog I will have to write a new class with a new qt designer form containing all the widgets that were previously at page1. The question is how to read/write the state of the widgets at the QDialog from my main window and vice versa? Why implementing this UI change will completely change the structure of my code?

Is there a way to access the QDialog form from my main window like before? eg:

MainWindow::someFunction{
uiD.widgetInDialog.setOrGetProp();
uiMW.widgetInMainWindow..setOrGetProp();
}

Thank you,
w

JonB

@wasawi2
There are several points/questions here, and I'm not sure what you are looking for or understand.

An individual widget instance cannot be "in two places at once". If you have a "page" widget on a QStackedWidget it is there, any cannot be on a QDialog as well; similarly, a QStackedWidget can only be on one window/dialog. You either have to create a quite separate instance to put elsewhere, or possibly you could move the widget to the new place, but then it's not in the old place, unless you move it back.

You also cannot copy any widget. You have to create a new, separate instance. And if you want to get settings from one instance to this new one you have to write to copy whatever you want to take across.

You can access one widget from another, e.g. a QDialog from a QMainWindow, if you wish. Because widget members are private to the class they are in (e.g. in Designer-generated code) you have to export something publicly to achieve that, usually best achieve by writing public getter/setter methods. But this does not obviate the issue about which instance of a widget you are accessing.

P.S.
If you want to create two separate instances of a widget, such as your "page" so as to have one for the stacked widget on your main page or wherever and one on your dialog, you do not have design the same widget twice in Designer. You can design it once and at runtime create two instances, one for each place. You would still have to copy across anything/its settings/contents if you want them to be the same, but you can re-use the design.

Pl45m4

@wasawi2 said in QStackedWidget to QDialog:

Now I wanted to have my page1 in a modal dialog instead of the stacked widget for some important reason. The problem is that there are many places in my code where i read the state of the objects at page1 from page2. As far as I understand, If I use a QDialog I will have to write a new class with a new qt designer form containing all the widgets that were previously at page1.

If you want to do most of your UI in Designer, then yes.
Remove the composed Page1 widget from QStackedWidget and create the same content for your custom QDialog UI.

The question is how to read/write the state of the widgets at the QDialog from my main window and vice versa? Why implementing this UI change will completely change the structure of my code?

Depends on how you treat your dialog. You can access it with set/get functions, you add to your dialog code, as @JonB mentioned.
Or you could write signals to send something to you dialog and process the data in there (add to the widget where it should be), because accessing the UI from other widgets directly is somewhat not optimal and not the best design.

If you keep it as member of your QMainWindow, it keeps the current state until you delete the instance.
If you show a new dialog every time, the dialog as well as all the widgets will have the default state.

@JonB said in QStackedWidget to QDialog:

you do not have design the same widget twice in Designer. You can design it once and at runtime create two instances, one for each place

I assume @wasawi2 is referrring to the composed page widget in QStackedWidget, where you just drag your widgets in and set a layout. So this all becomes one widget first, when being part of QStackedWidget.
Therefore I think, it's difficult to "export" it to some dialog (except copying the layout in Designer and inserting it to some dialog.ui).
Also, I don't think you can create another instance of this composed widget just like that?! (never tried, though)

JonB

@Pl45m4 said in QStackedWidget to QDialog:

I assume @wasawi2 is referrring to the composed page widget in QStackedWidget, where you just drag your widgets in and set a layout. So this all becomes one widget first, when being part of QStackedWidget.

If you do that you will not have a class which can be re-used elsewhere. So although it is convenient it may not be great for the OP's case. The OP can design a standalone page in Designer and then put an instance of it into the stacked widget (and another instance into the dialog) at runtime. Not as user-friendly, but better for re-use.

Pl45m4

@JonB said in QStackedWidget to QDialog:

If you do that you will not have a class which can be re-used elsewhere. So although it is convenient it may not be great for the OP's case

This is what the current state is here.

The OP can design a standalone page in Designer and then put an instance of it into the stacked widget (and another instance into the dialog) at runtime

Can :) But I think @wasawi2 was asking how to transition from QStackedWidget with the composed page widget, which was put togehter in Designer, to a QDialog that contains the same widgets (i.e. the composed "page") in a layout.
Designing a new, plain QWidget in Designer to be able to create multiple instances in your code, when you solely want to add it to your dialog, makes not sense to me and would require more steps than needed.

Edit:

Not as user-friendly, but better for re-use

But, yeah :) As usual, depends on the use-case and what kind of content we are dealing with and what @wasawi2 is going to do

JonB

@Pl45m4 said in QStackedWidget to QDialog:

But I think @wasawi2 was asking how to transition from QStackedWidget with the composed page widget, which was put togehter in Designer, to a QDialog that contains the same widgets (i.e. the composed "page") in a layout.

I did not read it that way. I thought the OP wanted it on a dialog in addition to being on the stacked widget elsewhere. Your reading may be correct, in which case some of my observations may not be appropriate.

Pl45m4

@JonB said in QStackedWidget to QDialog:

I did not read it that way. I thought the OP wanted it on a dialog in addition to being on the stacked widget elsewhere

@wasawi2 said in QStackedWidget to QDialog:

Now I wanted to have my page1 in a modal dialog instead of the stacked widget for some important reason

:)
The "instead" makes me think, that OP wants to move it from QStackedWidget to a separate dialog, not showing the content at both places.

Haha all good, I'm not saying you are wrong :-)

wasawi2

Thank you very much @JonB and @Pl45m4.

@Pl45m4 said in QStackedWidget to QDialog:

The "instead" makes me think, that OP wants to move it from QStackedWidget to a separate dialog, not showing the content at both places.

That is correct. I wanted to get rid of the stackedwidget, then I would have one QDialog for what was page1 in stackedwidget, and page2 just in a layout in my mainWindow. The main question is how to do that transition in the cleanest way possible. Let's say i had 10widgets in my page1 and I was able to read/write in them from my MainWindow by doing:

ui.widget1AtPage1.setOrGetProp();
ui.widget2AtPage1.setOrGetProp();
ui.widget1AtPage2.setOrGetProp();

That was very convenient and easy. Now if I move page1 into a QDialog which is a member of my MainWindow see myself forced to write getters and setters or signals and slots every time i need to read/write from one to another. That is what i wanted to avoid. So the question is if there is a way to write the QDialog instance so that i have access to its members anytime (even if its closed), and access from the dialog to the MainWindow's members without signals and slots.

I guess it is a very basic question but I'm surprised to see that this change would imply a sever modification in my code. Is it because I'm using the Designer? would it be cleaner by rewriting everything without it?

JonB

@wasawi2

That was very convenient and easy.

Sorry, but that doesn't make it the "right" way to do this. You want to export every widget from a UI class so that the outside world can access it directly, reading and writing. Yes, Designer makes sure the ui class is private precisely so you don't try to do this.

Now if I move page1 into a QDialog which is a member of my MainWindow see myself forced to write getters and setters or signals and slots every time i need to read/write from one to another. That is what i wanted to avoid. So the question is if there is a way to write the QDialog instance so that i have access to its members anytime (even if its closed), and access from the dialog to the MainWindow's members without signals and slots.

You are not supposed to do this, even though you consider it advantageous. Yes, you should write getters/setters on the containing widget and you should use signals/slots if appropriate. Yes you may have to move code around if you happen to change what page widgets are on. Equally your way code would have a hard dependency on a particular widget and its variable name in another UI class.

Up to you whether you take this design advice or pursue the way you want to do it.