I have QDialog that is heavily designed with QDesigner , I saw on the web that I could add QStatusBar with code like this :
#include <QDialog>
#include <QStatusBar>
#include <QLayout>
#include <QApplication>
#include <QTextEdit>
#include <QStatusTipEvent>
class Dialog : public QDialog {
public:
Dialog() : QDialog(){
QLayout *l = new QVBoxLayout(this);
QTextEdit *te = new QTextEdit;
te->setStatusTip("XXX");
l->addWidget(te);
bar = new QStatusBar;
l->addWidget(bar);
l->setMargin(0);
l->setSpacing(0);
}
private:
QStatusBar *bar;
protected:
bool event(QEvent *e){
if(e->type()==QEvent::StatusTip){
QStatusTipEvent *ev = (QStatusTipEvent*)e;
bar->showMessage(ev->tip());
return true;
}
return QDialog::event(e);
}
};
int main(int argc, char **argv){
QApplication app(argc, argv);
Dialog dlg;
return dlg.exec();
}
Its not even working in my case .. maybe the QDialog is already have few layets that holds widget.
My question is can I some how use palceholder in the QDesigner or somehow promote widget that place hold the QStatusbar class? I don’t know …
What can I do in such case? can I implement new QStatusbar?
Thanks
I presume when you say it doesn't work, that you are not seeing the status bar when you run.
I don't see any way to do this wholly in the designer. The designer certainly resists the idea of promoting something to a QStatusBar. I suppose you could fool the designer by subclassing QStatusBar, and then promoting a QWidget to your subclass.
But I don't think we need to go that route just yet. I think with a few tweaks to the code you have above should help.
In the designer, add a layout, it doesn't matter what kind, at the bottom of your dialog. I called mine 'StatusBarLayout'. You can see the layout (the red box that's squished at the bottom). I removed the bottom margin in the dialog so that the status bar is flush at the bottom.
Now remove everything in the above code about layout l, and just do this:
bar = new QStatusBar(this);
pUI->StatusBarLayout->addWidget(bar);
pUI->textEdit->setStatusTip("XXX");
The textEdit was something added in the designer. Now when you run it you should see this:
I hope that helps
Edit:
You can also set the Status Tips for various widgets in the designer too, so there is no need to do that in the code unless you want to.
Try adding a QStatusBar like this:
QDialog dialog;
QLayout* layoutWidget = new QVBoxLayout(&dialog);
layoutWidget ->addWidget(new QTextEdit);
QStatusBar* statusBar = new QStatusBar;
layoutWidget ->addWidget(statusBar );
Related
So, I took it down a few notches and am trying simple programs to get the hang of Qt's tools.
First I tried a simple label inside main() function, then a button inside it. All good.
Next, I tried the same, but inside a main window (using the Qt's created documents). After the one-button program worked, I did a two-button program, that simple. Worked.
Then, I tried Qt's Box Layouts.
In none of these "main window" tries, I changed the main.cpp file created by Qt.
Here's the mainwindow.h:
#ifndef MAINWINDOW_H
#define MAINWINDOW_H
#include <QMainWindow>
#include <QPushButton>
class MainWindow : public QMainWindow
{
Q_OBJECT
public:
MainWindow(QWidget *parent = 0);
~MainWindow();
private:
QPushButton *button1;
QPushButton *button2;
};
#endif // MAINWINDOW_H
Next, the mainwindow.cpp file:
#include "mainwindow.h"
#include <QPushButton>
#include <QHBoxLayout>
MainWindow::MainWindow(QWidget *parent)
: QMainWindow(parent)
{
setWindowTitle(tr("Two Button Example"));
resize(400,300);
button1 = new QPushButton(tr("Bye!"));
button1->setGeometry(0,0,200,30);
//button1->setParent(this);
connect(button1,SIGNAL(clicked()),this,SLOT(close()));
button1->show();
button2 = new QPushButton(tr("Hide B1!"));
button2->setGeometry(0,0,200,30);
//button2->setParent(this);
connect(button2,SIGNAL(clicked()),button2,SLOT(hide()));
button2->show();
QHBoxLayout *layout = new QHBoxLayout;
layout->addWidget(button1);
layout->addWidget(button2);
setLayout(layout);
}
MainWindow::~MainWindow()
{
}
I'm studying this book (for the layouts specifically, Chapter 2, the Find Dialog example (page 16 of the book, or 34 from the pdf file): C++ GUI Programming with Qt 4 1st ed.pdf
For this specific problem, I also used this: QHBoxLayout - Qt Examples and Tutorials
What I noticed:
Commenting the QHBoxLayout part, all the way to the "setLayout" function, makes no difference in the program. No test I've done is affected by this QBoxLayout thing;
The "setGeometry" function sets the position (first two parameters) and size (width and heightm, last two parameters) of a widget. This position is related to the parent widget, which may be the screen itself when no parent is assigned;
When the "setParent" functions for the buttons are commented and the "show" function is uncommented, the buttons are shown each in a separate window from the MainWindow. When I uncomment the "setParent" functions, the buttons are shown inside the MainWindow, and there's no difference if there are or no "show" functions for the buttons. The detail is, for the book I referenced, no example so far have had the need to declare the parent widgets, nor did the example in Qt's Examples and Tutorials site;
If I don't use the "setGeometry" function, the buttons are big, like 600x600, whatever. They follow the rules above regarding the other functions, but they are huge and always one on top of the other, not side by side. The function "sizeHint()" used extensively in the book, also has no effect;
Appearently, it's all following the same syntaxes and rules of the examples. So, what am I doing wrong, or not doing here? If it's not a problem to enlight me with the "sizeHint()" function, too, that would be great.
Thanks in advance!
I don't even remember the origin of the problem, but I have never been able to work with the layouts right in the window. In company I worked with Qt we used a central widget for managing layouts, so the diagram is: window -> central widget -> layouts -> subwidgets. If I modified your code so, it would look like this:
MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent)
{
setWindowTitle(tr("Two Button Example"));
resize(400,300);
auto *parentWidget = new QWidget;
auto button1 = new QPushButton(tr("Bye!"), parentWidget);
button1->setGeometry(0,0,200,30);
connect(button1,SIGNAL(clicked()),this,SLOT(close()));
auto button2 = new QPushButton(tr("Hide B1!"), parentWidget);
button2->setGeometry(0,0,200,30);
connect(button2,SIGNAL(clicked()),button2,SLOT(hide()));
QHBoxLayout *layout = new QHBoxLayout;
layout->addWidget(button1);
layout->addWidget(button2);
parentWidget->setLayout(layout);
setCentralWidget(parentWidget);
}
Also, I don't quite understand why do you try to set the button size if the layout resets it later. To change the size inside a layout you must change the sizeHint of a widget:
setWindowTitle(tr("Two Button Example"));
resize(400,300);
auto *parentWidget = new QWidget;
auto button1 = new QPushButton(tr("Bye!"), parentWidget);
button1->setMaximumSize(20, 20);
connect(button1,SIGNAL(clicked()),this,SLOT(close()));
auto button2 = new QPushButton(tr("Hide B1!"), parentWidget);
button2->setMaximumSize(20, 20);
connect(button2,SIGNAL(clicked()),button2,SLOT(hide()));
QHBoxLayout *layout = new QHBoxLayout;
layout->addWidget(button1);
layout->addWidget(button2);
parentWidget->setLayout(layout);
setCentralWidget(parentWidget);
After some observation, I believe I know why it wasn't working.
In the examples provided, the person was using QDialog or applying the layouts straight to the main() code, while I was using the QMainWindow class.
I suppose that when you use a QMainWindow class, you always have to set a Central Widget in order to make layouts work (setting this central widget layout).
So a solution would be:
QWidget centerWidget = new QWidget();
setCentralWidget(centerWidget);
//Add buttons, lists, and whatever
/*Add a QHBoxLayout or a QVBoxLayout and use
layout->addWidget() to add the widgets created,
like the examples. Then:*/
centerWidget->setLayout(layout);
It works, like Victor Polevoy suggested. Just answering as I believe I understood why weren't my QLayouts working.
I am following Qt examples (like TabDialog) and I notice that all the UI items are created as pointers - yet I see no delete and no destructor.
Is that right ? Will that not lead to memory leak ?
I am trying to add destructors
~TabDialog()
{
delete tabWidget;
delete buttonBox;
}
and on caller
TabDialog *tabDialog = new TabDialog();
tabDialog->setAttribute(Qt::WA_DeleteOnClose);
tabDialog->exec();
But the program crashes when I close the dialog.
Are the destructors, and delete all pointer items, unnecessary or am I doing it wrong ?
I think that you are confused because of these lines:
tabWidget = new QTabWidget;//and so on
You don't see explicit parent (like new QTabWidget(this);), but it is not necessary here. Take a look here:
QVBoxLayout *mainLayout = new QVBoxLayout;
mainLayout->addWidget(tabWidget);
mainLayout->addWidget(buttonBox);
setLayout(mainLayout);
setLayout will reparent your QVBoxLayout and QVBoxLayout will reparent all widgets inside it, so now your widgets has a parent and they will be destroyed after your dialog.
As doc said:
When you use a layout, you do not need to pass a parent when
constructing the child widgets. The layout will automatically reparent
the widgets (using QWidget::setParent()) so that they are children of
the widget on which the layout is installed.
Note: Widgets in a layout are children of the widget on which the
layout is installed, not of the layout itself. Widgets can only have
other widgets as parent, not layouts.
I'm sorry, but this just doesn't reproduce. The test case is below. You'd probably need to add some extra code to make it reproduce.
Qt's memory management will take care of everything, since all of the widgets end up having parents. Namely:
Tabs are parented as soon as they are passed to addTab.
tabWidget and buttonBox are parented as soon as they are added to the layout.
Since you delete the tabWidget and buttonBox before Qt attempts to delete them, everything is fine. As soon as you delete them, QObject's memory management is informed and they are removed from the TabDialog's child list. I've made this point explicit in the destructor code.
The meaning of Q_ASSERT is: "At this point during runtime, the following must be true". If we're wrong, the debug build will abort. Since it doesn't, the assertions are correct. Thus, before delete tabWidget, the dialog has both QTabWidget and QDialogButtonBox children. After delete tabWidget, the dialog should not have any QTabWidget children anymore. And so on.
#include <QApplication>
#include <QDialog>
#include <QTabWidget>
#include <QDialogButtonBox>
#include <QVBoxLayout>
class TabDialog : public QDialog
{
QTabWidget *tabWidget;
QDialogButtonBox *buttonBox;
public:
TabDialog() :
tabWidget(new QTabWidget),
buttonBox(new QDialogButtonBox(QDialogButtonBox::Ok |
QDialogButtonBox::Cancel))
{
tabWidget->addTab(new QWidget, tr("General"));
tabWidget->addTab(new QWidget, tr("Permissions"));
tabWidget->addTab(new QWidget, tr("Applications"));
QVBoxLayout *layout = new QVBoxLayout;
layout->addWidget(tabWidget);
layout->addWidget(buttonBox);
setLayout(layout);
connect(buttonBox, SIGNAL(accepted()), this, SLOT(accept()));
connect(buttonBox, SIGNAL(rejected()), this, SLOT(reject()));
}
~TabDialog() {
Q_ASSERT(findChild<QTabWidget*>());
Q_ASSERT(findChild<QDialogButtonBox*>());
delete tabWidget;
Q_ASSERT(! findChild<QTabWidget*>());
Q_ASSERT(findChild<QDialogButtonBox*>());
delete buttonBox;
Q_ASSERT(! findChild<QTabWidget*>());
Q_ASSERT(! findChild<QDialogButtonBox*>());
}
};
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
TabDialog *tabDialog = new TabDialog();
tabDialog->setAttribute(Qt::WA_DeleteOnClose);
tabDialog->exec();
return 0;
}
The only way it'd crash is if you tried the following:
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
TabDialog *tabDialog = new TabDialog();
tabDialog->setAttribute(Qt::WA_DeleteOnClose);
tabDialog->exec();
// At this point `tabDialog` is a dangling pointer.
delete tabDialog; // crash
return 0;
}
Unfortunately, Qt examples are a case of pointless premature pessimization. Qt's classes utilize the PIMPL idiom extensively. Thus the size of, say a QTabWidget is not much larger than that of QObject (48 vs. 16 bytes on my 64 bit platform). By allocating the fixed members of your class on the heap, you're performing two heap allocations: a small one for the QObject-derived class, and then another one for its PIMPL. You're doubling the number of allocations for no good reason.
Here's how to avoid this pessimization:
#include <QApplication>
#include <QDialog>
#include <QTabWidget>
#include <QDialogButtonBox>
#include <QVBoxLayout>
class TabDialog : public QDialog
{
QVBoxLayout m_layout;
QTabWidget m_tabWidget;
QDialogButtonBox m_buttonBox;
QWidget m_generalTab, m_permissionsTab, m_applicationsTab;
public:
TabDialog() :
m_layout(this),
m_buttonBox(QDialogButtonBox::Ok | QDialogButtonBox::Cancel)
{
m_tabWidget.addTab(&m_generalTab, tr("General"));
m_tabWidget.addTab(&m_permissionsTab, tr("Permissions"));
m_tabWidget.addTab(&m_applicationsTab, tr("Applications"));
m_layout.addWidget(&m_tabWidget);
m_layout.addWidget(&m_buttonBox);
connect(&m_buttonBox, &QDialogButtonBox::accepted, this, &QDialog::accept);
connect(&m_buttonBox, &QDialogButtonBox::rejected, this, &QDialog::reject);
}
};
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
auto tabDialog = new TabDialog();
tabDialog->setAttribute(Qt::WA_DeleteOnClose);
tabDialog->show(); // NOT tabDialog->exec()!!
return app.exec();
}
The less explicit heap allocations, the better. This way you can't even be tempted to delete anything in the destructor, since there are no pointers involved. The compiler generates necessary destructor calls for you automatically.
Furthermore, if you're showing only one window in main, there's no point to explicit heap allocation either:
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
TabDialog tabDialog;
tabDialog.show();
return app.exec();
}
Memory handling on Qt
Qt handles the widgets as a tree, every widget has a parent and every parent has
the obligation to free the children memory, if a widget has no parent you should delete it manually with the operator delete.
(Note: I started learning Qt yesterday and I did my search before asking this.)
After a bit of playing with Qt Designer I decided to make a more serious program, all programatically. Whereas before, simple taskes seemed.. simple, now, diaplaying a button is hell of a complicated because it doesn't show up.
main.cpp
int main(int argc, char * argv[])
{
QApplication app(argc, argv);
PixelPeep p;
p.show();
return app.exec();
}
pixelpeep.h - relevant part
class PixelPeep : public QMainWindow
{
Q_OBJECT
public:
explicit PixelPeep(QWidget *parent = 0);
signals:
public slots:
private:
QToolBar * toolBar;
QHBoxLayout * toolbarLayout;
QToolButton * addButton; // add new image
QScrollBar * zoomBar;
};
pixelpeep.cpp - relevant part
PixelPeep::PixelPeep(QWidget *parent) :
QMainWindow(parent)
{
resize(600,375);
toolBar = new QToolBar;
addButton = new QToolButton;
addButton->setGeometry(20,20,20,20);
toolBar->addWidget(addButton);
toolbarLayout = new QHBoxLayout;
toolbarLayout->addWidget(addButton);
}
After all this, I get an empty window.
Possible cause, AFAIK:
button would go out of scope after being created in the class constructor - it's not the case here because it's dynamically allocated and pointer by the private member addButton
not being in a layout or having size 0 - it's not the case since both of these were addressed in the code
What else could it be?
Sorry for such a noob question...
Call addToolBar(toolBar); inside the PixelPeep constructor.
You didn't set any icon on your button so it will appear as invisible. Hover over it and you will see it's there:
My application uses a QTabWidget for multiple 'pages', where the top-level menu changes depending on what page the user is on.
My issue is that attempting to re-create the contents of the menu bar results in major display issues. It works as expected with the first and third style (haven't tested second, but I'd rather not use that style) on all platforms except for Mac OS X.
The first menu is created in the way I create most in the application, and they receive the correct title, but disappear as soon as the menu is re-created.
The second menu appears both on the initial population and the re-population of the menu bar, but in both cases has the label "Untitled". The style for the second menu was only created when trying to solve this, so it's the only way I've been able to have a menu stick around.
The third dynamic menu never appears, period. I use this style for dynamically populating menus that are about to show.
I have tried deleting the QMenuBar and re-creating one with
m_menuBar = new QMenuBar(0);
and using that as opposed to m_menuBar->clear() but it has the same behavior.
I don't have enough reputation to post images inline, so I'll include the imgur links:
Launch behavior: http://i.imgur.com/ZEvvGKl.png
Post button-click behavior: http://i.imgur.com/NzRmcYg.png
I have created a minimal example to reproduce this behavior on Mac OS X 10.9.4 with Qt 5.3.
mainwindow.cpp
#include "mainwindow.h"
MainWindow::MainWindow(QWidget *parent)
: QMainWindow(parent)
{
m_menuBar = new QMenuBar(0);
m_dynamicMenu = new QMenu("Dynamic");
connect(m_dynamicMenu, SIGNAL(aboutToShow()), this, SLOT(updateDynamicMenu()));
changeMenuBar();
QPushButton *menuBtn = new QPushButton("Test");
connect(menuBtn, SIGNAL(clicked()), this, SLOT(changeMenuBar()));
setCentralWidget(menuBtn);
}
void MainWindow::changeMenuBar() {
m_menuBar->clear();
// Disappears as soon as this is called a second time
QMenu *oneMenu = m_menuBar->addMenu("One");
oneMenu->addAction("foo1");
oneMenu->addAction("bar1");
oneMenu->addAction("baz1");
// Stays around but has 'Untitled' for title in menu bar
QMenu *twoMenu = new QMenu("Two");
twoMenu->addAction("foo2");
twoMenu->addAction("bar2");
twoMenu->addAction("baz2");
QAction *twoMenuAction = m_menuBar->addAction("Two");
twoMenuAction->setMenu(twoMenu);
// Never shows up
m_menuBar->addMenu(m_dynamicMenu);
}
void MainWindow::updateDynamicMenu() {
m_dynamicMenu->clear();
m_dynamicMenu->addAction("foo3");
m_dynamicMenu->addAction("bar3");
m_dynamicMenu->addAction("baz3");
}
mainwindow.h
#ifndef MAINWINDOW_H
#define MAINWINDOW_H
#include <QtWidgets>
class MainWindow : public QMainWindow
{
Q_OBJECT
public:
MainWindow(QWidget *parent = 0);
private slots:
void changeMenuBar();
void updateDynamicMenu();
private:
QMenuBar *m_menuBar;
QMenu *m_dynamicMenu;
};
#endif // MAINWINDOW_H
All this looks like Qt bug on OS X. And it's very old bug, actually.
You can do workaround and don't work with QMenu via QMenuBar::addMenu function calls, as you do here:
m_menuBar->addMenu("One");
Instead of this work with QAction retrieved from QMenu by creation of the QMenu instance dynamically and then calling of QMenuBar::addAction for the QAction instance retrieved by QMenu::menuAction, as following:
m_menuBar->addAction(oneMenu->menuAction());
Beside QMenuBar::addAction you can use QMenuBar::removeAction and QMenuBar::insertAction if you want to make creation only of some specific menu items dynamically.
Based on your source code here it's modified version of it which deals with all menus dynamic creation on every button click (you do this in your source code) and the menu 'Dynamic' is populated with different count of items every time you click the button.
#ifndef MAINWINDOW_H
#define MAINWINDOW_H
#include <QtWidgets>
class MainWindow : public QMainWindow
{
Q_OBJECT
public:
MainWindow(QWidget *parent = 0);
private slots:
void changeMenuBar();
private:
QMenuBar *m_menuBar;
QMenu *m_dynamicMenu;
int m_clickCounter;
};
#endif // MAINWINDOW_H
#include "mainwindow.h"
MainWindow::MainWindow(QWidget *parent)
: QMainWindow(parent),
m_clickCounter(1)
{
m_menuBar = new QMenuBar(this);
connect(m_dynamicMenu, SIGNAL(aboutToShow()), this, SLOT(updateDynamicMenu()));
changeMenuBar();
QPushButton *menuBtn = new QPushButton("Test");
connect(menuBtn, SIGNAL(clicked()), this, SLOT(changeMenuBar()));
setCentralWidget(menuBtn);
}
void MainWindow::changeMenuBar() {
++m_clickCounter;
m_menuBar->clear();
QMenu *oneMenu = new QMenu("One");
oneMenu->addAction("bar1");
oneMenu->addAction("baz1");
m_menuBar->addAction(oneMenu->menuAction());
QMenu *twoMenu = new QMenu("Two");
twoMenu->addAction("foo2");
twoMenu->addAction("bar2");
twoMenu->addAction("baz2");
m_menuBar->addAction(twoMenu->menuAction());
m_dynamicMenu = new QMenu("Dynamic");
for (int i = 0; i < m_clickCounter; ++i) {
m_dynamicMenu->addAction(QString("foo%1").arg(i));
}
m_menuBar->addAction(m_dynamicMenu->menuAction());
}
Additionally while developing menus logic for OS X it's good to remember:
It's possible to disable QMenuBar native behavior by using QMenuBar::setNativeMenuBar
Because of turned on by default QMenuBar native behavior, QActions with standard OS X titles("About","Quit") will be placed automatically by Qt in the predefined way on the screen; Empty QMenu instances will be not showed at all.
I think your problem is this line:
QMenu *oneMenu = m_menuBar->addMenu("One");
To add menus to a menubar you'd want code as follows:
QMenuBar *m = new QMenuBar;
m->addMenu( new QMenu("Hmmm") );
m->show();
To create menus, and then add actions, and then add the menu to the menu bar:
QMenu *item = new QMenu( "Test1" );
item->addAction( "action1" );
QMenuBar *t = new QMenuBar;
t->addMenu( item );
t->show();
I need to place several instances of a custom QPushButton subclass adjacent to one another. For some reason, the buttons overlap one another when painted. A simplified example of the problem is below.
Here is the (incorrect) output:
Here is the code:
#include <QtGui>
class MyButton : public QPushButton {
public:
explicit MyButton(Qt::GlobalColor color, QWidget *parent = NULL)
: QPushButton(parent), color_(color) {
setSizePolicy(QSizePolicy::Fixed, QSizePolicy::Fixed);
}
QSize sizeHint() const {
return QSize(50, 25);
}
protected:
void paintEvent(QPaintEvent *) {
QPainter painter(this);
painter.setOpacity(0.5);
painter.fillRect(0, 0, width(), height(), color_);
}
private:
Qt::GlobalColor color_;
};
int main(int argc, char **argv) {
QApplication app(argc, argv);
QWidget widget;
QHBoxLayout *layout = new QHBoxLayout;
layout->setSpacing(0);
MyButton *w1 = new MyButton(Qt::red);
MyButton *w2 = new MyButton(Qt::green);
MyButton *w3 = new MyButton(Qt::blue);
layout->addWidget(w1);
layout->addWidget(w2);
layout->addWidget(w3);
widget.setLayout(layout);
widget.show();
return app.exec();
}
What is causing this, and how do I fix it? BTW, I tried something similar with regular QWidget subclasses (instead of QPushButton subclasses), and there is no problem. It is something peculiar to QPushButton.
UPDATE: I'm really thinking now that this is a bug. I submitted it to the Qt Bug Tracker; we'll see what the Trolls think. In any case, deriving from QAbstractButton fixes the drawing problem ... I just had to re-implement some of the functionality I needed.
UPDATE 2: The Trolls at Qt provided a solution (workaround?); I posted their fix as an answer below. I'm leaving it up to their team to determine if this is a feature or bug. It apparently only behaves differently on the Mac.
The solution is to add the following to the subclass:
setAttribute(Qt::WA_LayoutUsesWidgetRect);
Apparently it is only necessary on the Mac platform; Windows and Linux display the layout as expected.
Instead of calling setSizePolicy() and reimplement sizeHint(), I would try to simply call
setFixedSize(50, 25)
in your constructor. This should update the sizeHint on its own.
Hope this helps.
Your code works fine for me. I have tested it. What version you use? I use Qt 4.6.3 and it is fine.