Details
-
Bug
-
Resolution: Cannot Reproduce
-
Not Evaluated
-
None
-
5.15.2
-
None
Description
Inside the paintEvent of a QWidget I instructed a QNAM instance to `get` something.
None of the connected slots were ever called.
It doesn't matter whether the QNAM instance was created in the QWidget's constrcutor or inside the paintEvent, whether `this` was passed to the QNAM constructor or not, whether a timeout was set or not, whether the slot was connected to the `finished` signal inside the QWidget's constructor or to the returned QNetworkReply's signal and this also for the 2 QNetworkReply error signals.
The behavior I observe is occuring and remedied like here: https://forum.qt.io/topic/5186/how-to-synchronize-qnetworkaccessmanager/11
Thus I believe it is either a bug or a design to be documented.
The documentation in general for Signals and Slots, Event System, Paint System and the specific documentation for paintEvent and QNetworkAccessManager do not state that a signal-slot driven Object does not work inside an event callback, do not state that an event callback does not execute in an event loop necessary for signal-slots to work and do not state that QNAM->get does not signal any slot when called inside the paintEvent of a QWidget.
If the observed behavior is by design, please state such in the general and the specific documentation! Also then add the only 2 possible solutions to get QNAM to work from a paintEvent: QTimer within the main event loop or a delegated thread (not a subclassed thread, inside those run method the `get` lives in the new thread but the parent of QNAM lives inside the constructing thread and moving `this` to the `currentThread` before constructing QNAM had no effect): https://mayaposch.wordpress.com/2011/11/01/how-to-really-truly-use-qthreads-the-full-explanation/