Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

Combining classes - append class to QMainWindow



  • My objective is to
    develop QWidget class - using GUI - QtDesigner.
    ( My current example is QMdiArea )
    then add / include / import / append (choose your terminology) this QWidget to QMainWindow class USING CODE .

    Here is my basic code

        MdiArea *mdiarea = new MdiArea();
        layout()->addWidget(mdiarea);
        mdiarea->show();
    
    
    

    It has an issue , I am getting this runtime error

    QMainWindowLayout::addItem: Please use the public QMainWindow API instead
    

    add the result display writes over QMainWindow bars

    e4ffb48b-460f-4e97-b3a8-2c311fd536e1-image.png

    1. How do I verify the actual QMainWindow UI setup AFTER this code ?
    2. It appears the my code is adding / replacing "centralwidget" with QMdiArea - that is NOT my goal.

    So - how do I add QMdiArea to "cenralwidget"?


  • Moderators

    Keep your cool everyone. The world is messed up as it is. Lets try to stay positive and friendly at least here ;)

    Anywho...

    why does intelisense offers inaccessible pointer as a valid entry ?

    It's a best guess effort. C++ is complicated language to provide accurate suggestions without actually compiling the whole thing. In some cases it doesn't have enough context so it uses heuristics to merely suggest what a valid syntax for given expression is without much consideration for the actual correctness of the program as a whole. Code completion is usually a lot more accurate in managed languages like C# or Java, as you have full language reflection at your disposal. In C++ a simple thing like #define true false can wreak havoc on suggestions.

    I'd suggest to treat code completion as a basic name and syntax helper. Sometimes you don't remember exact function or parameter name. Sometimes the param list is just long and it helps you save a few key strokes to type it in. Sometimes you want to quickly browse through class members looking for familiar keyword. For those cases it works well enough. I wouldn't rely on it to suggest meaningful code logic though. That should be on the programmer anyway IMO. In case of connect's it's especially important to understand what relations you're creating so relying on machine suggestions is not a good idea, at least until we have that world class AI made :P


  • Moderators

    @AnneRanch Sounds like you actually want to set the MdiArea as the central widget. In that case

    setCentralWidget(mdiarea);
    

    If, on the other hand, you indeed already have a central widget and you want to add that mdiArea to it then

    centralWidget()->layout()->addWidget(mdiarea);
    

    assuming of course that this central widget has a layout. If not then you need to create one.



  • @Chris-Kawa said in Combining classes - append class to QMainWindow:

    centralWidget()->layout()->addWidget(mdiarea);

    Hello Chris,
    no go , I missed something.

    Yes, I like to add to centralWidget.

    91caaa96-9979-4ebf-867d-9f348011feba-image.png


  • Moderators

    QMainWidnow doesn't have any central widget by default, so do you actually have a central widget? i.e. does centralWidget() return a non-nullptr ?
    From the picture I see you don't have one added in code so have you added it in the designer?
    If so - does it have a layout? i.e. does centralWidget()->layout() return a non-nullptr?



  • Yes, I did build QMainWindow using QtDesigner GUI and it does have centralWidget. I'll try to just replace it with the QMdiArea.
    I did some more reading on QMainWindow and it looks as I COULD replace default centralWidegt with QDock and then add centralWidget "inside" QDock.
    It is getting too complicated , but it may be the best final solution.


  • Moderators

    @AnneRanch That doesn't sound right.
    QMainWindow has an internal layout implementation and has an API that allows you to add one widget as a central widget, a widget as a toolbar, menubar and a bunch of QDockWidgets. Sorry to question you, but it really look s like you just don't have a central widget. It sounds like you want your mdi area to be the central widget so just setCentralWidget(mdiarea). If that's really really not the case could you post a screenshot of your widget hierarchy in the designer?



  • I did replace the default centerWidget and it works "BETTER".
    Now I have status bar , but Mdi still writes over menubar

       MdiArea *mdiarea = new MdiArea();
        if(centralWidget())
            std::cout <<"TOK centralWidget()  " <<std::endl;
        else
             std::cout <<"FAILED centralWidget()  " <<std::endl;
         setCentralWidget(mdiarea);
    

    f72f277c-dd9e-473e-b767-2d02266457e0-image.png


  • Moderators

    Ok, you do have a central widget in designer but it doesn't have a layout (the red crossed circle indicates that), so centralWidget()->layout() is null. That's why it crashed.

    Couple of options:

    1. (That's the one I'd recommend) Delete the central widget in designer and set mdiarea to be it from code:
    setCentralWidget(mdiarea);
    
    1. Add a layout to your central widget in designer and then you can do
    centralWidget()->layout()->addWidget(mdiarea);
    
    1. Add the layout from code and add a widget to it:
    QVBoxLayout* central_widget_layout = new QVBoxLayout(centralWidget());
    central_widget_layout->addWidget(mdiarea);
    

    but Mdi still writes over menubar

    I don't think it does. You just don't have anything in the menubar so it doesn't show up. It will show up once you add some menus or actions to it.



  • Thanks.
    You solved THREE "problems" in one post !
    I did not realize default QMainWindow form does not have a layout.
    I did not actually know what is "THE LAYOUT" and how it fits into the scheme of things.
    And I'll add some stuff to menu bar to see it .

    Great progress, but I need to fine tune it by adding the "rotten" btscanner dialogue as QDock next...


  • Lifetime Qt Champion

    Hi,

    @AnneRanch said in Combining classes - append class to QMainWindow:

    I did not realize default QMainWindow form does not have a layout.

    In fact it does have one and that's why you got the error message when trying to use it. QMainWindow's layout is "protected" because it's it that provides support for dock widgets toolbars etc.



  • @Chris-Kawa said in Combining classes - append class to QMainWindow:

    but it doesn't have a layout (the red crossed circle indicates that)

    OK, clarification needed.

    Even AFTER adding "form layout" I still have "red crossed circle" showing in the icon. No errors.

    Having presence or being "protected" seems to be TWO different properties.

    So which one "is causing the problem" encountered?



  • Expanding on the original post.
    Adding tab class to MainWindow by setting new centralwidget bypasses the missing / private "layout" . That works as desired.

    After that, similar process needs to be done "dowstream" - add QDialog to Tab class. Here the QDialoig does not have "centralwidget" to be replaced.
    So it is back to "layout" which does not exists or is private.

    Or I can go back to original - replacing QDialog with QWidget.
    Prefer no to do so - woudl have to convert more QDialogs to QWidgets.

    Any different solution , similar to centrawidget / layout , would be appreciated.


  • Moderators

    @AnneRanch said in Combining classes - append class to QMainWindow:

    Here the QDialoig does not have "centralwidget" to be replaced.

    It doesn't indeed. QMainWindow is a special widget with many regions including the "central" region. No other widgets have this structure. See the documentation at https://doc.qt.io/qt-5/qmainwindow.html :

    QMainWindow layout

    So it is back to "layout" which does not exists or is private.

    ...

    Any different solution , similar to centrawidget / layout , would be appreciated.

    Just like you call setCentralWidget() on QMainWindow, you can call setLayout() on plain "container" widgets like QWidget, QDialog, and QGroupBox.

    add QDialog to Tab class

    Can you explain your rationale for doing this?

    A dialog is designed to be a separate pop-up window. A tab widget is for "embedding" other widget inside an existing window. They have opposite goals.



  • @AnneRanch
    Going back for a moment to your earlier screenshot, and something @Chris-Kawa said about it. When using Qt Designer and you look at that "Object/Class" window showing your widget hierarchy: anywhere there you might see any widget you have added showing that "red-crossed-circle no-entry sign" on the widget. That indicates you should right click on that widget and add a layout to it. Without that, your widget layout is liable to be wrong.



  • Well , not sure if the group wants to continue this discussion.
    Been chastised for "reinventing wheel ", using stuff DIFFERENTLY than usual etc, Really do not want to repeat that, so let me leave WHY I am doing this alone. Maybe later...

    I prefer KISS, so my initial approach was to use QtCreator and build , using QtDesigner , base QMainWindow class.
    I did try QtCreator examples "Application" but it does not use Ui and I was not comfortable modifying "Application" example to fit my goal.

    However, the QMainWindow class build GUI "form" does not indicate , with the exception (red cross ) I just learn during this discussion, that "layout" is mandatory.

    That is still unresolved , because AFTER I manually add , using QtDesigner, " form layout " - the "red cross" is still there.

    As far as using code to reset "centralwidget" I am questioning the necessity of having "layout" - the application GUI works with no specific layout, just "free hand" , which to me makes sense.
    ( Not sure of advantage of using "form layout" during development - machine second-guessing the location of widgets or vice versa)

    BUT it looks as adding new QWidget to QMainWindow WITHOUT having "layout" is an issue.
    ( this format is awkward - I cannot see the previous post to intelligently reply to it )

    Now back to adding QDialog.
    I did try to add "layout" using code , but could not find how to code it . I got as far as QLayoutItem. I am still learning to navigate QtCreator.

     ui->tab->setLayout(????); // test add layout to first tab 
    

    PS
    Here is another, unconventional approach , to similar task
    https://stackoverflow.com/questions/23676283/splitting-qt-forms-between-multiple-ui-files
    Just to point out I am not the only crazy one.



  • @JonB
    Do I understand it correctly - adding "layout" to "centralwidget" is not enough to remove the "red cross" ?
    "layout" needs to be added to any widget "bellow" the "centralwidget".

    That is pretty minor issue - still looking for an answer why "layout" needs to be used at all when adding widgets in code.


  • Moderators

    Layouts are sort of a geometry managers for child widgets. When you resize a widget its layout takes care of moving and resizing the children to accommodate new parent size.

    A widget has either no layout or exactly one. This is indicated via that icon we talked about. If a widget has no layout its children sizes and positions are not automatically adjusted and can overlap. In such case you are responsible for manually calling setPos, move, resize, setGeometry or any other similar functions to set a correct child geometry. Layouts are a way of automating this tedious task. If a widget has a layout set it will react to the widgets resizeEvent and adjust children according to the layout's type. For example a QVBoxLayout will place children one under the other. QGridLayout will place them in a grid etc.

    Now for a little confusing part. You said you added a layout and it didn't remove the red circle. If you did that by dragging a layout from the toolbox on the left like you would with a button or a frame then you didn't set a layout on the widget. You added a new widget with that layout set, so what you have is the original widget, still without layout and a child with that layout.

    The option to set a layout on a widget is either in the right click menu under the "Lay out" sub-menu or on the toolbar (icons with dots, horizontal and vertical bars). An important note is that designer does not allow to set a layout on a widget that has no children (because it's usually not what you want anyway) so if you don't have any children those options will be grayed out.

    If you want to do that anyway you can workaround it with these steps:

    • add any child widget to the widget you want the layout set on (button, frame or whatever)
    • select the widget you want the layout to be set on
    • use either the right clik menu or the toolbar icons to set a layout (vertical, horizontal or grid)
    • remove the child widget you added previously

    This is not something you usually do though. Usually you either add children and set layout in the designer or do both of those from code.



  • @AnneRanch said in Combining classes - append class to QMainWindow:

    is not enough to remove the "red cross"

    It is, but if you do this in code, you will still see the red cross in QtDesigner, because your coded layout applies at run-time.

    Every widget or widget container can / should have a layout. Otherwise its content is floating around and it will produce other unwanted behavior, in terms of size (resizing) and position (while moving).

    So every new QMainWindow has its centralWidget, which is empty and has no layout set, per default. You could either add content to it, by drag'n'drop, using QtDesigner and then right click centralWidget -> Layout -> Then pick layout of your choice or you set a layout by using your code, then "grab" that layout again and add widgets (content)

    QHBoxLayout *cW_Layout = new QHBoxLayout;
    this->centralWidget->setLayout(cW_Layout);
    
    // To access your CW or its layout, do
    centralWidget->layout()->addWidget(  WIDGET_TO_ADD );
    
    // Ofc you can also populate your layout first before adding it to centralWidget
    


  • I need to restate - I did change / add layout in QtDesigner to observe the red cross persistence.

    I did not do that in code.

    As far as layout "automatically " do resizing - I am still in basic app development , hence I am happy camper when I see expected "static" results , I am not in position to move / resize things around at this stage.
    However, it is nice to know WHY to use layout in future, even it is not of my primary concerns for now.

    Cheers



  • @Pl45m4 said in Combining classes - append class to QMainWindow:

    @AnneRanch said in Combining classes - append class to QMainWindow:

    is not enough to remove the "red cross"

    It is, but if you do this in code, you will still see the red cross in QtDesigner, because your coded layout applies at run-time.

    Every widget or widget container can / should have a layout. Otherwise its content is floating around and it will produce other unwanted behavior, in terms of size (resizing) and position (while moving).

    So every new QMainWindow has its centralWidget, which is empty and has no layout set, per default. You could either add content to it, by drag'n'drop, using QtDesigner and then right click centralWidget -> Layout -> Then pick layout of your choice or you set a layout by using your code, then "grab" that layout again and add widgets (content)

    QHBoxLayout *cW_Layout = new QHBoxLayout;
    this->centralWidget->setLayout(cW_Layout);
    
    // To access your CW or its layout, do
    centralWidget->layout()->addWidget(  WIDGET_TO_ADD );
    
    // Ofc you can also populate your layout first before adding it to centralWidget
    

    This post is pretty much repeat of what was already said.
    This is not criticism, just a statement of fact.

    While applying similar approach in "layout-less" QDialog , as fas as QMianWindow" sees it, I have opted to use "promotion" and it works as desired.

    Of course the "promoted" form has "layout" already.
    I hope that makes sense.



  • @AnneRanch said in Combining classes - append class to QMainWindow:

    This post is pretty much repeat of what was already said.

    If you look at the time stamps of @Chris-Kawa 's and my post, you will see that they are just 2-3mins or so apart. The moment when I started typing, there was no response... So we both wrote our replies at the same time :)



  • I think I have painted myself into a corner.

    1. I have QMainWindow with class member BT_TabWidget
      This part works and I can verify the “connect” too
     BT_TabWidget *BT_tab = new BT_TabWidget(this);
      setCentralWidget(BT_tab);
      connect (BT_tab,
               SIGNAL(tabBarClicked(int)),
               this,
                SLOT(MainTestFunction())
               )
               ;
    
    1. In the BT_TabWidget I have promoted “tab” QWidget to
      DeviceDiscoveryDialog - QDialog class
      This part also works and I can actually retrieve / list bluetooth devices.

    2. DeviceDiscovwryDialog class has a member class QBluetoothDeviceDiscoveryAgent
      instantiated as
      discoveryAgent = new QbluetoothDeviceDiscoveryAgent();
      discoveryAgent does all the dirty work and it does it well , so far.

    Here is MY problem , basically while trying to monitor the working application progress.

    1. I cannot use discoveryAgent , have no access to it , as source for “connect”
      I should be able to get intelisense to accept / provide the following
      BT_tab→discoveryAgent....
      But it gives no "discoveryAget" option.

    2. I cannot figure out HOW to include SLOT (QMainWindow(….) ) ,
      in “connect” . Again intelisense is of no help and I am not sure if the #1 problem is the cause.
      ( I did try &app (main application) - no go )

    I am using "discoveryAgent" within the QbluetoothDeviceDiscoveryAgent to track the bluez "library" and just like to extend it to the main "status bar". It worked prior to implementing the promotion scheme.

    I am sorry to drag this discussion, but I keep running into these issues in the process.



  • @AnneRanch Here is a thought.
    Since promotion works I suspect that promoting QWidget "tab" to "DeviceDiscoveryDialog" is assigning a pointer to the class.
    I do not know that pointer, neither does Qt and its intellisence.
    Not having access to the unknown pointer I obviously do not have access to "DeviceDiscoveryDialog" variables / methods .

    So it is back to QtCreator interaction with QtDesigner - an annoying and BIG issue since I first started looking into Qt.
    Perhaps too much behind the scene automation.

    I have a small proof.
    I can implement promotion to "DeviceDiscoveryDialog" , in dialog, but I have to type /copy it in - no "pull down" control to help me.
    However, "DeviceDiscoveryDialog" has to be valid class.
    So the QtDesigner have knowledge about the "DeviceDiscoveryDialog", but it cannot be selected via "standard" pull down control.
    Unfortunately is it these (little) "gotcha " which keeps project from smooth development and completion.
    But it is fun.



  • @AnneRanch said in Combining classes - append class to QMainWindow:

    I cannot use discoveryAgent , have no access to it , as source for “connect”
    I should be able to get intelisense to accept / provide the following
    BT_tab→discoveryAgent....
    But it gives no "discoveryAget" option.

    Since discoveryAgent is a var or even a member in your BT_tab widget, you can not just access it from your MainWindow. You could write a getter-function in order to receive a pointer to discoveryAgent inside your MainWindow. You can connect to it afterwards. But there could be better ways in terms of structure. Why you need your agent in MainWindow? You could move every BT task to your BT widget. Then you just need to connect MainWindow and your BT widget for controls. Your Bt widget handles the whole BT stuff.

    @AnneRanch said in Combining classes - append class to QMainWindow:

    I cannot figure out HOW to include SLOT (QMainWindow(….) ) ,
    in “connect” . Again intelisense is of no help and I am not sure if the #1 problem is the cause.
    ( I did try &app (main application) - no go )

    How to include slot MainWindow?

    @AnneRanch said in Combining classes - append class to QMainWindow:

    connect (BT_tab,
    SIGNAL(tabBarClicked(int)),
    this,
    SLOT(MainTestFunction())
    )
    ;

    This doesn't look wrong, except you have an int-passing signal, but no slot, that can take that int value (parameter mismatch). Change slot to MainTestFunction(int) or use default values
    (void MainWindow::MainTestFunction(int i = 0){ /* some code */ } )

    If you use the new signal and slot syntax (function-based instead of string-based with SIGNAL / SLOT keywords), the autocompleter will find your slots (as long as they got declared correctly)
    ( https://wiki.qt.io/New_Signal_Slot_Syntax )

    connect(BT_tab, &BT_TabWidget::tarBarClicked, this, &MainWindow::MainTestFunction);
    

    This equals your connection above... 1st and 3rd (sender and receiver instance) stay the same.

    • Signal = & + Name of class + :: + name of signal
    • Slot = & + Name of class + :: + name of slot (after typing :: it should make some suggestions)


  • Since discoveryAgent is a var or even a member in your BT_tab widget, you can not just access it from your MainWindow.

    Is it not how class relations works?

    I have used the "new" connect and it works when the function is declared in QMainWIndow. It helps immensely.

    As soon as I can figure out how "bluez" is posting (pairing) error messages I should be able to move them from ( cerr ??) console to main status bar.

    Making great progress thanks to this forum.
    Appreciate that very much.



  • @AnneRanch said in Combining classes - append class to QMainWindow:

    Is it not how class relations works?

    How should MainWindow know about what happens inside BT_TabWidget unless it's declared public?
    So if you create a new QBluetoothDeviceDiscoveryAgent somewhere in your BT_TabWidget, MainWindow will not "see" that and can't access it either.
    Besides that I would let your BT widget handle all BT connection stuff and dont try to move the BT device- and connection handling to MainWindow. Connect MainWindow with your BT widget and not with everything inside your BT widget class.

    // In MainWindow
    connect(this, &MainWindow::someSignal, BT_tab, &BT_TabWidget::startDeviceDiscovery);
    
    // ############################
    
    // BT_Widget
    // Then search for BT devices in your BT_Widget in "startDeviceDiscovery" slot:
    
    void BT_Widget::startDeviceDiscovery()
    {
         QBluetoothDeviceDiscoveryAgent *discoveryAgent = new QBluetoothDeviceDiscoveryAgent(this);
          connect(discoveryAgent, SIGNAL(deviceDiscovered(QBluetoothDeviceInfo)),
                this, SLOT(deviceDiscovered(QBluetoothDeviceInfo)));
    
           // Start a discovery
           discoveryAgent->start();
    
          //...
    
    }
    

    https://doc.qt.io/qt-5/qbluetoothdevicediscoveryagent.html#details

    Edit:

    As I've said, I would not use the getter approach in this case (to access BtDiscoveryAgent), but in general, it would look like this:

    Class A.h

    #include "A.h"
    
    public:
         Class_A();
    
         A& getA() { return m_A; }
    
    
    private:
        A *m_A;
    
    
    

    ClassA.cpp

    m_A = new A();
    

    ClassB.h

    #include "classA.h"
    
    public:
         Class_B() { classA = new ClassA(); } // Creates ClassA instance in ClassB
    
    private:
        ClassA *classA; // Stores pointer to ClassA in ClassB
    
    

    ClassB.cpp

    // get member A from ClassA
    A *a = classA->getA();
    

    ClassA ptr in ClassB is used to access public get-function in ClassA, which will return private member A.
    Without getA function, ClassB would NOT see A in ClassA, even though you have full access to that instance (ClassA) itself, because A is a private member (= invisible for other classes).



  • This will certainly look repetitious to the discussion, but I AM Still having this issue.

    All of my "connect" code originally codded in QDialog of btscanner work as expected. No problem.

    What I desire is to post a message to QMainWindow "status bar".
    In theory , I want to "connect" former object QDialog to object QWidget.

    So I am adding another "connect" to the working code - constructor - of DeviceDiscoveryDialog.

    The sender SIGNAL object is "ui->scan" - plain "push button" and "ui->scan"
    does triple duty as part of mentioned other working "connect".

    The "issue" is , and again I asked before , HOW to assign (syntax) receiver object as QMainWindow.
    ( I believe my otherwise working code structure Main window -> tab widget ->DeviceDiscoveryDialog-> buetooth -QBuletoothDeviceDiscoveryAgent is OK)

    `
    if(
    (bool)
    connect( ui->scan,
    SIGNAL( sendStatus( const QString & ) ),
    &MainWindow_BT(),
    SLOT(MainWindow_BT()::displayStatusMessage(const QString & )
    )
    )
    )

    Above included code snippet throws this error 
    
    
    

    /media/z/DEV_COPY_LABEL/Qt/QT/qtconnectivity/examples/bluetooth/CAT_BT/device.cpp:136: error: taking address of temporary [-fpermissive]
    &MainWindow_BT(),
    ^

    What am I doing wrong ? 
    
    PS 
    I need to pass message using "connect" which implies, per doc,  I Ishould not be using the "new" connect style to connect functions.  At leas not WITHOUT more knowledge HOW to add parameters ( QString) to the "connect" process functions in new style of connect. 
    Maybe  later.

  • Lifetime Qt Champion

    @AnneRanch said in Combining classes - append class to QMainWindow:

    &MainWindow_BT(),

    You are creating a temporary object and taking its address.

    @AnneRanch said in Combining classes - append class to QMainWindow:

    SLOT(MainWindow_BT()::displayStatusMessage(const QString & )

    This is wrong as well. It's the slot name that is required.

    In any case, this code looks like it's located in a dialog that is likely created any your MainWindow_BT class. Is that correct ? If so, you are doing the connection in the wrong object. Your dialog should send its status and not care who is receiving it. That code should be located in the class that creates and handles your DeviceDiscoveryDialog. Likely your MainWindow_BT class.

    Therefore:

    connect(pointer_to_dialog, &DeviceDiscoveryDialog::sendStatus, this, &MainWindow_BT::displayStatusMessage);
    

    I do not see in your PS the relation with the new syntax.



  • @AnneRanch said in Combining classes - append class to QMainWindow:

    This will certainly look repetitious to the discussion, but I AM Still having this issue.

    But you still make the same mistakes :)

    @Pl45m4 said in Combining classes - append class to QMainWindow:

    connect(BT_tab, &BT_TabWidget::tarBarClicked, this, &MainWindow::MainTestFunction);

    It's always this structure. So no () - function calls in second or fourth argument allowed.

    My Get-Example was to illustrate how it would look like, when accessing private members from another class.

    @AnneRanch said in Combining classes - append class to QMainWindow:

    I need to pass message using "connect" which implies, per doc, I Ishould not be using the "new" connect style to connect functions. At leas not WITHOUT more knowledge HOW to add parameters ( QString) to the "connect" process functions in new style of connect.
    Maybe later.

    You dont need to use arguments in connection statement. The new syntax will do that for you. If your signal passes QString and your slot accepts QString, it just works. So you don't have to worry about types in your connection, if they match, everything's fine.

    This

    connect(test, SIGNAL(someSignal(QString)), this, SLOT(randomFnctn(QString)));
    

    Or even that:

    connect(test, SIGNAL(someSignal(int, qreal, QVector<int>)), this, SLOT(randomFnctn(int, qreal, QVector<int>)));
    

    Equals this:

    connect(test, &TestWidget::someSignal, this, &MainWindow::randomFnctn);
    


  • @Pl45m4 said in Combining classes - append class to QMainWindow:

    Equals this:
    connect(test, &TestWidget::someSignal, this, &MainWindow::randomFnctn);

    Please note - I may be repeating my errors but I do not post just to get "cut and paste" confirmations of my posts.
    I am hoping somebody will help find / lead me to a solution.
    .

    Here is a faulty - need of solution - code snippet .

    DeviceDiscoveryDialog::DeviceDiscoveryDialog(QWidget *parent)
        :   QDialog(parent), localDevice(new QBluetoothLocalDevice),
          ui(new Ui_DeviceDiscovery)
    {
       ui->setupUi(this);
       discoveryAgent = new QBluetoothDeviceDiscoveryAgent();
    // working connect 
        connect(ui->scan, SIGNAL(clicked()), this, SLOT(startScan()));
    // faulty connect 
    both sendStatus and displayStatusMessage are given/ completed by intellisnese - they exists,  and are valid BUT 
    this code throws  an error 
        connect(ui->scan,
                &DeviceDiscoveryDialog::sendStatus,
                this,
                &MainWindow_BT::displayStatusMessage);
    

    **Compiler output AFTERT "no matching function" error

    &MainWindow_BT::displayStatusMessage);
    

    is declared**

    This is just " connect" error, I have NOT implemented the actual "emit" to use it. Not until it passes by complier.

    ../CAT_BT/device.cpp: In constructor 'DeviceDiscoveryDialog::DeviceDiscoveryDialog(QWidget*)':
    ../CAT_BT/device.cpp:121:49: error: no matching function for call to 'DeviceDiscoveryDialog::connect(QPushButton*&, void (DeviceDiscoveryDialog::*)(const QString&), DeviceDiscoveryDialog*, void (MainWindow_BT::*)(const QString&))'
                 &MainWindow_BT::displayStatusMessage);
                                                     ^
    In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/qvariant.h:45:0,
                     from /usr/include/x86_64-linux-gnu/qt5/QtCore/QVariant:1,
                     from .uic/ui_device.h:12,
                     from ../CAT_BT/device.h:56,
                     from ../CAT_BT/device.cpp:51:
    /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:196:36: note: candidate: static QMetaObject::Connection QObject::connect(const QObject*, const char*, const QObject*, const char*, Qt::ConnectionType)
         static QMetaObject::Connection connect(const QObject *sender, const char *signal,
                                        ^
    /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:196:36: note:   no known conversion for argument 2 from 'void (DeviceDiscoveryDialog::*)(const QString&)' to 'const char*'
    /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:199:36: note: candidate: static QMetaObject::Connection QObject::connect(const QObject*, const QMetaMethod&, const QObject*, const QMetaMethod&, Qt::ConnectionType)
         static QMetaObject::Connection connect(const QObject *sender, const QMetaMethod &signal,
                                        ^
    /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:199:36: note:   no known conversion for argument 2 from 'void (DeviceDiscoveryDialog::*)(const QString&)' to 'const QMetaMethod&'
    /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:475:32: note: candidate: QMetaObject::Connection QObject::connect(const QObject*, const char*, const char*, Qt::ConnectionType) const
     inline QMetaObject::Connection QObject::connect(const QObject *asender, const char *asignal,
                                    ^
    /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:475:32: note:   no known conversion for argument 2 from 'void (DeviceDiscoveryDialog::*)(const QString&)' to 'const char*'
    /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:213:43: note: candidate: static QMetaObject::Connection QObject::connect(const typename QtPrivate::FunctionPointer<Func>::Object*, Func1, const typename QtPrivate::FunctionPointer<Func2>::Object*, Func2, Qt::ConnectionType) [with Func1 = void (DeviceDiscoveryDialog::*)(const QString&); Func2 = void (MainWindow_BT::*)(const QString&); typename QtPrivate::FunctionPointer<Func>::Object = DeviceDiscoveryDialog; typename QtPrivate::FunctionPointer<Func2>::Object = MainWindow_BT]
         static inline QMetaObject::Connection connect(const typename QtPrivate::FunctionPointer<Func1>::Object *sender, Func1 signal,
                                               ^
    /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:213:43: note:   no known conversion for argument 1 from 'QPushButton*' to 'const Object* {aka const DeviceDiscoveryDialog*}'
    /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:245:13: note: candidate: template<class Func1, class Func2> static typename QtPrivate::QEnableIf<((int)(QtPrivate::FunctionPointer<Func2>::ArgumentCount) >= 0), QMetaObject::Connection>::Type QObject::connect(const typename QtPrivate::FunctionPointer<Func>::Object*, Func1, Func2)
                 connect(const typename QtPrivate::FunctionPointer<Func1>::Object *sender, Func1 signal, Func2 slot)
                 ^
    /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:245:13: note:   template argument deduction/substitution failed:
    ../CAT_BT/device.cpp:121:49: note:   candidate expects 3 arguments, 4 provided
                 &MainWindow_BT::displayStatusMessage);
                                                     ^
    In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/qvariant.h:45:0,
                     from /usr/include/x86_64-linux-gnu/qt5/QtCore/QVariant:1,
                     from .uic/ui_device.h:12,
                     from ../CAT_BT/device.h:56,
                     from ../CAT_BT/device.cpp:51:
    /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:254:13: note: candidate: template<class Func1, class Func2> static typename QtPrivate::QEnableIf<(((int)(QtPrivate::FunctionPointer<Func2>::ArgumentCount) >= 0) && (! QtPrivate::FunctionPointer<Func2>::IsPointerToMemberFunction)), QMetaObject::Connection>::Type QObject::connect(const typename QtPrivate::FunctionPointer<Func>::Object*, Func1, const QObject*, Func2, Qt::ConnectionType)
                 connect(const typename QtPrivate::FunctionPointer<Func1>::Object *sender, Func1 signal, const QObject *context, Func2 slot,
                 ^
    /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:254:13: note:   template argument deduction/substitution failed:
    /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h: In substitution of 'template<class Func1, class Func2> static typename QtPrivate::QEnableIf<(((int)(QtPrivate::FunctionPointer<Func2>::ArgumentCount) >= 0) && (! QtPrivate::FunctionPointer<Func2>::IsPointerToMemberFunction)), QMetaObject::Connection>::Type QObject::connect(const typename QtPrivate::FunctionPointer<Func>::Object*, Func1, const QObject*, Func2, Qt::ConnectionType) [with Func1 = void (DeviceDiscoveryDialog::*)(const QString&); Func2 = void (MainWindow_BT::*)(const QString&)]':
    ../CAT_BT/device.cpp:121:49:   required from here
    /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:254:13: error: invalid use of incomplete type 'struct QtPrivate::QEnableIf<false, QMetaObject::Connection>'
    In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/qatomic.h:34:0,
                     from /usr/include/x86_64-linux-gnu/qt5/QtCore/qvariant.h:37,
                     from /usr/include/x86_64-linux-gnu/qt5/QtCore/QVariant:1,
                     from .uic/ui_device.h:12,
                     from ../CAT_BT/device.h:56,
                     from ../CAT_BT/device.cpp:51:
    /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:1073:45: note: declaration of 'struct QtPrivate::QEnableIf<false, QMetaObject::Connection>'
     template <bool B, typename T = void> struct QEnableIf;
                                                 ^
    In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/qvariant.h:45:0,
                     from /usr/include/x86_64-linux-gnu/qt5/QtCore/QVariant:1,
                     from .uic/ui_device.h:12,
                     from ../CAT_BT/device.h:56,
                     from ../CAT_BT/device.cpp:51:
    /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:285:13: note: candidate: template<class Func1, class Func2> static typename QtPrivate::QEnableIf<(QtPrivate::FunctionPointer<Func2>::ArgumentCount == (-1)), QMetaObject::Connection>::Type QObject::connect(const typename QtPrivate::FunctionPointer<Func>::Object*, Func1, Func2)
                 connect(const typename QtPrivate::FunctionPointer<Func1>::Object *sender, Func1 signal, Func2 slot)
                 ^
    /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:285:13: note:   template argument deduction/substitution failed:
    ../CAT_BT/device.cpp:121:49: note:   candidate expects 3 arguments, 4 provided
                 &MainWindow_BT::displayStatusMessage);
                                                     ^
    In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/qvariant.h:45:0,
                     from /usr/include/x86_64-linux-gnu/qt5/QtCore/QVariant:1,
                     from .uic/ui_device.h:12,
                     from ../CAT_BT/device.h:56,
                     from ../CAT_BT/device.cpp:51:
    /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:293:13: note: candidate: template<class Func1, class Func2> static typename QtPrivate::QEnableIf<(QtPrivate::FunctionPointer<Func2>::ArgumentCount == (-1)), QMetaObject::Connection>::Type QObject::connect(const typename QtPrivate::FunctionPointer<Func>::Object*, Func1, const QObject*, Func2, Qt::ConnectionType)
                 connect(const typename QtPrivate::FunctionPointer<Func1>::Object *sender, Func1 signal, const QObject *context, Func2 slot,
                 ^
    /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:293:13: note:   template argument deduction/substitution failed:
    /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h: In substitution of 'template<class Func1, class Func2> static typename QtPrivate::QEnableIf<(QtPrivate::FunctionPointer<Func2>::ArgumentCount == (-1)), QMetaObject::Connection>::Type QObject::connect(const typename QtPrivate::FunctionPointer<Func>::Object*, Func1, const QObject*, Func2, Qt::ConnectionType) [with Func1 = void (DeviceDiscoveryDialog::*)(const QString&); Func2 = void (MainWindow_BT::*)(const QString&)]':
    ../CAT_BT/device.cpp:121:49:   required from here
    /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:293:13: error: invalid use of incomplete type 'struct QtPrivate::QEnableIf<false, QMetaObject::Connection>'
    In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/qatomic.h:34:0,
                     from /usr/include/x86_64-linux-gnu/qt5/QtCore/qvariant.h:37,
                     from /usr/include/x86_64-linux-gnu/qt5/QtCore/QVariant:1,
                     from .uic/ui_device.h:12,
                     from ../CAT_BT/device.h:56,
                     from ../CAT_BT/device.cpp:51:
    /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:1073:45: note: declaration of 'struct QtPrivate::QEnableIf<false, QMetaObject::Connection>'
     template <bool B, typename T = void> struct QEnableIf;
                                                 ^
    ../CAT_BT/device.cpp: In member function 'void DeviceDiscoveryDialog::displayPairingMenu(const QPoint&)':
    ../CAT_BT/device.cpp:409:14: warning: unused variable 'testAction' [-Wunused-variable]
         QAction *testAction = menu.addAction("BT test menu add... ");
                  ^
    ../CAT_BT/device.cpp: At global scope:
    ../CAT_BT/device.cpp:461:47: warning: unused parameter 'message' [-Wunused-parameter]
     int DeviceDiscoveryDialog::StatusBar(QString *message)
                                                   ^
    Makefile:606: recipe for target '.obj/device.o' failed
    make: *** [.obj/device.o] Error 1
    19:21:42: The process "/usr/bin/make" exited with code 2.
    Error while building/deploying project CAT_BT (kit: Desktop)
    When executing step "Make"
    

  • Moderators

    In the connect statement third param is a pointer to object and fourth is a member of that object class.

    You're in DeviceDiscoveryDialog constructor so this is of class DeviceDiscoveryDialog. In your connect you have a member of MainWindow_BT. This can't work. You can't call a method of class A on an instance of class B.
    If you use this as third parameter the fourth needs to be a member of its class, so &DeviceDiscovery::SomethingSomething.
    If you want the fourth parameter to be &MainWindow_BT::displayStatusMessage the third parameter needs to be a pointer to an instance of that class.

    As @SGaist already mentioned - you probably don't have a pointer to MainWindow_BT in your DeviceDiscoveryDialog class. You're doing the connect in the wrong place. If you're creating an instance of DeviceDiscoveryDialog in MainWindow_BT then you should do that connect in MainWindow_BT, where you have both pointers available, not in the dialog that does not have access to the instance that created it.



  • @AnneRanch
    You need to act on the final paragraph of @Chris-Kawa's answer and @SGaist's comment, for the error to go away.



  • @Chris-Kawa said in Combining classes - append class to QMainWindow:

    In the connect statement third param is a pointer to object and fourth is a member of that object class.

    You're in DeviceDiscoveryDialog constructor so this is of class DeviceDiscoveryDialog. In your connect you have a member of MainWindow_BT. This can't work. You can't call a method of class A on an instance of class B.
    If you use this as third parameter the fourth needs to be a member of its class, so &DeviceDiscovery::SomethingSomething.
    If you want the fourth parameter to be &MainWindow_BT::displayStatusMessage the third parameter needs to be a pointer to an instance of that class.

    As @SGaist already mentioned - you probably don't have a pointer to MainWindow_BT in your DeviceDiscoveryDialog class. You're doing the connect in the wrong place. If you're creating an instance of DeviceDiscoveryDialog in MainWindow_BT then you should do that connect in MainWindow_BT, where you have both pointers available, not in the dialog that does not have access to the instance that created it.

    Thanks Cris,
    as always you are right on the money with your explanation.

    Now for absolutely last question in this discussion -
    why does intelisense offers inaccessible pointer as a valid entry ?

    Moral of the story - use intellisense with caution and NOT as a replacement for my albeit limited " experience / intelligence" .



  • This post is deleted!


  • This post is deleted!


  • @JonB said in Combining classes - append class to QMainWindow:

    @AnneRanch
    You are beyond rude (and not for the first time). I was trying to draw your attention to the fact that you will not solve your error message until you move where you are trying to do the connect(), rather than playing with its parameters where it currently is. I was short, polite & helpful.

    It's nice to know when @Chris-Kawa tells you this in hist last paragraph, you find it helpful. When I merely tried to draw your attention to the last of his paragraphs --- which is what you need to act on before you worry about understanding the preceding stuff --- his is helpful, mine is "superficial" and "does not help solve" and "inappropriate" and seems to demand an apology from you.

    Why is my comment "inappropriate"? Where have I ever asked you to apologise or say sorry for anything?

    Just unbelievable. GtH.

    Beyond rude post deleted .


  • Moderators

    Keep your cool everyone. The world is messed up as it is. Lets try to stay positive and friendly at least here ;)

    Anywho...

    why does intelisense offers inaccessible pointer as a valid entry ?

    It's a best guess effort. C++ is complicated language to provide accurate suggestions without actually compiling the whole thing. In some cases it doesn't have enough context so it uses heuristics to merely suggest what a valid syntax for given expression is without much consideration for the actual correctness of the program as a whole. Code completion is usually a lot more accurate in managed languages like C# or Java, as you have full language reflection at your disposal. In C++ a simple thing like #define true false can wreak havoc on suggestions.

    I'd suggest to treat code completion as a basic name and syntax helper. Sometimes you don't remember exact function or parameter name. Sometimes the param list is just long and it helps you save a few key strokes to type it in. Sometimes you want to quickly browse through class members looking for familiar keyword. For those cases it works well enough. I wouldn't rely on it to suggest meaningful code logic though. That should be on the programmer anyway IMO. In case of connect's it's especially important to understand what relations you're creating so relying on machine suggestions is not a good idea, at least until we have that world class AI made :P


Log in to reply