OCX references

The ability to fix up ActiveX DLL references works nicely. Is there any way of doing the same with an OCX?

David

Hi David

If you are referring to Object* type references in visual basic project file, the answer is no. We have not found a reliable way to resolve the references. If I have misunderstood your question, please email support with your vbp files so I can see what is happening.

Thanks Vincent, the Object* is what I was referring to.

The issue I have is that a custom OCX is interacting with objects in another DLL. If the other DLL changes its GUIDs, the OCX no longer works and has to be recompiled with its own new GUIDs. Then I have to manually reinsert the custom controls into the form.

I have perservered and found a solution. This involves changing the GUIDs in the vbp and the frm to the new values. The key to this was being able to get the GUID from the OCX then using the Text Find/Replace action to insert the new GUID into the 2 files.

I wrote a small piece of script within the Project Global Script as follows:


Function GetGUIDFromFile(vsFile)
Dim oTLI
Dim oTII

Set oTLI=CreateObject("TLI.TLIApplication")
Set oTII = oTLI.TypeLibInfoFromFile(vsFile)

GetGUIDFromFile = oTII.GUID
End Function

(It does require that the file TLBINF32.DLL be registered on the system, but it comes as part of Visual Studio I believe.)



I then use a Run Script action to call this function to set the value of a variable as follows:

OcxGuid = GetGuidFromFile("\MyControl.ocx")



Then I use a Text Find/Replace Action to change the FRM file:

set the search string to:
Object = "{*}#1.0#0"; "MyControl.ocx"

set the replace string to:
Object = "%OcxGuid%#1.0#0"; "MyControl.ocx"



Then I use a Text Find/Replace Action to change the VBP file:

set the search string to:
Object={*}#1.0#0; MyControl.ocx

set the replace string to:
Object=%OcxGuid%#1.0#0; MyControl.ocx


After this everything compiles fine.

Hope this may help others in the future.

David

Hi David

Glad to hear you found a solution. We use TLBINF32.DLL ourselves in the VB action, however with Object references we hit a roadblock in that we could not find a reliable way to determine the correct path to the file (and there are often multiple copies of the ocx file, all with different guids).