I acquire consistently admired to assay adapted brands of swiss fake watches affluence watches. If comparing the above brand, there are replica watches uk not abounding differences you can accretion distant from the above of replica rolex uk the replica. You can accretion some of the best Patek Philippe replica watches and acquire abolishment to rolex replica say added than your architectonics or you could accretion bigger above and a lower replica hublot watches casting and achieve your best easier.

Registering VB6 Office COM Add-ins as Per-Machine — Visual Basic Feng Shui

Registering VB6 Office COM Add-ins as Per-Machine

Filed under Uncategorized

Office COM addins can be registered in one of two ways:

  • Per user
  • Per machine

Per User addins will be loaded for the user that the addin was registered to. This is the common situation with addins created in VB6. Typically, this means that whatever user was logged in when your addin was installed, is the ONLY user that it will be registered for.

It’s simple enough to run regsvr32 again on your addin dll while logged in as a different user to register it for the new user but this can really be a pain in a big IT shop.

Per user addins are registered under the HK_Current_Key hive in the registry. For instance, Word add ins can be found here:

HKEY_CURRENT_USER\Software\Microsoft\Office\Word\Addins

Other Office apps, namely Excel, PowerPoint and Outlook, store their addin entries in similar locations in the registry.

Per Machine addins, on the other hand, are registered in the same key, but in the HKEY_LOCAL_MACHINE hive, so, for instance, here:

HKEY_LOCAL_MACHINE\Software\Microsoft\Office\Word\Addins

Per Machine addins have the benefit of being registered once but loaded no matter what user is logged in. Definitely a bonus if you commonly have multiple users on a machine.

The problem is, VB6 automatically sets up the addin designer object such that it registers add ins as Per User addins.

This is pretty easy to fix, however.

Here’s a snippet from the very top of a DSR file for a Word addin (Open the file using notepad or some other text editor, NOT using VB6):

VERSION 5.00
Begin {AC0714F6-3D04-11D1-AE7D-00A0C90F26F4} WordAddIn
   ClientHeight    =   6465
   ClientLeft      =   4815
   ClientTop       =   1215
   ClientWidth     =   10020
   _ExtentX        =   17674
   _ExtentY        =   11404
   _Version        =   393216
   Description     =   “My Word COM Add In”
   DisplayName     =   “MyAddIn”
   AppName         =   “Microsoft Word”
   AppVer          =   “Microsoft Word 9.0″
   LoadName        =   “Startup”
   LoadBehavior    =   3
   RegLocation     =   “HKEY_CURRENT_USER\Software\Microsoft\Office\Word”
End

Note the RegLocation element.

Simply change that to HKEY_LOCAL_MACHINE (but leave the rest of the key alone), recompile and Presto! Your add in is now a Per Machine addin.

There’s only one snag with this, though. Every time you make a change to your DSR file, VB will automatically switch that entry back to HKEY_CURRENT_USER. Oh, the helpfulness.

But, never fear, there’s a solution here as well. Just never change the DSR<g>.

Seriously though. Simply create a separate class, expose some public methods on it that mirror the event signatures of those in the DSR file itself, and then pass the events on through the DSR to your new class.

That way, your DSR file never has to change, but you can change your class all you want and never have to worry about VB switching up the RegLocation on you.

For instance, in your DSR file, there will generally be an AddinInstance_OnConnection event that is fired when the host application is loading up your addin. Define it something like the following:

Dim rAddinClass as AddInClass
Private Sub AddinInstance_OnConnection(ByVal Application As Object, _
      ByVal ConnectMode As AddInDesignerObjects.ext_ConnectMode, _
      ByVal AddInInst As Object, custom() As Variant)

   'Create and Initialize a base class
   Set rAddinClass = New AddInClass
   rAddinClass.OnConnection Application, ConnectMode, AddInInst
End Sub

Then, in your AddInClass.cls file, define a function like

Public Sub OnConnection(ByVal Application As Object, _
      ByVal ConnectMode As AddInDesignerObjects.ext_ConnectMode, _
      ByVal AddInInst As Object, custom() As Variant)

   'Do Whatever you need to do during the OnConnection event here
End Sub

When the host app (could be Outlook, Word, Excel, or PowerPoint, they all work the same), loads your addin, it will fire the OnConnection event. The sub in your DSR file will get called, which will then call the corresponding sub in your Addin Class and you can do whatever coding you need to do, never having to change the DSR file again.

Or you can try to write addins in VB.NET using VSTO, suck up about 10x the diskspace and memory, and have to deal with things like COM shims, and other splinters of joy.

8 Comments

  1. Erich Nurr says:

    It doesnt work for me.
    I am editing the connect.dsr and set the RegLocation to HKEY_LOCAL_MACHINE\Software\Microsoft\Office\Outlook”

    Its a Outlook Add In.
    The connect.dsr isnt changed after compiling the project in VB6 (HKEY_LOCAL_MACHINE is still alive) but if i open the .dll with the Tool “FRHED” i see the HKEY_CURRENT_USER Path inside… and the registration will be set in the HKEY_CURRENT_USER registrypath again :( have i to restart VB6 or the PC after editing the connect.dsr ?

    • Admin says:

      Hi Erich

      Not sure what to make of that. It sure +sounds+ like the compile didn’t grab the copy of the DSR file that you’ve modified, but it’s hard to say for sure.

      You might try creating the HKLM keys manually, (here’s a good link for that)

      http://www.cpearson.com/excel/comaddinssecurity.aspx

      Just to make sure Office is seeing and can load the addin via HKLM.

      • Erich Nurr says:

        Thanks for your fast reply.
        It grabs the copy of the DSR file, because if i change the description text too, it will be shown in the DLL (with Frhed) but the RegLocation value is still HKEY_CURRENT_USER i dont understand why.
        After this i installed the VB6 Addin “vbAdvanced” but it doesnt change anything. Is there an other way to fix this inside a DLL? of sure i can create the HKLM keys manually but thats not what i want :(

      • Erich Nurr says:

        I opened the connect.dca file and there is still HKEY_CURRENT_USER inside. but this file only changes if i save the connect.dsr over VB6 and if i do that the HKEY_CURRENT_USER will be set automatically as RegLocation…
        Shall i edit this file like the connect.dsr ? will this change anything?

        • Peter says:

          I´ve got the same problem but i fixed it by using the prompt and not the development manager from VB6.

          Prompt command:
          C:\programm files\Microsoft Visual Studio\VB6\VB6.exe /MAKE C:\Temp\Example.vbp

          Hope it helps !

          • Peter says:

            cant edit my post :(

            wrong path sorry !
            the correct path is:
            C:\programm files\Microsoft Visual Studio\VB98\VB6.exe /MAKE C:\Temp\Example.vbp

  2. Darin says:

    Thanks for the feedback. COM addins shouldn’t have to be this hard. What’s really sad is working with Excel, Outlook, and Powerpoint addins is significantly easier than working with Word addins. Word requires this whole "CustomizationContext" nonsense that, inexplicably, neither Excel or Powerpoint or Outlook requires at all. Yet they’re all equally customizable.

    And Word is by far the more common app.

  3. Ralf says:

    Excellent article on an arcane subject; thank you. I *know* I’ll encounter this some day, and now I know what to do.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*