Using a custom mainwindow subclass in Creator/Designer?

[visinet]

For reference, I am investigating porting my old Borland CPP Builder (BCB) application to another tool chain and looking to see if I can do the same thing I did in BCB in QT. My application has say 3 different custom window form classes that are sub-classed/based on the tool's/framework's base main form class with added methods and properties needed by the application. BCB allowed me to create these custom sub-classed forms in the designer and save them as packages/libraries that can later be used at design time in the designer just like the native base form widget/object/class. In the designer you can then simple select say Add New and select the desired custom form instead of the base form and work with it in the designer just as if it was the base/standard form .

So in QT, basically create a few different custom MyWindow classes based on the QMainWIndow class that can then be used in Creator/Designer for the application's mainwindow and when adding new additional windows to the project and then allowing the user to edit these forms/windows in Creator/Designer just like the standard MainWindow.

Is it possible to do this or something similar in QT, and if so how?

I hope I was clear in describing my question, and thanks in advance for any and all input/advice from the community.

[Christian Ehrlicher]

If you just want a custom mainwindow class without setting additional properties in designer then create a mainwindow in designer and init the ui in your custom class. If you want additional properties in designer you have to create a designer plugin.

[visinet]

@Christian-Ehrlicher
Let me provide some more detail to make things clearer.

My application code base/Project is modified for each customer to meet the system requirements for their particular system. It is basically a SCADA system. The core functionality of the application is the same for all implementations but the number of the Forms/Window mentioned below and their widget contents vary for each installation and this is not done, like it should be, dynamically at runtime by reading some config files, all the modification are done at design time in the tool kit ( like BCB or QT ). So for each customer system I basically create a new application based on the generic source code and add new windows to it meeting the system requirements. There can be hundreds of custom Forms of the types mentioned below, so having the IDE allow me to create and work with new forms of a certain base class is a big help. I know this is not the best way to do this but that is how it works now and I do not want to redesign the entire system to work that way.

1- All the forms/windows (not dialogs) specific to a customer in my app must provide some basic functionality/interfaces to my back-end code so there is a TMasterForm class based off the framework's generic form (say QWmainWindow in QT) with some protected properties and pure virtual functions that 3 additional base Forms use as their base class, and these 3 additional forms are used as the base class for all other system implementation specific forms.

e.g. class TMasterForm : public TForm

2- The 3 other types of base Forms in the application are all based on the above mentioned TMasterForm class, and each class also defines some additional pure virtual functions and member variables that the back-end code needs.

• TMainForm e.g ( class TMainForm : public TMasterForm )
• TSubsystemForm e.g ( class TSubsystemForm : public TMasterForm )
• TDeviceForm e.g ( class TDeviceForm : public TMasterForm )

When building a new system for a client, I ask the IDE to create a new form of one of the types above and then I edit that form.

The TMainForm class is the used as the base class for the MainForm of the application, of which there is always only 1 instance of. In the IDE's generated code for this MainForm class I add the code to implement the virtual functions.

TSubsystemForm class is used as the base class for a type of window that provides specific capabilities in the application and each particular system will have many new forms of this type added to the project at design time with each new form eventually getting widgets and layouts added to it by the designer me at design time. Once again, in the IDE's generated code for each new form I add the code to implement the virtual functions.

The TDevicForm class is used just like the TSubsystemForm class. It is used as the base class for a type of window that provides specific capabilities in the application and each particular system will have many new forms of this type added to the project at design time with each new form containing different widgets and layouts that need to be edited at design time.

I'm not sure your first suggestion of manually editing the IDE generated MainWindow code will work with what I am trying to do, your thoughts?

Will the plugin method work given a more detailed explanation of my architecture?

Thanks again for all your feedback.

[mpergand]

@visinet
In situation (maybe) like yours, I use a different approach where I don't subclass MainWindow, but use subclasses of DeviceManager instead:

Device -> DeviceManager
               ^
               |
MainWindow -----

The MainWindow only knows standard parameters common for all devices, for a particular device it asks the DeviceManager:
deviceManager->buildUi(some view in main window)

An old post of mine where I talk about the same idea:
https://forum.qt.io/topic/132286/which-model-and-item-classes-should-i-use-to-display-custom-items-in-a-table-and-in-a-combo-box/17?_=1691695665312

[visinet]

@mpergand
Thanks for you response. I will take a look at your past post.

[visinet]

@visinet

Update:

I was eventually able to get this working, good enough, by manually editing the class structure of generic IDE generated MainWIndows to have their base class be my custom form and not the general QMainWindow. The only issue I ran into so far was that since the UI Designer does not know about the new inheritance structure it still creates a new UI for the new window and that UI overwrites any UI items that also exist in the in the parent UI. For example, I have a menu structure and functionality in the base window class created in the Designer ( window.ui) that I want all descendant windows to inherit, but when I create a new MainWindow that will be manually edited to inherit from the mainwindow base class it also has a menu and that menu overwrites, if that is the correct terminology, the base class one so when the form is shown at runtime the base class's menu is not present. Once I figure out what was possibly going on I simple deleted the menu from the new mainwindow and everything worked as expected.

