Art,
I was following your original post and IMO the problem is raised when
your XL2003 file was saved to the later version. It could have just as
easily been saved as the early version so it continues to work in both
environments. For example, all my addim projects are XLAs whether they
run in early or late versions of Excel. This is doable because addins
rarely get saved during runtime. Rather, the workbooks they act on get
saved in whatever version the addin runs in. The result is there's no
forward/backward compatibility issues with the VBA project.

Is there any reason why you can't distribute the VBA part of your
project separately from the workbook part it acts on? Normally, addin
solutions will always start out using their own pre-design workbook
templates, and continue in that context each time a user makes a new
file based on the pre-designed template. The addin would normally
handle the template implementation, but if your project doesn't require
a pre-designed file to start with then your even better off to not need
a template. Thus, your VBA solution can act on any workbook the user
chooses.

Going this route will require that you revise your project such that
it's 'version-aware', and so runs code appropriate for the current host
version of Excel. This is a trivial concern since there's really not a
whole lot that's different about core functionality, and so focus needs
only to include extended features in the later versions. IMO, this
approach is much better than having to manage and maintain 2 versions
of your VBA project.

In a nutshell.., I'm trying to convey the idea of separating the
'programming tier' of your solution from the 'business tier' that it
processes!

--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc