Thanks, Nick.

A user can always set security to high prevents macros from running and
thankfully there is nothing you can do about that.

I understand and appreciate the reason for this.

However, what I'm trying to do is protect a commerical product by ensuring
that the user has purchased a valid license. In our Visio application, we did
that by building our special functions and our license checking code into a
COM add-in (COM add-ins are not affected by macro security settings). If the
add-in is properly registered with Visio and a license is present, our
intelligent shapes work as advertised. But if the COM add-in isn't registered
or has been disabled, our shapes cease to function. I'm trying to replicate
this mode of operation in Excel.

From various tips here and elsewhere, I've come to several conclusions:
-- I can digitally sign my code so it will run at any security setting other
than very high.
-- I can password protect my VBA project so the user can't see or alter the
code.
-- I can continue to check for a valid license in the auto_open() sub.
-- I can't prevent the user from setting macro security to vry high and
preventing my code from running.

Given the above:

-- If my code runs and there is a valid license present, my code will
provide its added value functions and the user (and I) will be happy.

-- If the user prevents my code from running, they will be able to open the
xls/xlt and view the spreadsheet, however, the special functions provided by
my code will not be available. So even in this case I guess I am "protected"
in a reasonable way.

Any flaws in my logic? Any other suggestions?