Problem: Main app using 3rd party libraries as base for most classes. These 3rd party libs include windows.h. Have DLL with descendant of CDialog in it. I'm told (MSDN) you can use a statically or dynamically linked Win32 DLL using MFC within a non-MFC program (the main program doesn't see the MFC). How? When I include the header for a class in my DLL (which at the moment contains nothing, was planned to contain my CDIalog), the main project won't build because it complains about including stdafx.h (I have afxwin.h included therein). If I try to leave out stdafx.h, of course the DLL itself won't build. So what do I need to do to create a header that can be included in my main project, has the exports that won't drag MFC into the main App, and so that the DLL will still build? Any help appreciated.

My suggestion would be pass a reference to the object and let the Dialog interrogate the object directly for the data. Why pass n parameters when half the raison d'etre for the object is the encapsulation of this data? Pass a reference. In fact, there are probably ways to display the data in a dialog in such a way (combined with a bright method or two in the CPerson object) such that you can change the internal data represented in the CPerson without having to modify the Dialog that displays it. One of the stratagems of the experienced programmer is to try to devise ways to insulate himself from changes in data structure within object classes - this tends to happen, and the less impact it has on code scattered across the project, the better.