[RESOLVED] Overlap between to add-ins

[MartinLiss]

I’ve written two COM add-ins using VB6. One of them which I’ll call ai-VB6 was written first and is intended for use in VB6 projects. The other one which I’ll call ai-VBA was created by modifying ai-VB6 and it is intended for use in Excel.

The problem I’m having is that if ai-VBA is in use and I try to use ai-VB6 in a VB6 project, a Msgbox that resides in ai-VBA’s AddinInstance_OnConnection sub gets displayed indicating that it’s trying to connect to ai-VBA. If ai-VBA is not in use there’s no problem connecting to ai-VB6.

Some facts:
ai-vb6 has a reference to to ‘Microsoft Visual Basic 6.0 Extensibility’ and ai-VBA instead has a reference to ‘Microsoft Visual Basic for Applications Extensibility 5.3’
The Connect.dsr ‘Application Name’ is different
Only ai-vb6 shows up in a VB6 projects Add-in Manager and only ai-VBA shows up in Excel.

Any idea why this is happening?

[MartinLiss]

Another fact. Even though the dll's have different names it's the one that's compiled last that is always connected to from either Excel or VB6.

[Nightwalker83]

I am assuming that there is code in both the add-ins that acts the same way so it appears that the second add-in is stopped in this case.

[MartinLiss]

Yes there is similar code in both add-ins but the problem occurs before the code is involved, and for some reason VB always thinks that I'm trying to connect to the last-compiled add-in. I have another pair of VB6/VBA add-ins that have no problem coexisting and I don't see anything in the problem pair that's done differently in Connect.dsr.

[Nightwalker83]

So you used a designer in the working pair as well?

[MartinLiss]

If you mean connect.dsr, then yes.

I've attached the dll's renamed as txt files. I'd be interested in knowing if the same thing happens to you when you try them. To do so
- Store them anywhere you like
- Rename them as dll files
- Register them by going to Start|Run and type in Regsvr32 C:\<Path to the file>\insertprocname.dll and again for the VB6 version.
- Then go to Add-in Manager in VB6 and in the VBE of Excel (not the sheet) and load them

