Combining classes - append class to QMainWindow

[SGaist]

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.

[Anonymous_Banned275]

@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?

[Anonymous_Banned275]

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.

[JKSH]

@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 :

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.

[JonB]

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

[Anonymous_Banned275]

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.

[Anonymous_Banned275]

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

[Chris Kawa]

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.

[Pl45m4]

@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

[Anonymous_Banned275]

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

[Anonymous_Banned275]

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

[Pl45m4]

@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 :)

[Anonymous_Banned275]

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())
           )
           ;

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

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

[Anonymous_Banned275]

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

[Pl45m4]

@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)

[Anonymous_Banned275]

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.

[Pl45m4]

@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).

[Anonymous_Banned275]

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.

[SGaist]

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

[Pl45m4]

@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);