pass ui to subclass

[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.