As far as #1, you can write code to replace all of the data, or
alternatively use a "code" workbook, which operates in the background
against a data-only user workbook. That can be an addin or hidden workbook.

#3: How far are you willing to dress up a cat to make it appear as a dog?
You can program and program until the cows come home, but sooner or later
Excel will be "known" and then you're left with all of this code that still
has to put Excel back into the state it existed in before your solution was
used.


--
Tim Zych
SF, CA

"Johnno" wrote in message
oups.com...
Hi,

I have distributed an Excel spreadsheet to a number of users, and
while it does what it should do, there are some broader issues that
need to be resolved. Let me explain:

The positives:
1) It has been easy enough to develop so far, within the limit of my
knowledge of VBA.
2) There is a single workbook containing both the VBA code and the
user's data.

The negatives:
1) There is a single workbook containing both the VBA code and the
user's data. As updates are needed, the user will have to delete the
workbook and replace it with the new one, meaning a loss of data.
2) There is code to hide Excel's standard features at start up and
insert a custom toolbar. This works well on Excel 2000 to 2003, but
the custom toolbar does not appear on Excel 2007.
3) Even with a splash screen, the user knows it is Excel. Something
that looks like a stand-alone application might have a higher
perceived value than "just a spreadsheet".
4) Depending on the version of Excel, there is a prompt regarding
macro security settings, which can confuse inexperienced users.
5) Some charts created in Excel 2000 (the earliest supported version)
don't display in Excel 2007.

I'm sure there's a way (or ways) to overcome these issues. What might
they be, and what would be the pros and cons of each?