Quote Originally Posted by soupfly View Post
In theory I wanted to be able to write something like this for each of the functions:
That does not really fit your application.
Your current backend is already asynchronous and any future backend has a likely chance of also being asynchronous (e.g. network based).
As a GUI you are not in a situation where you can just block and wait for response, that would result in bad user experience.

Quote Originally Posted by soupfly View Post
Unfortunately QProcess()->read() seems to never return a buffer.
It will if there is something to return.
Which is not likely in the pseudo code above since that would require that the data has been written to the child process, then your process having been suspended long enough for the child to process and write back before your program has had a chance to resume and call read.

Not impossible, but highly unlikely.


Quote Originally Posted by soupfly View Post
Because I never received output from the QProcess()->read() call I instead had recvCommandOutput() insert results into a results data structure. The results output have a transaction ID that I can set when I make my query
Good, that is what I meant with making request and response associated to each other.

Quote Originally Posted by soupfly View Post
The issue with this is that the polling will loop forever. recvCommandOutput() is never hit once I start looping. Again I believe this is because I have a single MainWindow thread.
It is less a matter of having a single thread but exclusively using the single thread for one purpose (looping) so it can't do anything else (like processing events for QProcess).
Basically you've deadlocked yourself.

Quote Originally Posted by soupfly View Post
Reading between the lines in both of your messages I now believe I am making a mistake in attempting to make the asychronous calls appear sychronous to the GUI.
Definitely. A GUI should never assume that I/O is instantaneous, especially nothing that will require communication with a different system (via network, cable, etc).
It is very rare that such communication has deterministic and guaranteed response times that would make blocking the UI a viable approach.

Luckily most I/O in Qt is handled asynchronously so you don't have to do anything special (e.g. threads) to make it non-blocking.

Quote Originally Posted by soupfly View Post
Do you know if there is something similar for command line app output?
No, as application output is very application specific, i.e. how the application separates output of different responses, etc.

Quote Originally Posted by soupfly View Post
Also, how would you handle the case where there are multiple StockQuote and StockVolume windows open?
The window just needs to know which StockQuote object to work with.
In the QNAM example it would just need to know which QNAM to work with.

Quote Originally Posted by soupfly View Post
Again only one window should receive the output.
Since you can associate responses to requests, you just need to pick the right "reply" handler to pass it to, like QNAM knows which QNetworkReply to pass incoming response data to.
Each window only knows its reply object, so it won't be confused by other windows' data.

Cheers,
_