Is it possible to compile an Excel 2000 workbook similar to how Access
creates an MDE file which removes the code and ensures the project
won't uncompile? I saw a few older threads that said it couldn't be
done but it seemed like they were referring to '97. I have a feeling
this can't be done but I thought I'd ask just in case.

Ted

There is no way to compile a workbook as an executable if that is what you
are talking about. You can password protect the workbook. You can password
protect your code and you can make the workbook an addin. Any password
approach can probably be broken with existing software password crackers.
In all cases, to work with an excel workbook you would probably need excel
installed.

Regards,
Tom Ogilvy

"Ted Theodoropoulos" wrote in message
om...
Is it possible to compile an Excel 2000 workbook similar to how Access
creates an MDE file which removes the code and ensures the project
won't uncompile? I saw a few older threads that said it couldn't be
done but it seemed like they were referring to '97. I have a feeling
this can't be done but I thought I'd ask just in case.

Ted

There is no way to compile a workbook as an executable if that is what you
are talking about.

No not as an executable but as a compiled workbook without any of the
canonical VBA text. Only p-code exists in the Access MDE making it
very secure and impossible to decompile. I didn't think Excel had
anything like the Access MDE but I thought I'd check nonetheless. All
the users will have Excel installed.

There's connection string info in the modules that has passwords that
I want to keep hidden from prying eyes. I'm not sure how to do it.
Of course I password protected the project with a strong password but
it seems like any brute force algorithim could get through it. Any
suggestions?

You could move your functions from VBA into a com add-in.

Since this is a compiled dll your code is much more secure,
if you use VB.Net to do this be sure to use a code obfuscator
as .net executable and dll's effectivel contain all the source which
can thus be disassembled.

Another great advance from micro$oft.

Keith

Thanks to both of you guys for your suggestions. The dll idea is a
good one but I'm trying hard to avoid having to run an installation
routine. I think that I would have to run one to register the dll on
the machine. Correct?

"Ted Theodoropoulos" wrote in message
om...
You could move your functions from VBA into a com add-in.

Since this is a compiled dll your code is much more secure,
if you use VB.Net to do this be sure to use a code obfuscator
as .net executable and dll's effectivel contain all the source which
can thus be disassembled.

Another great advance from micro$oft.

Keith

Thanks to both of you guys for your suggestions. The dll idea is a
good one but I'm trying hard to avoid having to run an installation
routine. I think that I would have to run one to register the dll on
the machine. Correct?

You dont need full blown Installshield type setup routine, a DOS batch
file would be fine or you could bypass that by writing a macro that calls
the
Shell function to run Regsvr32 and register your dll that way

Keith

You dont need full blown Installshield type setup routine, a DOS batch
file would be fine or you could bypass that by writing a macro that calls
the
Shell function to run Regsvr32 and register your dll that way

Keith

Interesting. You couldn't do it in a macro in the workbook (VBA
project) that needs the dll could you? The project would have a
reference to the dll and that dll would not be present in which case
none of the code would work including the shell function to run
Regsvr32. How could you get around that?