Programmatically register an ActiveX component or DLL

[DinoVaught]

Does anyone know how to programmatically register an ActiveX component or DLL with visual basic? Not by shelling regsvr32 but with API calls where the name of the DLL is NOT hard coded into the application?

[dglienna]

What would you want that for? How would it know the ActiveX to register?

[Shaikh.Riyaz.a]

Does anyone know how to programmatically register an ActiveX component or DLL with visual basic? Not by shelling regsvr32 but with API calls where the name of the DLL is NOT hard coded into the application?

DLL must be there with function definition. You can set it as function parameter with regsvr32 command.

[WoF]

Well, you would possibly want it for an automated update system like I do.
During update the Updater program would unregister the former version of an ActiveX, copy the new one to windows\system32 and register it to be usable again.
The following code registers or unregisters a dll or ActiveX server.

Option Explicit

Private Declare Function FreeLibrary Lib "kernel32" ( _
        ByVal hLibModule As Long _
   ) As Long

Private Declare Function LoadLibrary Lib "kernel32" Alias "LoadLibraryA" ( _
        ByVal lpLibFileName As String _
   ) As Long

Private Declare Function GetProcAddress Lib "kernel32" ( _
        ByVal hModule As Long, _
        ByVal lpProcName As String _
   ) As Long

Private Declare Function CallWindowProc Lib "user32" Alias "CallWindowProcA" ( _
        ByVal lpPrevWndFunc As Long, _
        ByVal hWnd As Long, _
        ByVal Msg As Any, _
        ByVal wParam As Any, _
        ByVal lParam As Any _
   ) As Long

Private Const ERROR_SUCCESS = &H0

Private Const SELFREG_E_First = &H200
Private Const SELFREG_E_TypeLib = SELFREG_E_First
Private Const SELFREG_E_Class = SELFREG_E_First + 1


Public FSO As New FileSystemObject
Public SHL As New Shell


Public Function RegisterServer(hWnd As Long, ServerPath As String, Mode As Boolean)
  Dim hLib As Long
  Dim ProcAd As Long
  Dim sMod As String
  Dim res As Long
  
  On Error Resume Next
  
  sMod = "Dll" + IIf(Mode, "R", "Unr") + "egisterServer"
  
  hLib = LoadLibrary(ServerPath)
  ProcAd = GetProcAddress(hLib, sMod)

  res = CallWindowProc(ProcAd, hWnd, 0&, 0&, 0&)
  
  FreeLibrary hLib
  RegisterServer = res
 
End Function

Put the above code in a module.
Assume you are going to register "C:\windows\system32\MyActiveX.ocx"

   dim Result&, ocx$
   ocx = "C:\Windows\System32\MyActiveX.ocx"
   'to register:
   Result = RegisterServer(Me.hWnd, ocx$, True)
   'to unregister
   Result = RegisterServer(Me.hWnd, ocx$, False)

Each ActiveX has a procedure to register (RegisterServer) and one to unregister (UnRegisterServer)
The code loads the ActiveX in memory, asks for the adress of either function (depending on Mode being true or false) and calls it.

I'm using this code in an automated update program to update several .ocx controls when new versions are required.

[DinoVaught]

Thanks for the sample code WoF. It seems to be working perfectly for me! I am currently creating an application (that will reside on each PC) and will distribute or copy all of our other applications EXEs, DLLs etc to local hard drives, register and unregister certain components and do a bunch of other stuff too.

[WoF]

Addendum:
After a comment from dglienna, I'd like to add, that certainly you must know name and path of the ocx to register.

The requirement was

Not by shelling regsvr32 but with API calls where the name of the DLL is NOT hard coded into the application?

Note, that for the function RegisterServer the name of the dll is NOT hardcoded, but a parameter to pass. You can use it for multiple ocx to register, as long as you have name and path.

Btw.: the method I use in my procedue is nearly exactly the same what regsvr32 does.

[DinoVaught]

I do have one other question for you. What is the best way to know if the registering or unregistering failed? The calls to LoadLibrary and GetProcAddress return 0 when I feed them an invalid path or a non existent DLL so I assume is safe to assume an error if either of those return 0?. Or is there a better way to capture a failure that you know of?

Also, by using WoF's method my app is more dynamic and I wont have to worry or make any assumptions about where regsvr32 is or what it "might have done" if I shelled it. I can get return values after my attempts to registering or unregistering giving my app more knowledge about what happened.

[dglienna]

s

sumptions about where regsvr32 is or what it "might have done" if I shelled it

you do realize that regsvr32 just calls the api's for you, and acts like a wrapper? It's easy to find, and does what it should.

[DinoVaught]

In my situation there can not be any human intervention. It has to be done programmatically so. . . If I used the /s switch with regsvr32 and passed it an invalid path. Under these conditions regsvr32 would NOT be able to register the component. How would my app know it failed? I don't know of a way to get a success or failure back from regsvr32. Is there a way?

[dglienna]

Not a better way, but there's always a way...

[WoF]

Look at the programming of my function RegisterServer.
I forgot to explain: It is a function and will return 0 if the process was successful. Any non-zero value indicates an unsuccessful proceeding.
You simply check the Result:

Result = RegisterServer(Me.hWnd, ocx$, True)
If Result <> 0 Then MsgBox "Failed"

Edit: As an afterthought: I'd check validity of path and file existence before calling RegisterServer(). So you can be sure that a non zero return value was not caused by a missing ocx or invalid path, but by some other problems during registration.

Oh yes, and looking again at my post, you can leave aout these two lines:

Public FSO As New FileSystemObject
Public SHL As New Shell

They were remainders of my ropgram where I needed those. Although, the FSO might come in handy to check the existence of the ocx

If FSO.FileExists(ocx$) Then...