Converting a Console Program into an MFC app (Thread issues) (Pleora SDK)

Question

Back to stackoverflow with another question after hours of trying on my own haha. Thank you all for reading this and helping in advance.

Please note the console program has following functionalities:

1. connect to a frame grabber
2. apply some configs
3. store the incoming data (640 * 480 16-bit grayscale imgs) in a stream of buffers inside a while loop
4. Exits the while loop upon a key press.
5. disconnect from device

And I'm only adding the displaying the images functionality on the MFC GUI app. In short,

i) Converting a console app to an MFC app (dialog based)

ii) decided to use thread for displaying images, but DK how to properly exit from thread when there are certain tasks to be done (such as call disconnectFromDevice(); freeBuffers();, etc) before exiting the thread.

iii) have tried making the while loop condition false but didn't work ( I actually want this to be a callback function that's called repeatedly but IDK how to implement it inside a thread)

iv) forcing AfxEndThread didn't work and it's not even the way it should be done (I think).

So my question is,

1. Are you supposed to use a while loop to excuete a certain job that should repeatedly be done? If not, do you have to implement a callback inside a thread? Or use Windows message loop? Why and how? Please provide a hello-world-like sample code example

(for example, you are printing "hello world" repeatedly inside a thread with a condtion in an MFC GUI app. How do you update or check the condition to end the thread if you can't just AfxEndThread() inside the threadproc)

2. If it's ok with a while, how do you exit from the while loop, in other words how do you properly update the exit condition outside the thread the while loop's in?

Please refer to the source code in the provided link

ctrl+F OnBnClickedConnectButton, AcquireImages and OnBnClickedDisconnectButton

https://github.com/MetaCortex728/img_processing/blob/main/IR140Dlg.cpp

Answer 1

Worker threads do not have message-queues, the (typically one and only) UI one does. The message-queue for a thread is created by the first call of the GetMessage() function. Why use messages to control processing in a worker thread? You would have to establish a special protocol for this, defining custom messages and posting them to the queue.

Worker threads can be implemented as a loop. The loop can be terminated based on various conditions, like failures to retrieve any data or request from the user. You can simply exit the thread proc to terminate the thread's execution. If the thread doesn't respond it may have stuck (unless it performs a really lengthy operation) and the UI thread must provide some mechanism to kill it. That is first request termination and if it doesn't respond within some set time then kill it.

The condition mechanism to terminate should best be some synchronization object (I would recommend a manual-reset event), interlocked variable or a simple boolean which you should access and set using a critical section.

Some considerations:

• You pass a parameter block to the thread. Make sure that it remains alive throughout the thread's lifetime. For example, it should NOT be a local variable in a function that exits before the thread's termination.
• The loop must be "efficient", ie do not loop infinitely if data are not available. Consider using blocking functions with timeouts, if available.
• Resource management (eg connecting/disconnecting, allocating/releasing etc) should best be performed by the same thread.

An alternative implementation can be APCs. Then the thread's proc function is a while(!bTerminate) { SleepEx(INFINITE, TRUE); } loop, and other threads issue requests using a the QueueUserAPC() function.

The AfxEndThread(0) call in OnBnClickedDisconnectButton() is wrong, it terminates the current thread, which in this case is the main (UI) thread. Check the documentation.

A sidenote, my suggestion about the project type is not a dialog-based application but instead a normal MFC application without a document class (uncheck the Document/View architecture support option), as it offers features like menus, toolbars and the like, and most importantly the ON_UPDATE_COMMAND_UI handlers.