Ok, so the thread is merely obtaining the information and being passed elsewhere for updating the UI? This would explain why the for loop attempt failed. So, I must look for the area of the code where the data is drawn is your suggestion?
Its easy. Inside your program every window belongs to a thread - the thread that created the window (note that in a normal program every window is created by a single thread). That thread has a message queue. Every time you do something to the window - click on it with the mouse, request redrawing part of its client area - a message for that window is put in the message queue of the thread that handles that window. The gui thread should remove messages and process them in a loop (this is called the main message loop: GetMessage/DispatchMessage funcionts). In your case MFC does this for you, in pure win32 you do that for yourself. The window messages (WM_LBUTTONDOWN, WM_CLOSE, WM_PAINT, etc...) are also messages that come from that message queue, and when the gui thread encounters such a window message it dispatches that to the windowproc of the right window. OK, how is this related to worker threads? Actually message queues are one of the best things to use as inter-thread communication and fortunately this thread-message queue is thread safe, you can put a message to it from any other thread. For example you can put a window message into the message queue of the gui thread by calling PostMessage() or SendMessage() form your worker thread. Both of these functions put a message to the message queue of the gui thread but PostMessage() returns immediately while SendMessage() blocks the execution of the caller thread and returns only after the gui thread has processed the message. OK, but where to send the message, and what message??? You should define your own window messages by starting from the WM_APP constant. You define for example WM_APP+0 and WM_APP+1 and so on as your thread messages. With PostMessage() and SendMessage() you can send these custom messages to your main window and you can also specify 2 integer parameters: wParam and lParam (lParam is somtimes used as a pointer). For example when you are copying a big file on the worker thread and the percentage counter changes you can use PostMessage() to send a WM_APP+0 message with a wParam=percentage parameter. In your main window you handle the WM_APP+0 message (on your gui thread) and update your progressbar accordingly. Note that we used PostMessage() that put the message to the queue of the gui thread for later processing and PostMessage() returned immediately without unnecessarily waiting for the actual processing of the message on the gui thread (and the progressbur update) so as to prevent slowing down the worker thread. No need to wait for that progressbar update on the gui thread! A codeproject article that demonstrates the use of these thingies with MFC: Synchronization in Multithreaded Applications with MFC[^]