Since I have had to work this problem, I've come up with answers to my own questions and thought I would share them. However, I am still looking for advice, as my answers might be wrong.
Answer to question #1 : Yes. Doing anything in an event-driven program that you know has the potential to lock the application is (most of the time) a bad practice.
Answer to question #2 : From what I've observed, a QNetworkRequest that has been posted generates three possible outcomes:
1) The request is honored, and the QNetworkReply that is returned has the results, or...
2) The request fails, and the QNetworkReply that is returned contains an error message, or...
3) Nothing is returned. No signals are generated. (This had occurred two separate times, and I am at a loss to explain why.)
I am still uncertain how to handle #3, but have come up with a solution for #1 and #2 as demonstrated by the following function:
void MainWindow
::PostQuery(QByteArray Query, NRMemFn SuccessFunction, NRMemFn FailureFunction
) {
QNetworkReply* p_reply = m_Manager.post(m_QueryRequest, Query);
connect(p_reply, &QNetworkReply::finished, [=](){ (this->*SuccessFunction)(p_reply); p_reply->disconnect(); p_reply->deleteLater();} );
connect(p_reply, static_cast<void (QNetworkReply::*)(QNetworkReply::NetworkError)>(&QNetworkReply::error), [=](){ (this->*FailureFunction)(p_reply); p_reply->disconnect(); p_reply->deleteLater();} );
}
void MainWindow::PostQuery(QByteArray Query, NRMemFn SuccessFunction, NRMemFn FailureFunction)
{
QNetworkReply* p_reply = m_Manager.post(m_QueryRequest, Query);
connect(p_reply, &QNetworkReply::finished, [=](){ (this->*SuccessFunction)(p_reply); p_reply->disconnect(); p_reply->deleteLater();} );
connect(p_reply, static_cast<void (QNetworkReply::*)(QNetworkReply::NetworkError)>(&QNetworkReply::error), [=](){ (this->*FailureFunction)(p_reply); p_reply->disconnect(); p_reply->deleteLater();} );
}
To copy to clipboard, switch view to plain text mode
This PostQuery function takes three arguments: a query and two pointers to member functions. The pointers to member functions are connected to the signals that the QNetworkReply will generate for cases #1 and #2. Lamba functions provide the needed "glue".
My Open function now just calls PostQuery with success and failure function pointers. Of course, this does not solve case #3; nor does it handle the (sub?) case of the results being delayed. (When you click Open, you expect to see something immediately, but the QNetworkReply is not guaranteed to be generated at any specific time -- or at all!)
Bookmarks