Newbie here, I put a dock widget in a main window, and there is a button in this dock widget panel, now I want to connect, this button with a function defined in the main window, it threw out an error, what should I do? Thanks
connect
(
perfectPanel_->btn_AAA,
SIGNAL(clicked()),
this,
SLOT(on_actionAAA_triggered()),
Qt::UniqueConnection
);
Error message is
$PWD/ui_perfectPanel.h: In constructor ‘xixi::xixi()’:
$PWD/ui_perfectPanel.h:71:18: error: ‘QPushButton* Ui_perfectPanel::btn_AAA’ is inaccessible
$PWD/xixi/xixi.cpp:51:25: error: within this context
Note that I have already managed to connect this with a toolbar button in the main window (xixi.cpp), it works great.
This happens because your dock class, perfectPanel, inherits privately from the generated ui class Ui::perfectPanel:
class perfectPanel : public QWidget, private Ui::perfectPanel
You could make that inheritance public, but shouldn't. Instead you should make the signal part of the perfectPanel class, and route the internal signal from the button to that external signal:
class perfectPanel ... {
...
signals:
void AAA_clicked();
};
perfectPanel::perfectPanel() {
setupUi(this);
connect(btn_AAA, SIGNAL(clicked()), this, SIGNAL(AAA_clicked()));
}
(And in case you would ask, yes, you can connect 2 signals together).
Then you simply connect the new signal inside your main window class:
connect(perfectPanel_,
SIGNAL(AAA_clicked()),
this,
SLOT(on_actionAAA_triggered()),
Qt::UniqueConnection
);
Related
I work with QT Creator 4.9.1 and i've made a gui with the designer. I have a MainWindow with a stackedWidget and round about 60 pages, inside my mainwindow i have a button, with the onButton_clicked signal i open a dialog(show picture) to insert a number to set the page the user want to see inside the mainwindow.
My Problem is that the SIGNAL comes from the Dialog with the name on_pushButton_Enter_clicked and my SLOT is inside my mainwindow with the name setCurrentIndex(). I,ve read the post's: "How to Connect Signal from MainWindow to Slot in Dialog" and "Qt connect mainwindow and dialog using signal and slot".
But that doesn't help me because my dialog doesn't know about my mainwindow and i don't know how i can connect them.
Signal:
Dialognummer_eingeben.h
...
signals:
void enterButtonPressed();
...
void Dialognummer_eingeben::on_pushButton_Enter_clicked()
{
QString text = ui->lineEdit_Dialognummer->text();
ui->lineEdit_Dialognummer->setText("");
this->reject();
emit enterButtonPressed();
}
Slot:
Terminal::Terminal(QWidget *parent) : QMainWindow(parent), ui(new Ui::Terminal)
{
ui->setupUi(this);
QObject::connect(&dialog, SIGNAL(enterButtonPressed()), this, SLOT(setCurrentIndex()));
}
void Terminal::setCurrentIndex()
{
int num = dianr.getNum();
QString strNum = QString::number(num);
switch(num)
{
....
}
}
Edit: 1. Add signal and slot code
2. Make some changes inside the code
inside my mainwindow i have a button, with the onButton_clicked signal i open a dialog(show picture) to insert a number to set the page the user want to see inside the mainwindow.
You have to additionally add a signal in your dialog class which should be emitted once enter button was pressed, using on_pushButton_Enter_clicked as a function is not enough. Add a signal in the dialog class, like "enterButtonPressed()" and emit it in the function on_pushButton_Enter_clicked.
Inside the mainwindow (at some point where the dialog is created) add this line:
connect(dialog, SIGNAL(enterButtonPressed()), this, SLOT(SlotNameWhichShouldGetCalled()));
EDIT: Even if the above solution should work, a better solution came to my mind.
You generally should use the QDialog::accepted signal to connect to (see https://doc.qt.io/archives/qt-4.8/qdialog.html#accept).
Concrete steps:
In on_pushButton_Enter_clicked() at the bottom of the code add accept() instead of this-reject() (I assume you want the dialog to be closed succesful and not as rejected?)
Connect to the QDialog::accepted() signal by adding
QObject::connect(&dialog, SIGNAL(accepted()), this, SLOT(setCurrentIndex()));
Additionally ensure that you have no error in the connect(...) function. If the signal/slot is not found or is not matching you should see something in your application output in Qt Creator
I have an application generally structured as the following:
class MultiEditor : public QWidget
{
...
MultiSplitter *mSplitter;
...
}
MultiEditor::MultiEditor( Main *main, QWidget * parent )
{
...
mActions[SplitHorizontally] = action = new QAction(tr("Split To Right"), this);
action->setShortcut( tr("Ctrl+P, 3", "Split To Right"));
connect(action, SIGNAL(triggered()), this, SLOT(splitHorizontally()));
settings->addAction( action, "editor-split-right", editorCategory);
...
}
void MultiEditor::splitHorizontally()
{
... do something on &mSplitter (above);
}
and a class MainWindow:
MainWindow::MainWindow(Main * main)
{
...
mEditors = new MultiEditor(main);
setCurrentMultiEditor(mEditors);
...
createActions();
mMenu = createMenus();
this->setMenuBar(mMenu);
...
}
and a class SubWindow that creates a widget:
SubWindow::SubWindow( QVariant * splitterData = 0, QWidget * parent = 0 )
{
...
sEditors = new MultiEditor(Main::instance(), this);
setCurrentMultiEditor(sEditors);
...
#ifndef Q_OS_MAC
QMenuBar *newMenu = main->createMenus();
newMenu->setSizePolicy(QSizePolicy ::Expanding , QSizePolicy ::Fixed );
windowLayout->addWidget(newMenu);
#endif
...
}
and the actual menu constructor:
QMenuBar * MainWindow::createMenus()
{
QMenuBar *menuBar;
QMenu *menu;
QMenu *submenu;
...
#ifdef Q_OS_MAC
menuBar = new QMenuBar(0);
#else
menuBar = new QMenuBar();
#endif
...
menu->addAction( currentMultiEditor()->action(MultiEditor::SplitHorizontally) );
...
return menuBar;
}
Let's suppose that I have the MainWindow and a open SubWindow.
Both create a MultiEditor with a Splitter inside.
All this works good on Ubuntu: every action is associated with the right Splitter. If I click on the SubWindow's Splitter, for example, and I trigger the action "splitHorizontally", the SubWindow's MultiEditor:splitHorizontally() is triggered, and the SubWindow's Splitter is affected.
This does not happen on Mac. Here, if I click on a SubWindow's Splitter, the mSplitter of the MainWindow is affected.
I believed that clicking on a mSplitter, I would focus that mSplitter, so the MAC's parentless menu would act on whatever mSplitter focused. But it happens that it get stucked with the mSplitter on the MainWindow.
Actually, could it be that I was thinking that the function currentMultiEditor() was dynamic (every time the action was triggered, a different MultiEditor was called), but in the truth the multiEditor is fixed when creating the menu (in MAC the menu is created only on the MainWindow, so the currentMultiEditor() would be MainWindow's mEditors, and that would still be anytime the action were triggered from anywhere)?
What is the best design for you?
Should I create new menus on MAC too? How?
If I understood your question correctly, this looks indeed like a focus issue and I'm not surprised Linux behaves differently than macOS.
Probably on macOS even if you open a window and click somewhere, the focus remains on the parent window, thus calling the unexpected QAction slot.
I think you have 2 options:
when a subwindow is open, make sure it gains the focus. Call the QWidget::setFocus() method on one of the visible widgets of the window
accept keystrokes only in one place and redirect them to the current context, which in other terms is your active window
Hope that helps
I want to forbid any action in the main window, including its closure. while open child
I try:
// child window
Settings::Settings(QWidget *parent) :
QWidget(parent),
ui(new Ui::Settings)
{
ui->setupUi(this);
((QWidget*)parent)->setEnabled(false); // or parent->setEnabled(false);
...
makes segmentation fault on Settings->show();
and I try send signal from Settings constructor/destructor
to MainClass slot
void MainClass::Enable(bool enable)
{
qDebug() << "detect signal enable"; //
this->setEnable(enable);
}
but signal wasn't sent.
ofcourse i connect Settings to MainClass)).
signal emiting works in any other function of Settings.
For child windows it would be better to inherit from QDialog (not QWidget) because the first one is designed specially for dialogs. From Qt docs:
The QDialog class is the base class of dialog windows.
The method you need is QDialog::exec(). It opens your dialog as a modal window which will block the input for other application windows until it is closed.
I have pretty specific situation. I want to place a QAction into QToolbar and reach following behaviour:
Checkable QAction with icon.
Classic arrow on the right side which is used for showing menu
By pressing this arrow my QDialog should appears on screen instead of QMenu-like one
Now I'm a bit confused with implementing all this things together.
For now I've created QAction added it to toolbar and also created an empty QMenubecause I didn't get the idea of how to add the "dropdown" arrow another way.
So, I also connected my slot to QMenu aboutToShow() signal and now, I can create my dialog and exec() it just before QMenu shows. But here's the main problem appears: after I did everything with my dialog an click OK button QMenu trying to appear, but as it is empty it shows nothing and further actions become available only after I left-click somwhere to "close" this menu.
Is there any way to force QMenu not to show or can inherit from QMenu and reimplemnt its behaviour (I've tried to do such trick with exec() show() popup() methods of QMenu after subclassing from it, but none of them are being called when menu appears on the screen) ?
Here's the solution, which worked for me.
class QCustomMenu : public QMenu
{
Q_OBJECT
public:
QCustomMenu(QObject *parent = 0):QMenu(parent){};
};
In code:
QAction* myActionWithMenu = new QAction ( "ActionText", toolbar);
QCustomMenu* myMenu = new QCustomMenu(toolbar);
connect(myMenu, SIGNAL(aboutToShow()), this, SLOT(execMyMenu()));
execMyMenu() implementation:
void execMyMenu(){
m_activeMenu = (QCustomMenu*)sender(); // m_activeMenu -- private member of your head class, needs to point to active custom menu
QMyDialog* dlg = new QMyDialog();
// setup your dialog with needed information
dlg->exec();
// handle return information
m_myTimer = startTimer(10); // m_myTimer -- private member of your head(MainWindow or smth like that) class
}
Now we have to handle timerEvent and close our menu:
void MyHeadClass::timerEvent(QTimerEvent *event)
{
// Check if it is our "empty"-menu timer
if ( event->timerId()==m_myTimer )
{
m_activeMenu->close(); // closing empty menu
killTimer(m_myTimer); // deactivating timer
m_myTimer = 0; // seting timer identifier to zero
m_activeMenu = NULL; // as well as active menu pointer to NULL
}
}
It works great on every platform and does what I wanted.
Hope, this would help someone. I've spent week trying to find this solution.
Witht QtCreator set up as default when you create a widget the class for it creates the form as private to the class. So you have for example something like this:
namespace Ui {
class MainWindow;
}
class MainWindow : public QMainWindow
{
Q_OBJECT
//...
private:
Ui::MainWindow *ui;
};
Now what I want to know is how you connect to the signals within the ui. For example if this widget was embedded into a QStackedWidget and when a button is pressed the page displayed needs to change. I would have considered connecting to the button but ui is private so I cannot.
Do I have to create signals in MainWindow and then within that connect the 'ui' signals to them and thus bubble up the hierarchy? Or have I missed something simple?
You can't have an unrelated object connect to signals/slots of aggregate components, even if you could it would break encapsulation and become a maintenance nightmare.
You need to expose the signals/slots of the aggregate components by adding them to the MainWindow API, and then call the relative ui component method in the definition.
For example, in the MainWindow definition, add:
signals:
void buttonClicked();
And then in constructor, do:
connect( ui->button, SIGNAL( clicked() ), this, SIGNAL( buttonClicked() ) );
This way, your MainWindow class propagates signals from it's aggregates - but finetuned to exactly how you intend the class to be used.