So even though it does not appear, as far as I can determine, that QT Creator/Designer has a mechanism to allow you to create new forms in a project that are based on a custom template or custom mainwindow, and then work with these forms in the UI Designer just like a standard QMainWindow, I can basically achieve the same end result, with some limitations, by simply modifying the new window's class declaration and a few other items. Please don't get me wrong, I am not bad mouthing QT Creator/Designer, just updating the community on my experience in case that someone in the future is looking to do the same. Yes, it would be nice to have a simpler mechanism to allow developers reuse custom forms, other objects, and even entire projects, something maybe like templates, but I understand not all tools provides the same capabilities and still think QT is a fantastic framework and QT Creator/Designer are fantastic world class development tools.

Cheers

[Christian Ehrlicher]

@visinet said in Using a custom mainwindow subclass in Creator/Designer?:

The only issue I ran into so far was that since the UI Designer does not know about the new inheritance

And as I already told you - simply create a QMainWindow ui in designer and use your custom mainwindow class to init this ui in there. No need to fiddle around in the ui files manually.

[visinet]

@Christian-Ehrlicher
I apologize if I am not understanding exactly what your are suggesting, but I don't believe that method meets my desires, but I may be wrong, it wouldn't be the first time. As mentioned, I can get it to work and to reach my end goal somewhat, with some restrictions, but need to manually make code changes to the Designer created class files which concerns me because I am not sure if this could possibly cause weird problems down the road for Creator/Designer or even at runtime. I usually do not likje to try to 'Hack', for lack of a better term, what the IDE is doing to achieve my goals since that can end up resulting in endless hours debugging and trying to figure out why things are not working as expected. I will always try to use the IDEs built in functionality, if it exists.

Here is the basic workflow I am looking for and if this is possible natively in QT Creator/Designer.

All done in the designer with respect to the UI stuff:

1. Create a new mainform window and add all the menus, menu logic (slots), layout, docking behavior, other widgets and their corresponding logic, and other general logic that will be common to a large number of other forms in the project. Also add some pure virtual functions to the class that will get implemented in these other forms. All these additional forms should use this mainform as their base class and therefor inherit all its functionality, including all its UI stuff.

2. In Creator/Designer create a new form somehow based on the base class form from step 1 and then start customizing the UI of this form in the Designer, adding additional widgets and related functionality. At design and runtime, this new form should look like and behave exactly like the baseform from step 1 just with additional UI functionality added to it, basic class inheritance.

3. Repeat step 2 to create additional new windows, each having custom UI elements such as images, tables, buttons, labels that represent the data and functionality of different physical devices. In any particular project/system there can be a hundred or more new windows that need to be created like this.

4. Also, in new systems/projects, be able to reuse any of these custom windows easily.

I still do not understand exactly what you mean by "create a QMainWindow ui in designer and use your custom mainwindow class to init this ui in there" Can you please expand on how this would meet the above mentioned workflow or something basically equivalent.

The end goal is to have a library of these custom windows that can be used to create new systems quickly and easily by simply starting with a base project and simply adding any number if these windows from the library. Done.

Thanks again for your feedback and advice, it is much appreciated.

[Christian Ehrlicher]

@visinet said in Using a custom mainwindow subclass in Creator/Designer?:

, but need to manually make code changes to the Designer created

This is not needed when your MainWindow class derives from QMainWindow.

I don't know what I should write more - simply try it out. You're mixing your class with the ui generated class - these are two separate things. And you e.g. can't add a (virtual) function to an ui...

[visinet]

@Christian-Ehrlicher
Ok, I think I know were the disconnect is between us. I don't think I was clear it what files I said I was needing to manually modify. I am not modifing the Creator/Designer generated/updated ui_windowname.h file that Creator/Designer generates and modifies everytime you make changes to the UI and either save or build the project. I am editing the new window's .cpp and .h file that Creator/Designer generates when you add a new window to the project and changing the base class for the window from QMainWIndow to my custom base class so I guess I am not editing the actual UI file. I hope that clears that up. If not then am really not understanding the concept your are outlining.

I am sorry if I am frustrating you, but the only way, as understand it, for my custom windows to inherit all the functionality of another window/form is to have their base class be the base class of that form, not the generic QMainWindow class. This is basic C++ OOP correct, or am I seriously missing something. If this is correct, then I must manually change the base class for each new custom window's cpp and .h files that Creator/Designer creates when I ask Creator/Designer to create a new window from QMainWindow to my base window's class . If Creator/Designer would allow me to select my base window as the base class for the new window instead of say QmainWindow or QWidget I would not need to do this.

I have that working somewhat but run into the problem that the new custom windows are not showing any widgets from my base class other that the menu and maybe the status bar. as I have not tested that yet. I have been playing with this for a number of days and cannot resolve this. After thinking about it more my guess is that it has something to do with the fact both my base window and the custom window based on it have a central widget where all widgets, other than the menu and status bars, get populated so when the custom window gets created and calls the setupUi(this) function the custom window's widget overrides/overwrites/hides the central widget, and all its children, from the base window's UI.

Am I on track here or am I just seriously missing the concept that you keep trying to enlighten me on?

