Hi Alan,
: Can you come down from the stratosphere and explain what this is about,
: please?
This is just an explanation as I see it, Eduardo's may be different:
: > * Custom implementation of DllRegisterServer and DllUnregisterServer for
: > ActiveX DLLs and OCXs.
When you run 'regsvr32 <DLL or OCX name>', the regsvr32 utility loads your
DLL and calls the DllRegisterServer function. Similarly, when you run
'regsvr32 /u <DLL or OCX name>', the regsvr32 utility loads your DLL and
calls the DllUnregisterServer function. (pseudo VB code follows)
' DllRegisterServer is a Sub
' so is DllUnregisterServer
Sub Main()
Dim hMod As Long, pfnReg As Long, pfnUnreg As Long
hMod = LoadLibrary("<DLL or OCX name>")
If hMod = 0 Then MsgBox Err.LastDllError: Exit Sub
If InStr(1, Command$, "/u", vbTextCompare) Or InStr(1, Command$, "-u",
vbTextCompare) Then
' unregister
pfnUnreg = GetProcAddress(hMod, "DllUnregisterServer")
If pfnUnreg <> 0 Then CallEx(pfnUnreg) _' execute pfnUnreg
Else MsgBox Err.LastDllError: FreeLibrary(hMod): Exit Sub
Else
' register
pfnReg = GetProcAddress(hMod, "DllRegisterServer")
If pfnReg <> 0 Then CallEx(pfnReg) _ ' execute pfnReg
Else MsgBox Err.LastDllERror: FreeLibrary(hMod): Exit Sub
End If
FreeLibrary hMod
End Sub
VB provides implementations of DllRegisterServer and DllUnregisterServer by
default for every OCX and DLL project you create, and these default
implementations register your classes under the appropriate registry keys.
If you're curious, you can run the Dependency Walker (depends.exe) on your
OCX/DLL or run dumpbin /exports:
[D:\Projects\Menu] $ dumpbin /exports dsMenuCtl.ocx
Microsoft (R) COFF Binary File Dumper Version 5.12.8181
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Dump of file dsMenuCtl.ocx
File Type: DLL
Section contains the following exports for dsMenuCtl.ocx
0 characteristics
38C4F3FC time date stamp Tue Mar 07 20:20:12 2000
0.00 version
1 ordinal base
4 number of functions
4 number of names
ordinal hint RVA name
1 0 00003AAA DllCanUnloadNow
2 1 00003A7E DllGetClassObject
3 2 00003A94 DllRegisterServer
4 3 00003A68 DllUnregisterServer
Summary
1000 .data
1000 .idata
1000 .reloc
2000 .rsrc
7000 .text
However, there are additional things you can do in a Dll(un)RegisterServer
function, including accessing settings, initializing variables, etc. The
problem is that VB does not currently give you a way to modify the code it
generates.
: > * Custom implementation of DllGetClassObject (to avoid object creation
: using
: > a custom license).
DllGetClassObject is called when CoCreateInstance(Ex) or CoGetClassObject
try to create a new instance of the object.
It looks like this:
Public Exported Function DllGetClassObject(ByVal rclsid As IID, ByVal riid
As IID, ppv As Any) As Long
' rclsid [in] CLSID that will associate the correct data and code.
' riid [in] Reference to the identifier of the interface that the caller
is to use to communicate with the class object. Usually, this is
IID_IClassFactory (defined in the OLE headers as the interface identifier
for IClassFactory).
' ppv [out] Address of pointer variable that receives the interface
pointer requested in riid. Upon successful return, *ppv contains the
requested interface pointer. If an error occurs, the interface pointer is
NULL.
'Return Values
'This function supports the standard return values E_INVALIDARG,
E_OUTOFMEMORY and E_UNEXPECTED, as well as 'the following:
'S_OK The object was retrieved successfully.
'CLASS_E_CLASSNOTAVAILABLE The DLL does not support the class (object
definition).
'Remarks
'If a call to the CoGetClassObject function finds the class object that is
to be loaded in a DLL, CoGetClassObject 'uses the DLL's exported
DllGetClassObject function.
' Your code here
End Function
: > * And why not DllMain. Since it will support mult-threading it will be
: > usefull to know when the DLL is attached to a thread/process to
initialize
: > data (instead of doing it each time an object is created).
DllMain is the entry point to a (standard or otherwise) DLL. In a non-VB
ActiveX DLL, you don't have to supply a DllMain, but most people normally do
it for the reasons Eduardo mentions. In a standard DLL, you usually supply
it so that you can get an instance pointer.
The DllMain function receives 4 reasons: DLL_PROCESS_ATTACH,
DLL_PROCESS_DETACH, DLL_THREAD_ATTACH and DLL_THREAD_DETACH.
DLL_PROCESS_ATTACH is called when a new process loads the DLL. It is always
followed by DLL_THREAD_ATTACH as the main thread of the process loads the
DLL.
DLL_THREAD_ATTACH is called when a new thread from an existing process loads
the DLL.
DLL_PROCESS_DETACH is always called after all threads in the process have
unloaded the DLL (in the process raising DLL_THREAD_DETACH notifications) to
inform the DLL that it will be unloaded.
A DllMain function looks like this:
Private nProcessCounter As Long
Private nThreadCounter As Long
Public Exported Function DllMain(ByVal hInstance As Long, ByVal dwReason As
Long, ByVal fReserved As Long) As Long
Select Case dwReason
Case DLL_PROCESS_ATTACH
nProcessCounter = nProcessCounter + 1
Case DLL_THREAD_ATTACH
nThreadCounter = nThreadCounter + 1
Case DLL_PROCESS_DETACH
nProcessCounter = nProcessCounter - 1
Case DLL_THREAD_DETACH
nThreadCounter = nThreadCounter - 1
End Select
End Function
--
Damit Senanayake | damit@mvps.org
Please reply to newsgroups, not by e-mail.
http://members.xoom.com/damit | {http,ftp}://damit.dyndns.org (experimental)
ICQ: 6930718