QT: How to close multiple windows of the same widget? - qt

I'm a beginner in programming in C++/Qt.
I created a widget called wexample in Qt. When displayed, there is an button event that will open another window of the same widget wexample, and so on. My question is how to close all the windows of that widget?
I open my first widget as follows:
wexample *w = new wexample;
w-> show();
Inside the widget, I also have these events:
void wexample::on_pushButton1_clicked()
{
wexample *w = new wexample;
w -> show();
}
void wexample::on_pushButton2_clicked()
{
QWidget::close();
}
So when button 1 is pressed, it will open a new window and so on. When button 2 is pressed, it will close the window where the button is. Is there a way to close all of the windows from that widget all at once? Or even better, is there a way to close specific windows (for example, all the windows after the 3rd one)?
I have tried using signal and slot but I can't connect them since they are all of the same name. I would have to declare all of the widgets beforehand for it to work but I cannot know how many of them the user will need.
I'm sorry if my question isn't clear. I am really a beginner and have been searching for a while but couldn't find an answer. Maybe the structure as a whole doesn't make sense. Please help. Thanks.

You should add your newly created wexample's to a list and then iterate through them when you'd like to close them:
class wexample : public QDialog
{
...
private Q_SLOTS:
void on_pushButton1_clicked() {
wexample *w = new wexample(this);
m_wexamples.append(w);
w->show();
}
void wexample::on_pushButton2_clicked() {
foreach (wexample *w, m_wexamples)
w->close();
}
private:
QList<wexample*> m_wexamples;
};
A few extra points here:
Notice that I added (this) to the wexample constructor above. This ensures that the dialog is properly parented (and therefore will be cleaned up if you don't manually delete the object yourself). Previously, you would have been leaking memory every time you showed the dialog
The slot for the second button simply iterates through the list of dialogs and closes them. This does NOT mean that the dialogs have been deleted (and in fact are still in the list after closing them). If you'd prefer to fully remove them, then use of the "take" methods of QList, removing the dialog from the list and then call dialog->close(); dialog->deleteLater(); on it
This is a somewhat contrived example, you probably won't be opening the dialog from within the dialog's implementation in practice

Related

What is the life time of object passed as receiver for a QAction in a QMenu widget?

I'm working on QMenu to implement some custom functionality.
I'm having trouble in understanding when does a particular object gets destroyed during the execution of QMenu pop and triggering of any action.
here is the snippet of the actual codde :
myCustomMenu, a derived class from QMenu has a function customExec()
void myCustomMenu::customExec()
{ myCustomMenu *rearrangedMenu = new myCustomMenu();
myCustomFunctionalityClass *mCFC = new mCFS(this, rearrangedMenu);
//This class saves "this" as originalMenu i.e. the current menu object's address in a variable so that I can access with following action's SLOT.
rearrangedMenu->addAction(" Open My Custom Widget", mCFC, SLOT(showWidget()) ;
rearrangedMenu->exec();
}
When I click on "Open My Custom Widget" a gui widget opens up, and inside the showWidget() if I try to access mCFC->originalMenu->size() it crashes.
It appears that the object has been destroyed.
My problem is that how can I access that object? And if it gets destroyed then why not mCFC object which is also a local variable.
EDIT: showWidget slot is a member of mCFC class.
Please add comments if you have any doubt understanding it. I'm stuck on this since a while.

How to call plain function from exec()?

I have 2 classes: one maintains some loop (at leas for 2-3 minutes; and is inherited from QObject) and another shows up a progress dialog (inherited from QDialog).
I want to start the loop as soon as the dialog is shown. My first solution was:
int DialogClass::exec()
{
QTimer::singleShot(0, LoopClassPointer, SLOT(start()));
return __super::exec();
}
There is a problem with throwing exceptions from slots. so I considered a possibility to make public slot start() just a public function. But now I don't know how to make it works well. Things like this:
int DialogClass::exec()
{
LoopClassPointer->start();
QApplication::processEvents();
return __super::exec();
}
don't help. The dialog doesn't appears.
Is there a common approach to this kind of situations?
some details, according to questions:
I have to work with system with its own styles, so we have a common approach in creating any dialogs: to inherit them from stytle class, which is inherited from QDialog.
my 'LoopClassPointer' is an exported class from separate dll (there is no UI support in it).
I have a 'start' button in main app, which connected with a slot, which creates progress dialog and 'LoopClassPointer'. at the moment I send 'LoopClassPointer' instance in the dialog and don't whant to make significant changes in the architecture.
Take a look at QtDemo->Concurrent Programming->Run function
e.g. in Qt 4.8: http://qt-project.org/doc/qt-4.8/qtconcurrent-runfunction.html
In this situation, I recommend you separate the logic of the loop from the dialog. Gui elements should always be kept separate.
It's great that your worker class is derived from QObject because that means you can start it running on a separate thread: -
QThread* m_pWorkerThread = new QThread;
Worker* m_pWorkerObject = new Worker; // assuming this object runs the loop mentioned
// Qt 5 connect syntax
connect(m_pWorkerThread, &QThread::started, m_pWorkerObject, &WorkerObject::start);
connect(m_pWorkerThread, &QThread::finished, m_pWorkerThread, &QThread::deleteThis);
m_pWorkerObject->moveToThread(m_pWorkerThread);
m_pWorkerThread->start();
If you're not familiar with using QThread, then start by reading this.
The only other thing you require is to periodically send signals from your worker object with progress of its work and connect that to a slot in the dialog, which updates its display of the progress.

Force update of QTListWidget to add/remove elements

I'm attempting to wrap a GUI around an existing management console app. The main function is to search for network devices, which is given a timeout and is essentially a blocking call until the timeout has expired (using sleep to do the blocking). In this example the call is this->Manager->Search(...).
My issue is that I want the QListWidget to display "Searching..." while the search is taking place, and then update with the results at the completion of the search. My on-click code for the Search button is as follows:
void ManagerGUI::on_searchButton_clicked()
{
ui->IPList->clear();
new QListWidgetItem(tr("Searching..."), ui->IPList);
ui->IPList->repaint();
this->Manager->Search(static_cast<unsigned int>(this->ui->searchTime->value()*1000.0));
ui->IPList->clear();
if(this->Manager->GetNumInList() != 0)
this->displayFoundInList(this->Manager->GetFoundList());
else
new QListWidgetItem(tr("No Eyes Found"), ui->IPList);
ui->IPList->repaint();
}
When I hit the button, the QListWidget IPList does not update until after the timeout has taken place (and I assume until after this callback has terminated). Does anyone have any suggestions? I was under the impression that calling ui->IPList->repaint() would cause an immediate redraw of the list.
Additional info:
QT Version 5.1.0 32-Bit
Compiled using VS2012
Running on Win7 Pro 64-bit (but to be ported to OSX and Linux, so nothing win-specific please)
1) You don't need to call repaint directly.
2) You should do your search asynchronously. It is big topic - you should learn basics of Qt first.
Start with signals and slots and then learn about QThread or QtConcurrent. Then implement a class that will do searching and send necessary signals: first signal on search start, second signal - on search stop. Then connect slots to this signals and work with your list view insine this slots.
Problem is that your "Search manager" blocks Qt's event loop. Thats why listview does not repainted.
You need a signal slot system because your search is blocking. Ideally you should do the search in a new thread. However you can cheat with a processEvents()
void ManagerGUI::on_searchButton_clicked()
{
ui->IPList->clear();
new QListWidgetItem(tr("Searching..."), ui->IPList);
emit signalStartSearch();
}
void ManageGUI::slotStartSearch()
{
// Process any outstanding events (such as repainting)
QCoreApplication::processEvents();
this->Manager->Search(static_cast<unsigned int>(this->ui->searchTime->value()*1000.0));
emit signalSearchCompleted();
}
void ManagerGUI::slotSeachCompleted()
{
ui->IPList->clear();
if(this->Manager->GetNumInList() != 0) {
ui->IPList->setUpdatesEnabled(false);
this->displayFoundInList(this->Manager->GetFoundList());
ui->IPList->setUpdatesEnabled(true);
} else {
new QListWidgetItem(tr("No Eyes Found"), ui->IPList);
}
}
Ideally you would want the Manager->Search to emit the signal and then use QtConcurrent::run to do the search in another thread.

