Archived Forum Post

Index of archived forum posts

Question:

New 9.5.0 Version for ActiveX

Sep 05 '14 at 22:45

With the new all-in-one dll for the ActiveX family, does that mean that each forthcoming version will have a different project and dll file name?

File Name: ChilkatAx-9.5.0-win32.dll
Code Sample:

Private Sub Process_Http(oReq As Chilkat_v9_5_0.ChilkatHttpRequest)
  Dim oResp As Chilkat_v9_5_0.ChilkatHttpResponse

Accepted Answer

Yes. This is important for the following reasons:

  1. If backward compatibility needs to be broken for some exceptional reason, then it can be.
  2. Older apps may continue using a specific version of the Chilkat ActiveX without fear of them breaking by newer apps installing a newer version of the ActiveX.
  3. There are internal performance advantages to having all the objects in a single DLL.
  4. One no longer needs to wonder about what object resides in which DLL.
  5. For Delphi programs, there are no longer type issue requiring the "As" keyword for type casting (see http://www.chilkatsoft.com/p/p_307.asp)
  6. Having one DLL allows Chilkat to move forward faster with new products/features. The entire ATL/COM infrastructure is now entirely generated (no longer hand-written).

Your programs should either isolate object-creation to one place where the name can be changed. For cases where the types are used in method signatures (such as in your example above), you can use Visual Studio or other editors (such as EmEditor which I often use for various task) to do file search/replace. It should be a simple task to do a search/replace of "Chilkat_v9_5_0" with "Chillkat_v9_5_1" (or whatever the next version number will be) in your source files.


Answer

Before I start griping, I want to say that these DLLs are the best thing I've ever found. I use them for EVERYTHING!

I have a set of VBScripts that automate a bunch of functions on a Windows server. Its basically a batch system with a few realtime functions. I understand the backward compatibility issue but changing the createobject statements in over 100 scripts is clumsy at best. And unless I move all the code to a linux box, I don't have anything in Windows that will bulk update like sed. To make things more difficult, all the scripts are in VSS so there is no automated check out/in.

I'd like to use the new DLLs and pick up any performance improvements but I don't see a reasonable approach especially if I'm faced with changing all the createobject statements every time


Answer

Bob, thanks I appreciate what you said, and griping is fine -- there's no harm in it.

The versioning is such that only the 1st three numbers are included in the ActiveX name. For example, we're currently at 9.5.0.43, but the ActiveX name only uses "9_5_0". The intent is that the first 3 version numbers will change very infrequently. Maybe once per year at most. Therefore, your CreateObject statements will continue to work with any version 9.5.0.X.

If/when a new version of the ActiveX is released where the CreateObject statement changes, I would say that it's good to leave existing scripts as-is. No need to update if all is working fine. New scripts can use the new version because both old and new can coexist. As you visit any given script in your work, you might at that point update to the newest version. I personally think this is better because you're never faced with all 100 scripts suddenly using a new version. Any unanticipated behavioral changes in Chilkat, or even newly introduced bugs would be confined to your script that is actively under development..