pass ui to subclass

[phil333]

I would like to split up the code of my application into multiple classes, each class containing a dockwidget with its underlying functionality.

For that I would like to have access to the original "ui" from my mainclass, since the dockwidgets need to change functionality in the main window. How can I connect this?

I have managed to pass the "ui" to a function, but i cant figure out how to store it inside the new object.
Any other approaches to solve this problem are also welcome.

#ifndef SUBCLASS_H
#define SUBCLASS_H
#include <ui_mainclass.h>
 
namespace Ui {
class MainClass;
}
 
class SubClass
{
private:
    Ui::Ui_MainClass *ui;
public:
    DataGeneration(Ui_MainClass *myUi);
}

#ifndef SUBCLASS_H
#define SUBCLASS_H
#include <ui_mainclass.h>

namespace Ui {
class MainClass;
}

class SubClass
{
private:
    Ui::Ui_MainClass *ui;
public:
    DataGeneration(Ui_MainClass *myUi);
}

To copy to clipboard, switch view to plain text mode 

NewSubclass::NewSubclass( Ui_MainClass *myUi)
{
    qDebug() << myUi->tableWidget->rowCount(); // works
 
    ui = myUi // does not work
}

NewSubclass::NewSubclass( Ui_MainClass *myUi)
{
    qDebug() << myUi->tableWidget->rowCount(); // works

    ui = myUi // does not work
}

To copy to clipboard, switch view to plain text mode 

[anda_skoa]

For that I would like to have access to the original "ui" from my mainclass

You actually don't want to do that, you want to treat the "ui" pointer as an internal to the window it belongs to.

since the dockwidgets need to change functionality in the main window. How can I connect this?

They should ask the main window to manipulate its UI.

NewSubclass::NewSubclass( Ui_MainClass *myUi)
{
    qDebug() << myUi->tableWidget->rowCount(); // works
 
    ui = myUi // does not work
}

NewSubclass::NewSubclass( Ui_MainClass *myUi)
{
    qDebug() << myUi->tableWidget->rowCount(); // works

    ui = myUi // does not work
}

To copy to clipboard, switch view to plain text mode 

No error so the guess is: because ui and myUI have different types?

Cheers,
_

[phil333]

Thank you for your answer.

I think I will try to instantiate the dockwidget inside the main window and then just pass a pointer. But that doesn't solve the issue that I have to access differentiates inside the main ui from the feedback i get inside the dockwidget. I like the idea of not letting subclasses touch the main ui directly, but i ll have see how easy this is in practice.


The code above compiles, but it crashes when it gets to the "ui = myUi" line.

[d_stranz]

solve the issue that I have to access differentiates inside the main ui from the feedback i get inside the dockwidget.

A fundamental building block of all Qt programs is the use of signals and slots. Every Qt class that derives from QObject supports them. Many of the built-in Qt classes have signals and slots that they use to 1) communicate changes in their state or notify about the availability of data they hold (signals) or 2) react to changes signaled by some other Qt object (slots). The real power behind signals and slots is that you aren't limited to the one Qt provides as built-ins; if you derive your own custom class from some other QObject-based class, you can add your own signals and slots to do whatever you want them to do.

As anda_skoa said, your dock widgets absolutely do not need pointers to your main window's "ui" instance. Your dock widgets don't even need to know that there is a main window. What they need to know is that if (for example) the user can do some action inside them that the outside world should know about, they should emit a signal that says "Hey, the user did X". Note that it doesn't matter how the user managed to do "X" - she could have clicked a button, turned a dial, slid a slider - that's a detail the dock widget knows about and no other class (including the main window) needs to know.

So, now you have a signal that your customized dock widget emits when the user does "X". Your main window wants to know about that, so you write a slot for your main window that handles what should happen when the user does "X". Now, at the point where you construct your dock widget (maybe in the MainWindow constructor), you make a connect() call to connect the dock widget's "heyGotAnX()" signal to the main window's "gimmeeAnX()" slot.

This is a one-to-one connection: if no other widget emits a heyGotAnX() signal -or- you don't connect the same slot to it, then the only time that slot will be executed is when that particular dock widget emits the signal connected to it. Your main window knows that the only place that signal could have come from is the dock widget it connected to so there is no confusion, and your main window can do whatever it need to "differentiate" the action that has just occurred.

Nobody needs to know anything about the internals of anyone else's user interface in order for this to work. The main window needs to know that the dock widget can emit some custom signal, but the dock widget doesn't need to know anything about the main window. The dock widget doesn't even need to know if -anyone- is listening for its signals - it emits them when it is supposed to and that's it as far as it is concerned. It is up to the class whose slot is conected to that signal to do something with it.