Multithread Questions

[Steve McNeese]

Can somebody explain the difference between worker and user-interface threading. Specifically, does "user-interface" mean that it will accept user input or write to a control on a user interface? In my scenario, I want to create a thread to periodically update a listview control on a pane of a splitter window from a CRecordset. The user-interface will also have a refresh button to manual force the update of the listview. I though that I could use a worker thread to update the listview every so many seconds or minutes and have the refresh button send a message to the thread to handle the "manual" update. Does this sound like the correct thing to do or am I not getting something?

Thanks for any suggestions or information! :)

Steven M. McNeese
steven.mcneese@boeing.com

Hi,

The big difference between an UI thread and a worker thread is that a UI thread has its own message queue, and can therefore receive messages. A worker thread
is basically just a function that runs in another thread. It can send messages, but not recieve them.

You could set up a UI thread (derived from CWinthread... see the docs), and pass messages back and forth.

Alternatively, you could use a worker thread with CEvents to signal it. CEvents work like a flag, you can switch its state in one thread and handle it in another (i.e. if the user pressed "Refresh" in the view class in one thread, you could set a CEvent. In your worker thread you can include a check of this CEvent in a loop, and if it is set, manually update the List.

Just be careful to protect any globals with a Critical Section.

HTH,

Harvey Hawes

[Aureliano Lopez]

You can think that the worker thread will also receive messages if it had a queue (not necessarily a Windows Message Queue), and it will just wait for actions to "work" on. In the given case, for example, a request will be stored in the queue and the Event that Harvey was talking about will be signaled, waking up the worker thread to do its work. Basically, you don't want to do lenghly actions in the thread that needs to handle the user inputs, because that would not make him happy.

The advantage of having an action queue, is that you can handle multiple requests.

Aureliano


Aureliano

Why do you want to do this in a Multithreaded way? A much easier way would be to use a timer. SetTimer() with a specific timerID an in OnTimer() you can handle thouse TimerID`s

[Steve McNeese]

I am using a thread because of the time that it takes to read the recordset and populate the listview. The user interface has several tabs of CViews that can be selected and accept input at any given time. The displaying of data in the listview could come from something they did on one of the tabs or from anybody else running an instance of the app. With a thread, their input process is not hindered in any way.

P.S. I did get this working by keeping a pointer to the view in my main application class. The worker thread accesses controls on the view through this pointer. Works great! No collisions with the user interface thread, even when data is selected from the listview control.

Thanks.

Steven M. McNeese
steven.mcneese@boeing.com