iterate through mdiarea subwindows

I have a mdiArea. I add subwindows to this mdiArea every time an image is opened. The widget I set for each subwindow is imageFileDialog which inherits from the QDialog. Within this dialog I have a spinbox. I want to be able to set the value of this spinbox for every dialog I have in the mdiArea after they have been created. I do not know how to iterate through the dialogs. I tried to think of ways to do this.
for (int j=0; j < ui->mdiArea->subWindowList().size(); j++)
{
imageFileDialog *ifd = ui->mdiArea->subWindowList()[j]->widget();
ifd->setSpinBox(0);
}
but I have an error because I cannot cast the widget as my imageFileDialog class that inherits from QDialog.
I though I might be able to set a connection upon creation of my imageFileDialog:
imageFileDialog *ifd = new imageFileDialog();
ifd->connect(this, SIGNAL(emitImageFileValue(double)), SLOT(ifd->setSpinBox(double)));
subWindow1->setWidget(ifd);
but this is unlike any connection I've tried to make before. Everything compiles fine, but the signal emitted does not reach my slot. I'm hoping someone has tried this before and has some suggestions! Thanks in advance.
Use qobject_cast for the first problem and for the second issue you need to pass only the slot name to the SLOT() macro (without ifd->), or pass the ifd pointer as separate parameter to connect, something like:
QObject::connect(this, SIGNAL(emitImageFileValue(double)), idf, SLOT(setSpinBox(double)));

QFileDialog used as widget

My goal is: user can choose file (only *mp3) and after clicking twice on it it should play (so the QString to file should be send to play() function)
Firstly I started to work with QTreeView, but it has signal when the file is selected.
So I decided to create QFileDialog and used it as widget built-in into MainWindow.
The only problem that I have, that after double-click it disappears. It is possible to avoid it?
Should I work with some QDialog::finished() signal or, QDialog::done()?
First, you can get a double-click signal from QTreeView; it's:
void doubleClicked( const QModelIndex & index );
Second, if you really want to use the QFileDialog that way, first override closeEvent( QCloseEvent * event). Inside, if you want to close the dialog, do event->accept();, otherwise just do event->ignore();. Connect to QFileDialog::currentChanged( const QString & path ); to get the filename the user double-clicks. One last thing--be sure to create the QFileDialog on the heap (using new), not on the stack (a local), and call show() on it instead of exec().
Remember that you can supply it with a parent (this) and you won't need to delete it later.
connect(file_dialog, SIGNAL(finished(int)), file_dialog, SLOT(open()));
This seems to work fine. The geometry stays fixed and it remembers the last path allright..

Resources