CompuServe Thread

MFC 2.0 will never be multi-threaded if it's based on the same internal premises that MFC 2.0 uses under DOS/Win16. I've dealt w/ these issues for A LONG TIME under NT with MFC 1.0 in the current SDK. Here's some stuff that might help you out (or hinder your use of MFC) First of all, MFC retains temporary lists of GDI objects like handles to DCs, Menus, etc. these lists are dealt with/cleaned up in OnIdle(). Well, if your main UI thread is OnIdle() but some other threads still using one of these, guess what your secondary threads referring to? JUNK, do to the fact that your primary UI threads got time to clean house! Second, MFC uses internal memory checking on it's linked list implementation of tying together all allocations to keep "integrity" within the application. Well, think about news and deletes on different threads. This linked list becomes all screwed up quickly. (ah, but yes you say, on a single processor box this will be quite rare as these operations are minimal… but in fact on an mulit-processor box you'll see this quite quickly!) You must DISABLE all debugging APIs in your application before any secondary thread is created or else you will pay. This can be done by setting a global variable afxMemDF=0, Third, MFC in it's exception handling uses ONE GLOBAL CONTEXT. So say you've got their TRY CATCH macros all over your code and then break some of these exceptions off into a separate threads. Well guess where your exception in Thread A occurs…..in Thread B if he runs the his try catch processing first EVEN THOUGH THE EXCEPTIONS IN THREAD A!!! Now try debugging where the true problem occured!!! Fourth, MFC assumes that you'll never want to see why the app really dies before he exists. I suggest you modify globally the DebugAfxTerminate() call with a call to DebugBreak() in NT (if DEBUG is defined), so that your [>> Continued in next msg] There is 1 Reply.