How to synchronize QNetworkAccessManager ?
-
As long as you can't provide a minimal compileable example the bug is on your side. Prove me wrong.
-
well, likely not. not much can be done wrong using QNAM, particularly after having combed through the documentation. I found many StackOverflow posts exist mentioning an unidentified issue. Eg. https://stackoverflow.com/questions/2776640/qt-qnetworkaccessmanager-does-not-emit-signals . Identifying the real culprit from those posts is difficult. One such SO post let surmise QNAM is created in a paintEvent (a globe map service url was used). I managed to find this qt.io post. The issue existed, the issue exists. Something triggers the issue in Qt. (Or it is by design but still something adds to it.) I haven't found it yet. Of course, until you haven't proof -- and even if you have -- it's up to your desire and interest to look into QNAM.
-
well, likely not. not much can be done wrong using QNAM, particularly after having combed through the documentation. I found many StackOverflow posts exist mentioning an unidentified issue. Eg. https://stackoverflow.com/questions/2776640/qt-qnetworkaccessmanager-does-not-emit-signals . Identifying the real culprit from those posts is difficult. One such SO post let surmise QNAM is created in a paintEvent (a globe map service url was used). I managed to find this qt.io post. The issue existed, the issue exists. Something triggers the issue in Qt. (Or it is by design but still something adds to it.) I haven't found it yet. Of course, until you haven't proof -- and even if you have -- it's up to your desire and interest to look into QNAM.
@uani said in How to synchronize QNetworkAccessManager ?:
Identifying the real culprit from those posts is difficult.
Yes, and this thread is no different. Diagnosing the problem with your code requires understanding the entire problem space and eliminating possible causes from most likely to least likely. If you, the OP in this thread, and the poster in your link will not engage with that process then you are going to have to live with the result.
-
I can't say I appreciate your attitude.
having said that - it would not hurt if you read with a modicum of understanding. If more experienced developers tell you that your design pattern is substandard then perhaps take it at the face value?I used to deal with a use case where I had to design and write client-facing program able to manipulate pdf documents over the WebDAV protocol, enabling users to download and display/print hundreds of small, 1-2 paged files at the time.
I did it all using QNAM since it is more than sufficient for the task.
Thinks to consider:- QNAM has a limit for
simultaneous
tasks being processed, which - as stated - is six. - That means exactly what it says. You can queue/fire 500 downloads in one series but they will be processed in batches of six.
- As QNAM is asynchronous you can't expect downloads to arrive in order they were called. Obviously, that depends on many factors but my experience just confirms that.
- Idea of calling QNAM from the paintEvent is pure bonkers. That's not what it was designed to do in the event chain event.
- If you don't have any other trigger (system event, any other async signal/slot to rely on) at least put the fetch loop on timer slot with a second or so delay. Timer can be started from the MainWindow constructor as the last entry, after QNAM and all the connections to it have been done. This is to allow main loop to spin up properly.
- if you need to cross-reference requested URIs with the downloaded data (for the purpose of assigning proper file names let's say) you have to keep track of that yourself. The simplest way is QStringList or QStringListModel, where you can keep called URIs and then remove them once the finished() signal passes you reply object. You do have to remember to deleteLater() that reply. Also, in case of a huge number of files memory issues might arise (I remember stress testing my program with 500.000 files in one go, that's where disk cache for the model would come in handy - but YMMV).
- QNAM has a limit for
-
which design pattern?
"more experienced" : i refrain from details.
I have posted no code .
It has been established:
When paintEvent is not done QNAM signals no slots.
Whan paintEvent is done, QNAM signals slots.
An unknown factor elicits this. **Thanks to me, Qt now knows* about this. It is up to their care and honor for their product to investigate this now or feel not so and wait.
I thank you for your points.
I read about point 1. The issue is not a matter of not receving everything. It is a matter of any reaction at all: timeout, error or data.
Point 4: the data is decided at paint time and the source set is too large to be in local space.
I have moved on and decoupled code for painting received data from requesting data already. The issue at hand is not one I need solving.
Trying to remember how I originally wrote the code i might have waited in a loop in paintEvent for threads to complete drawing to intermediate images.**
- by the bug report which contains a path for documentation
** The app main event loop (I remember event loops are for signal and slots, I don't remember how they work with Qt's event system) might have been blocked by painting for signal processing which could explain the issue.
If ** is the reason, the bug is no bug and perhaps the documentation needs no update. This would have been something an attentive reader could have figured and not write haughty responses.
-
which design pattern?
"more experienced" : i refrain from details.
I have posted no code .
It has been established:
When paintEvent is not done QNAM signals no slots.
Whan paintEvent is done, QNAM signals slots.
An unknown factor elicits this. **Thanks to me, Qt now knows* about this. It is up to their care and honor for their product to investigate this now or feel not so and wait.
I thank you for your points.
I read about point 1. The issue is not a matter of not receving everything. It is a matter of any reaction at all: timeout, error or data.
Point 4: the data is decided at paint time and the source set is too large to be in local space.
I have moved on and decoupled code for painting received data from requesting data already. The issue at hand is not one I need solving.
Trying to remember how I originally wrote the code i might have waited in a loop in paintEvent for threads to complete drawing to intermediate images.**
- by the bug report which contains a path for documentation
** The app main event loop (I remember event loops are for signal and slots, I don't remember how they work with Qt's event system) might have been blocked by painting for signal processing which could explain the issue.
If ** is the reason, the bug is no bug and perhaps the documentation needs no update. This would have been something an attentive reader could have figured and not write haughty responses.
@uani said in How to synchronize QNetworkAccessManager ?:
It is up to their care and honor for their product to investigate this now or feel not so and wait
Again: as long as you can't provide a minimal, compilable example nothing will happen and the bug will get closed soon.
-
@artwaw said in How to synchronize QNetworkAccessManager ?:
your attitude
I thanked you for your attempts at contributing help, Idiot !
your attitude. what a wickedness. what a disgrace .
@Christian-Ehrlicher said in How to synchronize QNetworkAccessManager ?:
Again: as long as you can't provide a minimal, compilable example nothing will happen and the bug will get closed soon.
Again: It is up to your care and honor for your product to investigate this now or feel not so and wait
-
@artwaw said in How to synchronize QNetworkAccessManager ?:
your attitude
I thanked you for your attempts at contributing help, Idiot !
your attitude. what a wickedness. what a disgrace .
@Christian-Ehrlicher said in How to synchronize QNetworkAccessManager ?:
Again: as long as you can't provide a minimal, compilable example nothing will happen and the bug will get closed soon.
Again: It is up to your care and honor for your product to investigate this now or feel not so and wait
@uani said in How to synchronize QNetworkAccessManager ?:
I thanked you for your attempts at contributing help, Idiot !
your attitude. what a wickedness. what a disgrace .
Please follow the code of conduct: https://forum.qt.io/topic/145364/forum-guidelines-code-of-conduct
Your wording is inappropriate, please stop it.