Does anybody know if MFC40.dll (MS Visual C++ file) should be distributed
with VB4.0 Pro apps which use the Sheridan 3D control? (I mean projects
in VB4.0 32-bit which contain the THREED32.OCX control).
 Mr/s Wizard lists the file as dependency of THREED32.OCX, but I am not
convinced (I am not making use of the control's custom property).
TIA.

Nonetheless, you're still using the control.  If it was written using
MFC and is dependent on some of the functions in the MFC DLL, you need
to include it in your distribution.  Of course, this is just theory.

George

===============================================================================
 George R. Torralba              xxxxxxxxxxxx                  Batang Cebu!!!
 Seattle, Washington             206.241.2801              MIME mail accepted
===============================================================================

Here are the DLL'd that Threed32.OCX is dependant on:

MFC40.DLL       MSVCRT40.dll    KERNEL32.dll
USER32.dll      GDI32.dll       ADVAPI32.dll
OLE32.dll       OLEAUT32.dll

Of these USER32, OLE32, GDI32, KERNEL32,ADVAPI32 are part of the NT/win95 OS and do not need to be shipped with VB4.0 (32)
appications

Here is some more info about DLL dependancies from Symantic C++ 7.2 (an OCX is a DLL with and OLE 2.x wrapper)

If both a DLL and an application want to use MFC, then they will both have a copy of the MFC library statically linked into
them. In fact, the versions of the libraries will be different. The application uses one of the standard versions of the MFC
library (depending on the memory model, say 'mafxcw.lib'), while the DLL uses a special version of the MFC ('lafxdwd.lib').
This has several advantages:

 the application using the DLL does not have to use MFC or, for that matter, it does not have to be a Visual C++
application.
 the memory model of the application can be different from the DLL. For example, MFC user DLLs (_USRDLL) are large model,
but the application using the DLL can be medium model.
 the size of the DLL depends only on those MFC and C runtime routines that are used and linked by the linker. Therefore, the
size of a _USRDLL version DLL is only slightly bigger than the exact same code in a large model application.
 there are no problems with classes changing underneath you. Your DLL design exports only those interfaces you wish it to.
 if both DLL and application use MFC, there are no problems with the application wanting a different version of MFC than the
DLL (or vice versa). Since the MFC library is statically linked into each DLL or EXE, there is no question about which
version you have.

 Thanks to both of you. actually our news server was down for a couple of days
and I managed to catch the second reply. What worried me is the huge size of
the MFC40.dll (900K!!!, which would almost fill a disk together with the
run-time dll of VB and its dependencies). Add to that the fact that some
vendors shipped their OLE wrappings with earlier foundation class libraries!
 I guess a good experiment is to try the app (w/out the MFC40.dll) on a system
that does not have it.
 Abed.