In QWebView, which signal is emitted while the DOM stucture of the page changes? For example ajax form can generate new DOM elements on the existing page without reloading the URL or something else.
No signal is emitted for DOM changes specifically. One way to solve that problem was that when I knew when that event should happen, I started a QTimer immediately after the loadFinished signal was emitted when the page was loaded, and connected it's timeout signal to a function which would emit the loadFinished signal again. The QTimer's timeout value was the time I knew should pass when the change will occur.
Related
Consider this situation:
For a button on a widget: if there is a chance that the button's clicked() slot is delivered (processed) after the widget (that contains the button) gets hided by explicitly calling hide()?
For instance, suppose that there is a timer, and in its timeout() slot, widget.hide() gets called. Coincidentally, The user clicks the button just at the same time time is up.
The question is: Is there a chance that the button's clicked() slot get called after timer's timeout() slot (which hides the widget that contains the button)?
No, the main thread in synchronous respect the GUI actions, so you cannot change the visibility of an object living in the main thread (like your QPushButton) exactly at the same time an user is clicking on it. Also, unless you 're on a multithread app with different events loops, your QTimer will be processed in the main thread too, so it is synchronous respect the UI. In few words: you may get a millisecond concurrence (clicking immediately before hiding it), but not actual parallelism.
If you care about this, maybe you can set a small delay before actually processing the click, just to check if the button was clicked but immediately hidden. In this case you can ignore the user input but it would be confusing. Another option would be to delay hiding the button if it was clicked, so the user doesn't get the wrong visual feedback.
I have a question about Qt and its signals/slots mechanism.
I have created a custom widget and in that I have created a custom SIGNAL (ShowMessage). This signal is connected to a SLOT, which displays the message (along with the specified timeout) in my main window's status bar.
Now, I have an operation in my class that takes a long time to execute, and it's blocking the UI. I was hoping to emit my signal before starting the operation and when it's finished, emit it again to update the status bar; something like this:
emit ShowMessage(message, timeout);
// Do the long operation
emit ShowMessage(newMessage, timeout);
But my problem is that it seems that Qt waits until the whole operation is finished, and only updates the status bar with newMessage.
Is there a way to somehow "force" immediate processing of my signal, because if I want to resort to threads, then my life will get much more complicated!
Is there a way to somehow "force" immediate processing of my signal
Yes, there is. :-).
After you show your first message, call QCoreApplication::processEvents(). This forces all pending events to be processed at the point of call. For example,
emit ShowMessage(message, timeout);
QCoreApplication::processEvents();
// Do the long operation
emit ShowMessage(newMessage, timeout);
I have set a break-point on a slot method and started up gdb to debug my Qt5 application. I would like to know from where in the code this slot gets called from (via the Qt5 signal system).
My naive approach ends in suspension of the program at the break-point, but the stack-trace is all Qt5 internals with no clue as to which part of the program actually sent the signal to this slot (or weather it was a queued or direct invocation:
Is this at all possible? How?
Thanks!
UPDATED
The only time you won't see the signal caller in the stack backtrace is when the connection is queued.
For direct connections you should see something like this:
0 Receiver::baz() <-- slot function that received the signal
1 Receiver::qt_static_metacall()
2 QMetaObject::activate()
3 Sender::bar() <-- function with the name of the signal
4 Sender::foo() <-- function that called emit
5 QWidget::event()
...
For queued connections, the situation is more complicated. But you can add the following to your slot:
QString __sender__ = sender()->metaObject()->className();
This will give you class name of the object, which had sent the signal. You can make it into a macro and sprinkle in your code.
Alternatively, if you have multiple objects of the same class and you need to know which one had sent the signal, you can use the sender() function and compare object address, etc.
Guessing that the signal and slot are connected through a Qt::QueuedConnection, I usually put a breakpoint in every emit of a signal connected to that slot in that case, if there aren't too many of them.
If you otherwise temporarily make it a Qt::DirectConnection (or Qt::BlockingQueuedConnection if across threads) you should be able to see the emission in the stack trace of the emitter thread, waiting for the slot to complete.
I'm attempting to implement a simple, lightweight system for recording Qt GUI events and playing them back from a script. I thought this would be fairly straightforward using the magic of Qt's event system, but I'm running into a problem I don't understand.
Here's quick summary of what I'm doing:
RECORDING:
I use QApplication.instance().eventFilter() to capture all GUI events I'm interested in* and save them to a Python script, in which each step looks something like this:
obj = get_named_object('MainWindow.my_menubar')
recorded_event = QMouseEvent(2, PyQt4.QtCore.QPoint(45, 8), 1, Qt.MouseButtons(0x1), Qt.KeyboardModifiers(0x0))
post_event(obj, recorded_event)
PLAYBACK:
I simply execute the script above, in a worker (non-GUI) thread. (I can't use the GUI thread because I want to keep sending scripted events to the application, even if the 'main' eventloop is blocked while a modal dialog eventloop is running.)
The important stuff happens in my post_event() function, which needs to do two things:
First, call QApplication.postEvent(obj, recorded_event)
Wait for all events to finish processing:**
Post a special event to the same eventloop that obj is running in.
When the special event is handled:
Call QApplication.processEvents()
Set a flag that tells the playback thread it's okay to continue
After the second part is complete, my expectation is that all effects of the first part (the recorded event) have completed, since the special event was queued after the recorded event.
The whole system mostly seems to work just fine for mouse events, key events, etc. But I'm having a problem with QAction handlers when I attempt to playback events for my main QMenuBar.
No matter what I try, it seems that I can't force my playback thread to block for the completion of all QAction.triggered handlers that result from clicking on my QMenu items. As far as I can tell, QApplication.processEvents() is returning before the QAction handler is complete.
Is there something special about QMenu widgets or QAction signals that breaks the normal rules for QApplication.postEvent() and/or QApplication.processEvents()? I need a way to block for the completion of my QMenu's QAction handlers.
[*] Not every event is recorded. I only record spontaneous() events, and I also filter out a few other types (e.g. Paint events and ordinary mouse movements).
[**] This is important because the next event in the script might refer to a widget that was created by the previous event.
I think your problem might best be served by using QFuture and QFutureWatcher (that is, if you're using the QtConcurrent namespace for threads, and not QThreads). Basically, the Qt Event handling system does NOT necessarily handle events in the order they're posted. If you need to block until a certain action is completed, and you're doing that action in a separate thread, you can use the QFuture object returned by QtConcurrent::run() with a QFutureWatcher to block until that particular thread finishes its processing.
Something else to consider is the way you handle events. When you use QApplication.postEvent(), the event you create gets added to the receiver's event queue to be handled later. Behind the scenes, Qt can reorder and compress these events to save processor time. I suspect this is more your problem.
In your function which handles playback, consider using QCoreApplication::processEvents(), which will not return until all events have finished processing. Documentation for QCoreApplication is here.
QMenu widgets and QAction signals are a special case. QMenu has an exec() function, normally used for popups. I suspect (but I don't know for sure) that QMenuBar would use this mechanism when it opens a regular pull-down menu. The docs are not clear about this, but Menus act a lot like dialog boxes in that they block all other user activity - how would Qt do this except by giving menus their own event loop? I can't fill in all the blanks from the information in your post, but I don't see how your playback thread would cope with a new event loop.
I'm using a QSlider (v4.6) for input as well as to provide feedback to the user. For the feedback I will be calling the setValue method. I'm trying to find a signal that will fire only if the user modified the value. The valueChanged signal fires when the user changed the value as well as when I call setValue. sliderMoved only fires when the user drags the slider (not when using the keyboard). I checked the API docs and can't seem to find anything. Am I missing something? This seems something that would be common. If there is no other signal, how would you recommend that I simulate this functionality? Should I set a flag before calling setValue, disconnect and reconnect the signal every time I call setValue...?
Good question, I checked the API and also couldn't find a signal that would be triggered only if value was modified by user. The workaround you proposed may be the only option, just keep in mind that you don't have to disconnect / connect all signals, just use QObject::blockSignals method:
slider->blockSignals(true);
slider->setValue(x);
slider->blockSignals(false);
Hope that helps.