Simple Query:
If GUI widget window is hidden does it receives signals from other objects?
In our Qt application we have seen this issue/behaviour.
However, when window is shown it receives and process all the signals that it receives.
Every QObject (and hense every QWidget) receives signals until it's destroyed or the signal is disconnected. Visibility doesn't matter.
If you don't disconnect signals while hiding the QWidget they're received and processed.
Related
I have a child QDialog, when a button is pressed from it a socket is opened from QtConcurrent, and if there's an error an alert dialog is shown.
But if the user closes the child QDialog to return to the main window the signal cannot be received by the child QDialog slot.
I tried to broadcast the signal to parentWidget, but the program crashes, because this->parentWidget() doesn't exist anymore.
I use this code to emit the signal and connect it to the slot
connect(this, SIGNAL(errorTcpSignal(QString)), this, SLOT(displayTcpError(QString)));
connect(&t, QOverload<QAbstractSocket::SocketError>::of(&QAbstractSocket::error),[=](QAbstractSocket::SocketError err){
emit errorTcpSignal("Error while changing game settings \n" + QVariant::fromValue(err).toString());
});
Is there a way to solve this issue?
Thank you very much.
SOLVED:
emit the signal from the child widget, but set the connection from the father widget.
I have a custom implementation of QChartView where I can zoom. (Class "ChartView" from this example)
In there I have a mousePressEvent.
Now I wanted to add a QScatterSeries and connect the clicked signal with a custom slot. Unfortunately as soon as I click on my QScatterSeries only a signal is emitted to my ChartView mousePressEvent slot and not to my QScatterSeries mypoint_clicked slot.
I also added an QScatterSeries hovered signal which works fine.
connect(myScatterSeries, SIGNAL(hovered(QPointF,bool)), this, SLOT(mypoint_hovered(QPointF,bool)));
connect(myScatterSeries, SIGNAL(clicked(QPointF)), this, SLOT(mypoint_clicked(QPointF)));
Just guessing here.
mousePressEvent() is not a slot, but an event handler. I guess that QChartView::mousePressEvent() is somewhat responsible for handling mouse press events on the chart and dispatching them to series.
If you reimplemented ChartView::mousePressEvent() without explicitly calling QChartView::mousePressEvent() to forward the event, you might prevent the normal event processing to dispatch the event to the series. And therefore QScatterSeries::clicked() is never emitted.
I have a visual c++ program which creates multiple GUI on the main thread. I want to show a QWidget alongside all the other GUI. Currently, if I call QApplication.exec(), it blocks the main thread until I close the window. Is there any way to prevent the exec function from blocking the main thread or to use QWidget without calling exec?
The method is not blocking the main thread, on the contrary: it allows the event loop to execute, ensuring that the UI remains responsive.
While the widget is shown, all the other GUI will be responsive, as Qt's event loop fully interoperates with the native message queue.
If you want something to happen when a dialog widget gets closed, connect the relevant code to e.g. the dialog's accepted() signal.
I've made my first qt window. Now I'd like to make my first dialog, using qt. I have just finished creating the dialog, which is basically made of a QDialogButtonBox, and now I'd like to connect it to the window. I have two beginner's questions:
How can I retrieve how the dialog was closed (ok pressed or cancel pressed) from the window.cpp, which creates a new dialog, and then calls dialog->show() ?
Where and how to destroy the dialog pointer ?
If you use dialog->show() then I assume it's non-modal dialog.
If you have created QDialogButtonBox and connected its signals with accept() and reject() slots of your dialog as documentation shows, then your dialog will emit finished(int) and additionally accepted() or rejected() signals by which you can determine how it was closed.
If you need more customized behavior, then you can reimplement closeEvent(QCloseEvent *event) or create your own singnals.
If you need to delete your dialog you can use setAttribute(Qt::WA_DeleteOnClose, true);, which will delete instance on close.
you can use one flag, and signal and slot.
when put OK flag=1 , and when put cancel then flag=-1; and then use signal.
in in the window.h write code how to handle that flags with 1 simple slot.
for destroying the pointer you can use signal and slot in your Dialog and tell when user push
Ok, or Cancel , or exit (up- right (red cross)) go to slot in call the Destructer of dialog
and also you that you better set parent of dialog to window.
First Question:
When you want to show the dialog,just construct it,using myDialog *d = new myDialog(this)(the this pointer will make sure that you havn't to delete the pointer you created 'cause Qt will handle this if you specified the dialog's parent). And use d->exec() if you need a modal dialog, or d->show() to make it non-modal;
Second Question:
Once your specified the dialog's parent object, all u need is just use it and leave alone the memory managent,Qt will do this for you. Also you can use d->setAttribute(Qt::WA_DeleteOnClose,true) to make it destroy itself when it is closed.
Remember to link the QDialogButtonBox to your dialog's actions.
I need help to understand to use QEvents in QT, this is driving me crazy.
I am writting an application using custom events, but as in QApplication::postEvent function, it's necesary to specify the target object.
As I understand, it's possible to post events to Qt's event loop with
QApplication::postEvent(obj_target, QEvent myevent);
This means that I'm trying to catch "myevent" event in obj_target an do some stuff.
But I need to post events without specify a target object, as QMouseEvent or QKeyEvent do
I mean, when clicking in a QMainWindow with a lot of buttons, how is that I can click
any button and that button is pressed?
What is the target object when the click event is posted?
It's possible to register objects to "listen" for a specific event?
I'm really confused, it's possible to post an event without specifying a target object?
Thank you very much in advance
There is no trivial way to post events "globally", as Dan has said. All of the event dispatching of native events is done by private Qt implementation code.
The important distinction is:
There are native messages/events, delivered by the operating system, usually received by a window-specific event loop.
There are QEvents.
Internally, Qt keeps track of the top-level Widgets (windows, really), so when it receives an event from the OS, it knows which window it should go to - it can match it using the platform window id, for example.
QEvent delivery makes no sense without a receiving object, since sending an event to an object really only means that QObject::event(QEvent*) method is called on that object. It's impossible to call this method without having an object instance!
If you want to synthesize a global key press or mouse click event, then you have to figure out what object the event goes to. Namely:
Identify what top-level window (widget) the event should go to. You can enumerate top level widgets via qApp->topLevelWidgets().
Identify the child widget the event should go to. If it's a keyboard event, then sending the event to currently focused widget via qApp->focusWidget() is sufficient. You need to enumerate the child widgets to find the deepest one in the tree that overlaps the mouse coordinates.
Send the correct QEvent subclass to the widget you've just identified. Events delivered to top-level widgets will be routed to the correct child widget.
When sending mouse events, you also need to synthesize relevant enter and leave events, or you risk leaving the widgets in an invalid state. The application.cpp source file should give you some ideas there.
This doesn't give you access to native graphical items, such as menus on OS X.
Please tell us exactly what you're trying to do. Why do you want to post a broadcast event? Who receives it? Since your own QObject-derived classes will receive those broadcasts, I presume, it's easy enough to use signal-slot mechanism. You'd simply connect(...) those receiver classes to some global broadcaster QObject's signal(s).
For this purpose, I have a specific singleton class which I call GuiSignalHub. It regroups all the application-wide signals.
Objects that want to trigger an application-level action (such as opening context help) just connect their signal to the GuiSignalHub signal. Receivers just connect the GuiSignalHub to their slot.