"JE McGimpsey" wrote in message ...
In article ,
"macropod" wrote:

Well, if the worksheets start out blank and the vba code populates them with
the data and functions, then disabling the macros
prevents the user getting access to either the data or the functions. Quite
simple, really.

What's to prevent the user from removing macro protection (again, with
the workbook closed, using extremely simple techniques), then opening
the file with macros disabled, examining the code, removing or modifying
the part(s) that check for expiry, saving the file, then opening it with
macros enabled to populate the data and functions?

That's simple too. Removing protection takes about 30 seconds. Finding
the expiry code may take a bit longer, but probably not very long.

I've done this many, many times for clients that have had employees who
created "expiring" workbooks, and who have since left the company or
forgotten the project password. In fairness, half the time one can
defeat the protection just by running a backup copy after setting the
computer's clock back to before the expiry date.

A further difficulty is preventing the user from saving a copy of the
workbook with all the data and formulae expunged from the worksheet(s)
(but yet saved somewhere safe) and everything locked up tight. It's
possible, certainly, but not without its tricky aspects.

One client of mine, in addition to project protection and vba population
of key formulae, and many, many, layers of checking hidden activation
codes, *and* almost continuous on-time macros running to detect removal
of worksheet and workbook protection, asked me to make a small
modification to the app. He sent me a copy of the app, and called 1/2
hour later to give me the activation key. He was flabbergasted when I
told him I didn't need it, that I'd already removed or bypassed
everything he'd done and made the modification.

Trying to make XL workbooks secure from the moderately curious is like
adding epicycles upon epicycles to circular orbits - adding layers of
protection may look better and better, but ultimately it's futile.

Yes, certainly the average user won't be bothered try to break the app,
but if one wants it truly "inoperable", one shouldn't be using XL.

A COM add-in or another compiled app is far more secure.

Yes, all these things are true, and they just go to show how the standard 'expiry' protections might be circumvented. That's not to
say the principle is unsound, and the OP was after advice on how it might be done. Of course, using Office Developer Edition makes
it pretty easy to turn vba code into a COM add-in (see http://support.microsoft.com/kb/306130/en-us). Getting the COM add-in to
un-register and delete itself might be a bit more work, though.

Cheers
--
macropod
[MVP - Microsoft Word]
-------------------------