Hello,
I am writing an MFC application (a database front-end). At one point, the user must perform a potentially lengthly database operation.
I think that the user should have a responsive user interface, and a cancel button. The database API and database server I'm using, pqxx and PostgreSQL respectively, both heavily emphasize transactions, much like oracle. They have practically no overhead, I'm assured. This lends itself well to a cancel button for large transactions.
The way to have a cancel button and a responsive user interface is obviously to use a second thread.
I've looked into MFC threads. There are two types: A user interface thread, and a worker thread. Worker threads seem less complicated, but do not allow user input. All I want to do is do my database transaction, and update a few of my original thread's dialog items: a progress bar, and some static text. I think that this should, if possible, be done in the second thread, because I can just put the code that changes the static text immediately before the operation to let the user know the operation is in progress, do the operation, and change the static text to report that the operation was completed. I guess I'd do this through a pointer to the first thread's CDialog .No user input is processed.
I guess it's up to the first thread's event loop to update it(so the static text and so on changed by the second thread is re-painted). I'm not sure of the whys and wherefores of this, so I'm being very presumptuous as to how this is going to work.
The cancel button causes the first thread to change a bool to false. The second thread will check this bool in its database API loop, and break out if it is false.
My question is, is this approach feasible?
Thanks a lot,
Sternocera
Start Free Trial
