Initialising a dialog with the MainWindow pointer

[feraudyh]

Hello,
In my application which has a MainWindow, I allocate a whole lot of Dialogs and for each of these, I want to have a m_mainwindow pointer of type MainWindow *.
Now when I make a dialog via the wizard add new > Qt > Qt Designer Form class
it creates a constructor for the dialog which takes an argument of type QWidget *, when in fact this QWidget pointer is going to be passed my MainWindow pointer. So I end up defining a method of signature void init(MainWindow *) for each of my dialog. It kind of feels like a waste to have to define an extra method when I have passed the MainWindow (albeit as
a QWidget in the constructor).
I dont like the idea of dynamically recasting the QWidget pointer to a MainWindow pointer in the constructor.
I am wondering about whether it is possible to change or configure the wizard that gets called when I add a new Qt Designer Form Class.
Should I be looking into adding a new Template for the wizard?

[d_stranz]

Aside from the fact that what you are proposing almost certainly is a case of bad design (TM), and that you should instead be thinking in terms of "What kinds of signals and slots do I need to implement for MainWindow and my dialogs so they can communicate the right information between themselves", the Qt wizards are simply a tool for generating boilerplate C++ and UI code that you then modify to flesh out the classes.

Open the cpp and h files in the code editor and just replace QWidget * with MainWindow * in the constructors (or add them as additional arguments). There's no magic here. You'll probably need to add a forward declaration ("class MainWindow;") in the dialog .h file unless you add a #include for MainWindow.h to avoid an undefined type error during compilation.

[feraudyh]

Thankyou d_strantz for replying with a clear answer.
I worked for a company that had a design style where there was a "central" object that owned all the shared services like the database connection, and objects would ask this one directly for the services.
I'll consider the idea that dialogs etc do not know where information is stored, they just emit signals saying "i need this kind of information" and the connections created (for example in the MainWindow) decide who shall supply what information.

[d_stranz]

I'll consider the idea that dialogs etc do not know where information is stored, they just emit signals saying "i need this kind of information" and the connections created (for example in the MainWindow) decide who shall supply what information.

That would be an excellent choice. Even if there is a "Master of the Universe", using signals and slots can hide all of that. You might also think about the idea that the MainWindow might not be the master either - it could create a master object, and connect the dialog signals and slots to that object instead of handling them itself. That will help give you a system where all of the business logic is as separate as possible from the GUI logic so that changes in the GUI will not force you into a redesign of the business logic.