Question

I have a Delphi 6 app that uses an ActiveX DLL to interface to another popular app (aka the “host” app for lack of a better word). The host app provides the integration DLL. I do not have the source code for it or any control over it. To use the DLL I create a TypeLib using the IDE Import ActiveX Control facility.

The problem arises when the host app vendor creates a new version of the ActiveX DLL. I have to scramble and provide my users with a new version of my program as they upgrade to the host app vendor’s latest or beta versions. Otherwise my app crashes of course when certain calls are made to the integration DLL due to variances between the old TypeLib and the new DLL. This also leads to the burden of maintaining multiple code bases of my app to maintain support for my users that still use the old versions of the host app. I’m trying to avoid a big messy code overhaul where I wrap everything in sight exposed by the integration DLL, in order to create a version of my code that can adapt at run-time to the current DLL version.

That leads to my question. The TypeLib(s) generated by Delphi is a big list of IDispatch methods and properties. Apparently the Delphi compiler converts these to IDispatch.Invoke() calls behind the scenes. Now I can detect the current version of the host app before I call CoCreate() to create the ActiveX object. So, is there any way I can at run-time switch between the two DLL TypeLib definitions? Right now I do it via compile-time conditionals that include the correct TypeLib based on the version of the host app I’m building for. I can do this because I retain each version of the TypeLib and give it a unique name as the vendor updates the DLL. But that doesn’t help me to do it at run-time.

I can’t fathom how to do this because everything from defined variables to method calls is based on the TypeLib as it is compiled. But I was wondering if there is something clever I could do at the IDispatch level to make this happen? Otherwise I’m stuck creating wrappers for each exposed object that calls the correct TypeLib method/property definition based on the current version of the host app. This is a big job and will also lead to some pretty convoluted code.

How have those of you faced with this same predicament solved or coped with it?

Answer 1

The practical solution would be to use late binding (getting a reference using CreateOleObject and having the references resolved at runtime) instead of using early binding via the typelibs. This would mean that as long as the vendor doesn’t remove functionality, your code would continue to work regardless of what version of the control was installed.

For examples of doing this with MS Office applications, you can see several of the old (but still accurate and usable) posts at Deborah Pate’s site (see note below). For instance, this one for Word uses late binding to either retrieve the currently running Word instance or create a new one:

var 
  Word: Variant; 
  Filename: OleVariant;
begin 
  try 
    Word := GetActiveOleObject('Word.Application');    
  except 
    Word := CreateOleObject('Word.Application');    
  end; 

  FileName := 'C:\WordDocs\MyFile.doc';
  Word.Documents.Open(FileName, EmptyParam, EmptyParam, EmptyParam,
                      EmptyParam, EmptyParam, EmptyParam, EmptyParam,
                      EmptyParam, EmptyParam);  
  Word.Visible := True;

Note that there is no included type library here, and no prior declaration of Word.Documents or the Documents.Open method. These are both resolved for you at runtime, and if not implemented will raise an exception.