Excel ActiveX Control compatibility principles?

[Ian.W]

Picking up on this thread I would like to confirm what I can expect an Excel spreadsheet ActiveX Control to do on a variety of target machines with different versions of Office installed.

My app needs to be deployed on many machines. I'm willing to require they have Excel 2000 or later installed, but I can't control which one.

Q: So, if my app has an Excel version "M" ActiveX spreadsheet control, will it work on a target machine with Excel "N" (which is "M" or higher), as long as I do not use any features that overlap with the changes in the Excel object model between "N" and "M"? 

Q: Has anyone found a statement from Microsoft on such compatibility issues?

Q: This there a more robust (future-proof) approach to this problem?  (This seems like a real Achilles heel of the whole use of ActiveX control.)

Q: Is it common or practical to implement some sort of version-detection and include support for many versions of the ActiveX control in question?

Thanks in advance,

Ian

[Wendy L]

Hello Ian,

At least for the Microsoft Excel 2000 object model, Microsoft documents that "many changes that have been made to support new and improved features in Excel. To provide backward compatibility, replaced components have been hidden rather than removed. This means that they don't show up in the Object Browser by default, but old code that uses the hidden components will still work correctly without modification."

So the answer to you first question is that your applications should still work, especially if they use functions that have not changed between the different version of the object model.  The only concrete way to know if a function is affected is by searching MSDN on the issue.  In general, I have been able to run applications in Excel 97 - Excel 2003 with only minor issues, but this was most likely dependent on the functions I used.

Certain ActiveX controllers provide functions that will return the version of the current control or set of functions, but once again, this is going to be dependent on these particular function calls, which are not guaranteed to remain the same between different versions of the object model (i.e Windows Media Player 10 Object Model and previous versions).

Thanks.

[DaveC]

Ian,

"Q: Is it common or practical to implement some sort of version-detection and include support for many versions of the ActiveX control in question?"

A:  I would say that it's common and practical to implement version-detection for ActiveX controls.  In fact, with CVI it's really a very necessary thing to do if you are embedding the controls into your UIR panel.  Some, but not all, activex controls require a specific version of the server on the machine in order to run.  For instance, a Windows Media Player 10.0 ActiveX control will not be able to load on a machine with only a Windows Media Player 6.0 installed.  This will create a problem if the control is embedded into your UIR because the panel that the control is embedded on will not load.

There are many ways to check for certain activeX availibility on a machine.  The most robust way to do it would be to check the Windows registry for key entries to see if the application has been installed on the machine.

I.e. for Access 97 the key is as follows:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\8.0\Access

While for Access 2002 the key is:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\10.0\Access

However this leads to problems because some people just like to use the highlight and delete key to remove programs, and not the windows add/remove programs panel.  In this case you can check for the .ocx or .dll files associated with the ActiveX control you wish to use.  

As far as including support for many versions of an activeX control, well it's only as practical as circumstances permit.  If you want to make sure all of controls are usable you should include distribution kits for each control.  For example, you might have an application that can display multiple types of media, pdf files, etc.  You would need to distribute probably one version of windows media player, a least one version of adobe acrobat reader, etc.  And this can add up to a lot of extra distributables for your application.  Is that something you want to burden the user with?  And trying to uninstall all of that stuff when the user want to get rid of your application is a whole other issue.  On the other hand if you have a single activex control that only requires one distributable, then it's something you should include with your application assuming it's legally distributable.

[Ian.W]

Thanks very much Dave and Wendy. Good advice and background.

As I work through this I'm still having trouble getting an ActiveX Excel 2000 spreadsheet control to work. Specifically the "Property ToolBox" in that control, just does not work. Most of my testing has been with Excel 2002. Perhaps I've hit a key version difference for which backward compatibility does not hold.

I'm attaching a small test project in case anyone can give me some insights, or simply a report whether it worked on their PC.

Thanks,

Ian

[Wendy L]

Hello Ian,

When I opened your UIR on my machine, I got an error message saying that the ActiveX control could not be registered.  I deleted the control and placed another Speadsheet 9.0 control on the UIR.  When I ran the application, I pressed the Office logo as directed on the UIR, and the About Box displayed stating that I was using Office Web Components 9.0.0.3821 SR-1.  Also, I was able to press the Spreadsheet Property Toolbox and change the font and color of values in cells.  I'm assuming you're not seeing this behavior on your machine.

On my machine, I previously had Office 2000, but currently have Office 2003, so I have the 9.0 and 11.0 spreadsheet controls on my machine.  I'm also using CVI 7.1.

Thanks.

[Ian.W]

Wendy,

Thanks for testing that out. The result is a bit surprising.

I have Office XP (i.e. 2002) on my machine, and when inserting an ActiveX control, I have Office Spreadsheets 9.0 (i.e. 2000)  and 10.0  (i.e. 2002) available as choices. Since I have not had Office 2000 on this PC, I assume that both were installed as part of Office XP.

My Spreadsheet 9.0 control reports its version as 9.0.0.8028 SP-3, but since that could not be registered on your machine, that to me suggests that your 9.0.0.3821 SR-1 is not a close enough match, even though they are both nominally Excel 2000 spreadsheets! 

This is looking worse that I thought in terms of compatibility, and it sounds like there is more to it than just object model compatibility to which we both referred earlier in the thread.

Just for "fun" I've attached the same test but with an Excel 2002 spreadsheet (10.0.0.6619). I wonder if anyone with something other than that exact version can load/run it.

Finally, on the topic of the using the formatting toolbar button in the spreadsheets, there is more strangeness: On my machine, the 10.0/2002 version works fine, but the 9.0/2000 does not, even though I'm using the version (9.0.0.8028 SP-3) that is on my computer. However it sounds like when you put in your own 9.0/2000 spreadsheet, the formatting worked.  Weird!

Thanks,

Ian

[Wendy L]

Hello Ian,

Can you reattach your application?  It seems to not have been posted with your previous thread.

Thanks

[Ian.W]

Oops! Thanks for pointing that out, Wendy. (It seems that Previewing a post drops the attachment!)

Here is the Excel 2002 test project.

--Ian

[Wendy L]

Hello Ian,

I saw the same behavior as before.  Since I don't have the 10.0 Speadsheet control, I receive an error when loading the UIR.  I went ahead and replaced the control with the 11.0 control (11.0.0.6255) and the Command and Options dialog (formerly the Property ToolBox) worked correctly.

Thanks

[Ian.W]

Thanks again, Wendy.

It looks like the conclusions so far are:

• The target PC needs a license for Office that matches the exact version (or perhaps only the SP #) of the ActiveX Excel spreadsheet control.
• Assumptions about backward compatibility should not be made.

Therefore I do not plan to pursue use of the ActiveX Excel spreadsheet control.

However, this does beg for more information on what developers should expect when using ActiveX controls. 

And, I'm in complete agreement with Roberto Bozzolo in this thread.

--Ian