Form too big. How to break it up please?
-
Long ago I used to be a c++ programmer and still know roughly how to do it. But how things have changed! Suddenly I need to do it again. I am using Qt Creator 4.6.1 on Opensuse 15.0. My form is getting too big and I need to move some dials and sliders into a separate window. I don't know how to make that happen and have the slots for those dials and sliders handled in the same class as for the main window. Thinking back to how I did these things in MSWindows days, perhaps I need the equivalent of a non-modal dialog? Any help much appreciated thank you.
-
Long ago I used to be a c++ programmer and still know roughly how to do it. But how things have changed! Suddenly I need to do it again. I am using Qt Creator 4.6.1 on Opensuse 15.0. My form is getting too big and I need to move some dials and sliders into a separate window. I don't know how to make that happen and have the slots for those dials and sliders handled in the same class as for the main window. Thinking back to how I did these things in MSWindows days, perhaps I need the equivalent of a non-modal dialog? Any help much appreciated thank you.
@thepedant: when you say you don't know how to do that, do you mean you don't know the steps needed to do this, or that you don't know which of the alternative methods to use?
It's hard to give a definitive answer based on the information provided, but I think you're on the right track with a non-modal dialog, though a plain QWidget might work just as well. Once you have decided what to move into the new window, create a new class (sub-classed from QDialog). If the items in your primary window were coded in C++, you can just cut and paste the desired items into your new class. If they were created in Designer, that will be a little more tricky. I've never done this before, but you might want to just copy the form file, add the copy to the project, then edit both, removing the parts you don't want for that particular display. Kind of tedious, but I think it would work.
Good luck...
-
@thepedant: when you say you don't know how to do that, do you mean you don't know the steps needed to do this, or that you don't know which of the alternative methods to use?
It's hard to give a definitive answer based on the information provided, but I think you're on the right track with a non-modal dialog, though a plain QWidget might work just as well. Once you have decided what to move into the new window, create a new class (sub-classed from QDialog). If the items in your primary window were coded in C++, you can just cut and paste the desired items into your new class. If they were created in Designer, that will be a little more tricky. I've never done this before, but you might want to just copy the form file, add the copy to the project, then edit both, removing the parts you don't want for that particular display. Kind of tedious, but I think it would work.
Good luck...
@mzimmers Thank you for responding. I think it's the step of creating a new class that makes the biggest puzzle for me. It's a MIDI application: a controller for an audio effects processor and the main class I created (MainWindow) contains members that send and receive MIDI messages, members that contain structures downloaded from the effects processor synthesizer. The new class really needs to access all those things and even access the current settings of the controls on the main window. I could possibly pass a whole raft of pointers to the new class but crikey moses it would be incredibly clumsy.
-
@mzimmers Thank you for responding. I think it's the step of creating a new class that makes the biggest puzzle for me. It's a MIDI application: a controller for an audio effects processor and the main class I created (MainWindow) contains members that send and receive MIDI messages, members that contain structures downloaded from the effects processor synthesizer. The new class really needs to access all those things and even access the current settings of the controls on the main window. I could possibly pass a whole raft of pointers to the new class but crikey moses it would be incredibly clumsy.
-
Put your "members/structures/messages", e.g to do with the MIDI, into their own classes as necessary. An EffectsProcessorSynthesizer class. These classes can be included wherever via their
.hfiles, both into MainWindow and other modules. Don't define these within the MainWindow, they are not main window things and would be difficult to access from there. -
Don't allow anything else outside-world to access "the controls on the main window". It's bad design, and you end up in tangle. Where necessary, pass the data around in the logical structures you defined by copying from the controls while inside MainWindow code, and outside world can populate these structures if they need to pass information back which the MainWindow can read to update its controls.
I don't know how to make that happen and have the slots for those dials and sliders handled in the same class as for the main window.
If you do want that: the main window can have a member variable which is one of your sub-windows/dialogs and still connect its signals to main window slots. There are various ways of doing this, simple is to export a desired widget (via a method is nice), so main window can still go:
connect(otherWidget->methodReturningPushButton(), &QPushButton::clicked, this, &MainWindow::otherWidgetPushButtonClicked);Though it's often nicer if you write wrapper code in the other widget to hide the pushbutton and raise its own signals on the widgets behalf for the main windows to connect to. But I know how that can get if you have many objects/signals.
-
-
-
Put your "members/structures/messages", e.g to do with the MIDI, into their own classes as necessary. An EffectsProcessorSynthesizer class. These classes can be included wherever via their
.hfiles, both into MainWindow and other modules. Don't define these within the MainWindow, they are not main window things and would be difficult to access from there. -
Don't allow anything else outside-world to access "the controls on the main window". It's bad design, and you end up in tangle. Where necessary, pass the data around in the logical structures you defined by copying from the controls while inside MainWindow code, and outside world can populate these structures if they need to pass information back which the MainWindow can read to update its controls.
I don't know how to make that happen and have the slots for those dials and sliders handled in the same class as for the main window.
If you do want that: the main window can have a member variable which is one of your sub-windows/dialogs and still connect its signals to main window slots. There are various ways of doing this, simple is to export a desired widget (via a method is nice), so main window can still go:
connect(otherWidget->methodReturningPushButton(), &QPushButton::clicked, this, &MainWindow::otherWidgetPushButtonClicked);Though it's often nicer if you write wrapper code in the other widget to hide the pushbutton and raise its own signals on the widgets behalf for the main windows to connect to. But I know how that can get if you have many objects/signals.
-
-
@JonB all good advice. I still think, though, that he needs to contend with mutual access to the actual instantiation of those objects. That's why I suggested using a struct, though you're right: a class/object would work at least as well.
-
Exactly...my point was just that he still needs a way of sharing the instantiation between windows, and for that, some aggregate (be it struct or class) is needed. I'd just add it as a parameter to the c'tor of the new window.
@mzimmers
That's fine. I'm afraid I don't get your multiple instantiation, and doubtless it will be long to explain! We each see things our own way. I just read it as he's asking how to move a sub-form-widget(s) out of a presently large main window module. -
