Help needed *ASAP* on MFC UI-threads

[HellDiver]

I need to write an application, featuring several UI threads, each obtaining large arrays of numbers, processing them, displaying to user, and letting the user to fiddle with displayed data. All that while the main program keeps ticking.

HOW DO I CORRECTLY IMPLEMENT UI-THREADS ?

And I mean a pretty detailed answer. I wrote some worker threads, but MFC UI-threads seem to be entirely different. The literature seems to cover worker threads in detail, but no UI-threads... (probably because they're rather MFC specific - too much fuss under Win32 API)

* Can I access methods and properties of classes running as separate threads from OTHER threads ?

* How can I transfer large quantities of data in TWO directions (to the UI-thread which is not the main thread, and from it)

* What methods should I add to the CWinThread derived class?

* Can anyone throw me a sample of UI-thread multithreaded app?

I need to write an application, featuring several UI threads, each obtaining large arrays of numbers, processing them, displaying to user, and letting the user to fiddle with displayed data. All that while the main program keeps ticking.
Do you really want UI threads? If you are processing data, just use worker threads.

But if you really want to use UI threads:
CWinThread is a good way to go.
* Can I access methods and properties of classes running as separate threads from OTHER threads ?
Yes. As long as you have a valid reference to the class you want to access.
Keep in mind that each thread has its own stack.
* How can I transfer large quantities of data in TWO directions (to the UI-thread which is not the main thread, and from it)
You can use PostThreadMessage to pass data (pass a pointer to data, or classes)
to any thread.
Again, keep in mind that each thread has its own stack.
* What methods should I add to the CWinThread derived class?
I'd stick with only those methods you need to completely implement
the thread class. Leave extra data processing functionality to other
classes. Don't make the CWinThread derived class an all-encompassing class.
i.e. use good OOP sense;-)
* Can anyone throw me a sample of UI-thread multithreaded app?
Yes, but it's easier for you to look in the MSDN
( http:// http:\\msdn.microsoft.com ).

[HellDiver]

Thanks for the rather complete answer.

> Do you really want UI threads? If you are processing data, just use worker threads.

That's the thing. I'm not JUST processing data. Rather, user is constantly demanding a new representation of data which must be recalculated, and all this while, the program must keep working in near-RealTime mode acquiring data from some input devices. Blocking user input in any one of the windows would be inacceptable.

Now comes another question:
* Is there any particular problem with shoving my UI-thread up ... No, not that place, a DLL. So that any reasonably OOPed program might use my UI-threads for it's visual representation of data?

there should be no problem at all in moving any code to a DLL