How do I make a custom parent class from a class that inherits from QMainWindow?

[graniteDev]

@mrjj
So when adding menu items, you have to connect the menu item to a slot. In the example code, I'm just creating an instance of ServiceAppLayout, I can't add any menu items because menu items need to be connected to slots, and I can't put the slot in main.cpp and call "this" in the connection to access it.

If I could inherit from ServiceAppLayout, I could easily create new menu items and connect to them. I tried to figure out if there was a way I could do that programmatically through function calls, but I'm honestly not sure if that's possible. Can you add connections programmatically? wouldn't that necessitate the slot be a lambda - and that the entire lambda be passed into the function as an argument? That doesn't sound like a fun way to do things.

[mrjj]

Hi
You can use lambdas to have "slots" in main
https://artandlogic.com/2013/09/qt-5-and-c11-lambdas-are-your-friend/
(in place )

Or just create a QObject based helper class to hold the slots. So you connect say
ServiceAppLayout something to helpers object something.

• Can you add connections programmatically?
  Yes! just use connect statement.
  connect( pointer to instance, signal, pointer to instance, slot )
  Best to use new syntax.
  http://wiki.qt.io/New_Signal_Slot_Syntax

Im still not 100% i understand you issue. :)
can you show a line where u need "this" in main to help me understand the actual issue.

[mrjj]

Oh, wait. You seen a lot of this in connect statements and hence "this" seems important ?
Normally inside say Mainwindow, often one part of the connect statement is this as slot lives in mainwindow.
But it dont have to be "this" . its just because, its inside the class in question.

Its perfectly legal not to have "this"
connect( ui->someWidget, SIGNAl, ui->OTHER, SLOT( this slot lives in OTHER ))

[graniteDev]

@mrjj hmm....maybe it's not as big of an issue, more my trying to do it the hardway ignorantly. I gave thought to a helper class, but only fleetingly thinking that was the incorrect way of doing it in an object oriented paradigm.

Although I'm still not sure even adding a menu item with a helper class is possible.
Normally to set up a menu item the code looks like this:

    utilMenu = menuBar()->addMenu("Utilities");

    // utilites menu list
    QAction *networkAction = new QAction("Network",this);

    networkAction->setCheckable(false);

    utilMenu->addAction(networkAction);
    utilMenu->addSeparator();

    connect(networkAction, &QAction::triggered, this, &ServiceAppLayout::onNetworkAction);

and I tried, I can't access utilMenu->addAction from main.cpp even though I made utilMenu
public.

w.utilMenu.

Nothing would come up after the "." like normal so I realized something isn't quite right and I can't access those members.

I take it actually inheriting a class with a custom ui is impossible?

[mrjj]

@graniteDev
Well it is inherited already as UI file is just an XML file - Creator uses to create the setupUI() function that contains plain c++ code to create the form layout. 100% like manually code.
the UI file is not used runtime in anyway.

I think this is why im not 100% sure what goes wrong or what you try. :)

[graniteDev]

@mrjj Yes, I understand what "this" is doing. The slot part of the connection just needs to know what object to find the slot in.

[mrjj]

Ok, good.
Just checking. :)

But would utilMenu not live inside the UI ?
so its
w.UI->utilMenu ?
(UI is most likely still private if you didnt move it )

[graniteDev]

@mrjj OH that's a good point - I could have done it that way, but I just made a helper function that allows me to add an action to the menu. I believe now I can connect to it with a helper class....I'll try it and see what happens

[mrjj]

@graniteDev
Hi
Adding a public helper function to allow connects
is better design than make UI public.

Also as a note.

Its also ok to make connect from signal to signal to surface inner widgets signals to the outside.
So you declare new public signals and internally hook widget signal to new public signal.

Then you can connect from outside to the public signal interface and in that way totally hide
what the widgets really are inside. Only signals are visible.
If you later change a a widget to other type, you just need to fix the internal mapping.
Any external connections still just see the public signal interface and no change is needed.

So for example a custom fileDialog have the signal FileSelected that outside can use.
What widget internally that actually got the input is not important from outside.
They just use FileSelected and knows nothing about its inner design.
On larger programs, such details hiding are worth the extra code in gold.

[graniteDev]

@mrjj Ok, thank you for the advice. I have it working.

helper.cpp

#include "helper.h"
#include "exwidget.h"

helper::helper(QWidget *parent) : QWidget(parent)
{

}

void helper::callWidget()
{
    ExWidget *exWidget = new ExWidget(this);
    exWidget->setWindowFlags(Qt::Window);
    exWidget->setAttribute(Qt::WA_DeleteOnClose);
    exWidget->setWindowTitle("Vmap Viewer");
    exWidget->show();
}

main.cpp

#include <serviceAppLayout.h>
#include <QApplication>
#include <QMenu>
#include <QAction>
#include "widgettest1.h"
#include "widgettest2.h"
#include "helper.h"

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);


    ServiceAppLayout w;
    helper *h = new helper(&w);

    widgettest1 *widgetTest1_A = new widgettest1(&w);
    widgettest2 *widgetTest2_B = new widgettest2(&w);

    w.addCustomWidget(widgetTest1_A, "Test Widget 1");
    w.addCustomWidget(widgetTest2_B, "Test Widget 2");

    w.initializeLayout();

    QAction * testAction = new QAction("Test Menu Item", &w);
    w.addMenuItem(w.devMenu, testAction);
    QObject::connect(testAction, &QAction::triggered, h, &helper::callWidget);

    w.show();

    return a.exec();
}

Running it loads the layout, the widgets, and the new menu item, and clicking the menu item launches the widget as desired.

Thank you again for your help!

[mrjj]

Hi
Np :)
Super. And you use the new connection syntax :) \o/ +1
Just as a note
QObject::connect(testAction, &QAction::triggered, h, &helper::callWidget);

Could have been made with a lambda to avoid the helper but helper is also fine.

[graniteDev]

@mrjj It's true, but I'm trying to avoid piling tons of code into main, and just keep it as much as I can to one line commands. In the actual implementation there will need to be quite a lot more code in the helper file.

[mrjj]

@graniteDev
That is a good plan.
Also a helper class is more OOP than multiple lambdas in main :)