Thanks so much again.

[Christian Ehrlicher]

Again: you do not need to modify a ui file in any way except with the designer. There is simply no need for it. What do you modify in there?

[visinet]

@Christian-Ehrlicher What do you define "ui file" as?

When you ask Creator/Designer to add a new QMainWindow or QWidget window to your project it creates the .cpp. .h, and the .ui files for the new window in the project. Whenever you Make the project it dynamically creates a "ui_windowname.h" in the project's build directory, based on the .ui file in the project, which is the actual file that defines the UI and actually get compiled into the output, at least this what I have determined from my investigation.

The only changes I am making are to the window's .cpp and .h files and all I am doing is changing the window's base class from QMainWIndow to myBaseWindowClass, which innherits from QMainWindow, so the new window inherits from my base window class and not QMainWindow.

[Christian Ehrlicher]

@visinet said in Using a custom mainwindow subclass in Creator/Designer?:

The only changes I am making are to the window's .cpp and .h files and all I am doing is changing the window's base class from QMainWIndow to myBaseWindowClass, which innherits from QMainWindow, so the new window inherits from my base window class and not QMainWindow.

and exactly this is not needed. But do whatever you want...

[visinet]

@Christian-Ehrlicher
It's not that I 'want' to do it this way, it's that this is the only way I have been able to get this to somewhat work.

You have mentioned a few time that no manual code changes are needed and that this can all be done in the Designer, which is exactly what I am looking for, but still do not follow your suggestion of "init the ui in your custom class" .

Can you please expend on exactly how to do this because I really have no idea of exactly what you are instructing me to do.

In it's most basic example:

1. create a new QWidgets project with the default MainWindow named HomeWindow and add push button to it in Designer. This will be the application Main/Home window.
2. In Creator add a new additional MainWindow, call it CustomWindowBase, to the project.
3. In the Designer for the new CustomWindowBase window, add basic Menu and status bar functionality along with a push button that closes the window.
4. In Creator add a 3rd additional MainWindow, call it CustomWindow, to the project and in the Designer add a bunch of different widgets to it.
5. Go back to HomeWindow in Designer and add simple Slot/Action for the push button to create and show a new instance of the CustomWindow.

Now, how can your suggestion of "use your custom mainwindow class to init this ui in there" make it so when I run the application and select the HomeWindow push button, the new instance of the CustomWIndow that gets opened contains all the functionallity from the CustomWindowBase window along with all the widgets added to the the CustomWindow window.

From what you have been saying, this can all be done in the Designer without making manual changes to any of the windows class definitions and all I need to do is "create a mainwindow in designer and init the ui in your custom class".

I understand that I could do this if I do all the UI stuff in code and not use the Designer at all but from the beginning I have stated that I need this to work in the designer.

I am not trying to be difficult and really appreciate all the time you have spent responding but I just truly don't understand how to implement what you keep suggesting. What exactly does "init the ui in your custom class" mean in context of the above outlined work flow? I realize my SW development skills are a bit rusty, to say the least,. and my QT experience is limited but I feel I should be able to follow and understand the logic behind your suggestions but for the life of me I am not getting it or simply misunderstanding what you are suggesting .

Thanks again for all your time.

[mpergand]

Hi @visinet
What you want to do is impossible because ui files are not inheritable.
What you can do, is to create a stand alone ui file for each of your window subclasses and build the central widget with it.

#include "ui_CustomWindow.h"

CustomWindow::CustomWindow(QWidget *parent) : WindowBase(parent),
    ui(new Ui::CustomWindow)
{
	setCentralWidget(new QWidget);
	ui->setupUi(centralWidget());
….

You can have multi ui files (ui1, ui2 ...) as well and put them in a stack view for example,
or build specific views for your different subclasses.

To say the truth, I'm convince it will be easier to build your interfaces by code.
I don't think the Designer is appropriate for complex interfaces like yours.

[visinet]

@mpergand
Thanks for the response and idea, I will play around with your concept. My main issue with creating the UI in code is that I currently have over 70 unique device windows/views that need to be created, with each one having 500 to 1000 or more label widgets and a number of table widgets that display all the device's data points and each window has it's widgets laid out and organized differently. Doing this in code I believe will just be to cumbersome. My current system has a separate window for each device and each window organizes/distributes all the data widgets across different Tabs in a tab view. In QT I would like to still have individual windows for each device but was thinking of using different pages of a stacked widget to distribute/organize the data and say have a tool bar on the left that allows the user to select which set of data items, stacked view page, to view. The main reason for having separate windows for each device is so that multiple devices/windows can be open and worked with at the same time.

Thanks again for your feedback.

[Christian Ehrlicher]

Then create your ui stuff in designer - nothing hinders you from doing this and there is no need to modify those ui files later on.

[mpergand]

@visinet said in Using a custom mainwindow subclass in Creator/Designer?:

I currently have over 70 unique device windows/views that need to be created, with each one having 500 to 1000 or more label

I can't imagine how cumbersome it will be to create 100's of labels in Designer !
By code, you can use loops.
You need to carefully design your windows/views subclasses to avoid pitfalls/dead end.