MFC Extension DLL's
Robert H. Mowery III -- rmowery@csci.csc.com
Wednesday, October 23, 1996
Environment: VC++ 4.2, Win 95, NT 4.0
I have been working on some MFC extension DLL's and have found that these
are REALLY cool. I am hoping there are a few people out there who have
some
experience with these and could lend some advice regarding pitfalls and a
few other questions. There is very little I have found written about the
rules governing extension DLL's so I am guess that MS expects us to learn
by trial and error. The only real reference I have found other then the
DLL Husk sample is the information in Scot Wingo's book on "MFC Internals".
Mike Blaszczak has some brief mention in his
book. Anyway here are a few questions and any feedback would greatly be
appreciated.
1) What is the best way to handle communication between two MFC Extension
DLL's?
2) How is the memory handled for the DLL's?
3) What is the best way to handle callbacks and expose them in the MFC
Extension DLL's?
4) When does one reach a point of deciding to go the COM instead of
extension DLL's?
Thanks for any advice, pointers, or other form of help.
-
Robert H. Mowery III
SofTech Multimedia, Inc.
79 Springfield Avenue
Rochester, NY 14609-3607
Phone: (716) 288-5830
Fax: (716) 288-5288
Automated Sales: (800) 624-3197
Web: http://www.stmm.com
Email: rmowery@stmm.com
Erik Funkenbusch -- chucks@isd.net
Friday, October 25, 1996
----------
> From: Robert H. Mowery III
> To: mfc-l@netcom.com
> Subject: MFC Extension DLL's
> Date: Wednesday, October 23, 1996 9:53 AM
>
> Environment: VC++ 4.2, Win 95, NT 4.0
>
MFC Extension DLL's really aren't that different (in most ways) from normal
DLL's, the only difference is that they allow mfc to interact across module
(DLL) boundaries where they wouldn't normally be able to with user dll's.
> 1) What is the best way to handle communication between two MFC Extension
> DLL's?
There is no communication, the EXE makes direct calls into the extension
DLL and the extension DLL can gain access to the EXE through common methods
(AfxGetApp, AfxGetMainWnd, GetActiveView, whatever..)
> 2) How is the memory handled for the DLL's?
Memory is allocated by the application (exe) for extension dll's. This is
different from user dll's.
> 3) What is the best way to handle callbacks and expose them in the MFC
> Extension DLL's?
The same way you handle them in a single monolithic application.
> 4) When does one reach a point of deciding to go the COM instead of
> extension DLL's?
Com and Extension DLL's are two seperate things. if you want the features
COM gives you, you go COM, if you don't, and need interaction between DLL's
in MFC, the go extension, if not.. go USER..
Roger Onslow/Newcastle/Computer Systems Australia/
Tuesday, October 29, 1996
>From: chucks @ isd.net ("Erik Funkenbusch")
>> From: Robert H. Mowery III
>> 4) When does one reach a point of deciding to go the COM instead of
>> extension DLL's?
>Com and Extension DLL's are two seperate things. if you want the features
>COM gives you, you go COM, if you don't, and need interaction between DLL's
>in MFC, the go extension, if not.. go USER..
There are 3 (roughly) types of DLL.
USER
MFC Extension
COM
MFC extension is better then USER at encaspulating C++ classes (especially
those written in MFC)
However, COM is an even *better* way of putting C++ classes in a DLL. Its spec
meshes exactly with the way C++ virtual classes are stored. It makes
maintenance and extension of classes in DLL's easier to implement without
breaking old code. It encourages you to have well-defined and documented
interfaces. It is very efficient (calls to a COM DLL are simply virtual
function calls). I think I'd use COM as a way of implementing any non-trivial
C++ class in a DLL.
The only catch is that you cannot put a class which is derived from an MFC
class directly in a COM DLL (unless derived from one of the many COM classes in
MFC). However, you can USE MFC to implement your DLL.
I think a lot of people hear "COM" or "OLE" and think there is some sort of
magic involved and that it is too complex to be understood. Now, it is true
that OLE is a complex beast (that is implemented in COM), but COM itself really
isn't. It is basically a very simple, efficient, extensible and maintainable
way of putting C++ classes in a DLL. You use COM all the time without knowing
it (eg IStreams). It's like looking at MFC and says, because it is built as a
lot of C++ classes, that you should avoid using classes in C++ because they are
too complex.
There is an article on MSDN (can't recall the title) that shows how you can go
from a simple standard DLL (and the inherent problems that has with C++) and by
step-by-step solving those problems, you end up with COM. It is a very good
article and explains very clearly how COM works and demystifies the whole
thing. (when I find my MSDN disk and look it up, I'll let you know)
Also look at the ATL (ActiveX Template Library) which is a wizard (and C++
library) for creating COM DLL's.
PS: Don't be put off by the word "ActiveX" -- ActiveX really has *nothing* to
do with the internet, it is simply the new name for OLE. However, the new OLE
spec has been enhanced so that it will work better in a network environment,
but ActiveX does NOT *require* internet support or a network environment.
Current OLE controls and documents etc are all perfectly good ActiveX
components and documents - the only thing that changes is that you say
"ActiveX" where you used to say "OLE". ActiveX specs actually allow you to
write simpler and less code when implementing OLE/ActiveX components.
Roger
| Вернуться в корень Архива
|