What they do is to add the name of all procedures that you select into the procedure in the type of statement you want. For example if you click the "A" button and select Debug.Print (which is the default, Debug.Print <Name of the procedure> will be executed if and when that procedure is run.

You will get an "Error on line 20" if there's a problem.

[Nightwalker83]

Trying to register the "InsertProcNameVB6.dll" I encounter an error as soon as I enter Regsvr32 <Path to the file>\insertprocname.dll in command prompt and press "Enter",

The module failed to load.

Make sure the binary is store at the specified path or debug to check for problems with the binary or dependent .Dll files. The specified module could not be found.

Edit:

I had to browse to the "System32" in "Windows" folder and drag the file to "Regsvr32" in-order for the .dll to register successfully.

Edit II: Yes, I receive the same error! It is interesting that the dll ran while I was loading the VB6 IDE i thought I would have to start a new project, add the dll then run the project in-order for the dll t work.

[MartinLiss]

Sorry about the problems you had registering the dlls. I use Windows XP and I just go to Start|Run. You?

In any case do you have any experience writing COM dll's? If so I'll post the source for both of the dll's if you want to see if you can find out what's wrong.

[Nightwalker83]

Sorry about the problems you had registering the dlls. I use Windows XP and I just go to Start|Run. You?

In any case do you have any experience writing COM dll's? If so I'll post the source for both of the dll's if you want to see if you can find out what's wrong.

I use Windows 7 on both my desktop and Laptop although, I might have a virtual machine with WinXP on it floating around somewhere that I could test the dlls on. I have only written basic dlls no add-ins.

[MartinLiss]

In my original post I said

The problem I’m having is that if ai-VBA is in use and I try to use ai-VB6 in a VB6 project, a Msgbox that resides in ai-VBA’s AddinInstance_OnConnection sub gets displayed indicating that it’s trying to connect to ai-VBA. If ai-VBA is not in use there’s no problem connecting to ai-VB6.

and that's not correct. It turns out that what's in use doesn't matter. What happens is that the last dll that's compiled or the last dll that's registered is the one that gets connected to from either platform.

[Nightwalker83]

In my original post I said

and that's not correct. It turns out that what's in use doesn't matter. What happens is that the last dll that's compiled or the last dll that's registered is the one that gets connected to from either platform.

So both Excel and VB6 can use the same dll regardless of whether it is the VB6 version or the VBA version?

[MartinLiss]

No. When you go to the Add-in Manager in VB6 the only add-in (of mine) that's available is ai-VB6 and in Excel the only one that's available is ai-VBA. However if, say, I've compiled or registered ai-VBA last, if I go to VB6 the only add-in of mine I see is still ai-VB6 but an error occurs when I try to connect to it, and I've proved that it's trying to connect to ai-VBA with the use of a msgbox that tells me which add-in is being connected to. It's all VERY strange.

[Nightwalker83]

I take it both DLLs have the same filename except for the "VB6" or "VBA" part? If so try changing the filename as see what happens when you go through the process from scratch.

Edit:

Saying to keep the filename for the VB6 version as is and change the filename of the Excel version to something such as "Excar.dll" does the problem still occur when you use both dlls simultaneously?

[MartinLiss]

Same problem

[Nightwalker83]

I suppose the next step would be to comment out bits of the code one part at a time and test to see if the problem still occurs. If this is possible?

[eHugo]

could it be that you copied the first addin and it was set to binary compatibility? If so, and you did not break compatibility, then both would have the same ClsID and whatever you compile last, gets registered with exactly this ClsID. Try compiling one of them without any compytibility-option.

[MartinLiss]

I suppose the next step would be to comment out bits of the code one part at a time and test to see if the problem still occurs. If this is possible?

The add-in fails on the first line of code.

When a designer is used to create the add-in you are shown the form on the left. The picture on the right shows the available choices for the 'Application' value. In the VB6 add-in I choose 'Visual Basic' and in the VBA add-in I choose 'Visual Basic for Applications IDE'. When 'Visual Basic' is chosen 'Application Version' gets set the 'Visual Basic 6.0' (the only choice) and when 'Visual Basic for Applications IDE' is choses, 'Application Version' gets set the '6.0' (the only choice).

When the add-in is run, the first step in the process is the AddinInstance_OnConnection event, the first lines of which look like this.

Private Sub AddinInstance_OnConnection(ByVal Application As Object, ByVal ConnectMode As AddInDesignerObjects.ext_ConnectMode, _
            ByVal AddInInst As Object, custom() As Variant)
'------------------------------------------------------
'this method adds the Add-In to VB
'------------------------------------------------------

    On Error GoTo ErrorRoutine

    ' Save the instance of VB
    Set oVBE = Application

and here 'Application' refers to the 'Application' specified in the Designer. So when, say, the VB6 add-in runs oVBE should get set to 'Visual Basic 6.0', but what happens if the VBA add-in happens to be the last one compiled, is that a "Type mismatch" error occurs at the Set oVBE = Application line.

[MartinLiss]

could it be that you copied the first addin and it was set to binary compatibility? If so, and you did not break compatibility, then both would have the same ClsID and whatever you compile last, gets registered with exactly this ClsID. Try compiling one of them without any compytibility-option.

In both versions 'Version Compatibility' is set to 'No Compatibility'.

[Nightwalker83]

and here 'Application' refers to the 'Application' specified in the Designer. So when, say, the VB6 add-in runs oVBE should get set to 'Visual Basic 6.0', but what happens if the VBA add-in happens to be the last one compiled, is that a "Type mismatch" error occurs at the Set oVBE = Application line.

May the line of code

Set oVBE = Application

needs to be set

Set oVBE = Application.Visual Basic

for the VB6 version and

Set oVBE = Application.Visual Basic for Applications IDE

for the VBA version?

[MartinLiss]

Thanks for trying but no, 'Application' is derived from the designer and has no properties or methods. As proof I have another pair of VB6/VBA add-ins that work just fine with just "Application".

[Nightwalker83]

Thanks for trying but no, 'Application' is derived from the designer and has no properties or methods. As proof I have another pair of VB6/VBA add-ins that work just fine with just "Application".

It is interesting that you have

On Error GoTo ErrorRoutine

although, it doesn't seem to be working as it should because if it were would not receive the "type mismatch" error, unless, that is the custom message you designed?

[MartinLiss]

Thanks. I resolved the problem. It turns out that regardless of the name of the dll, only one registry entry is created and that entry is created from the project name. In my case while I had two projects that created two differently named dlls, both projects had the same name so there was only one registry entry. Naming the projects differently resolved the problem.