Create a VBA/VBE password through code?

[TC]

Hi folks

(1) Say another VBA-capable product (not Word), uses automation to create a
new document, and add some procedures to that document's ThisDocument
module. Am I right in believing, that there is >NO WAY< for the
automation-using product, to set the VBA (VBE?) Password of the created
document, from code, without using nasty SendKeys hacks? Using Word 97, but
needs to work in higher versions also.

(2) Is there any good or accepted way to obfuscate Word VBA code, to make it
less easy for the user to read/steal/modify, if he cracks the VBA/VBE
password with a commercial tool or whatever?

TIA,
TC

 

[Jezebel]

There is no way to do it, even with using sendkeys. Even if you succeed, the
degree of protection is moot: a while ago someone posted a document
containing a password-protected macro. Someone else posted back the macro
code within about 20 minutes.

The most reliable method is to put the code into a VB module and compile it
to a DLL. Add that as a reference to your VBA project. All your VBA does is
call the functions in the DLL: code so trivial it's not worth protecting.

 

[TC]

Ok, thanks for your quick reply.

Unfortunately I'm not working from Visual Basic, so I don't have the ability
to compile to a DLL. Also, I really need my code to operate from within a
Word environment, so it runs fast even though it is late-bound. (There's a
reason why it has to be late bound.) I suspect that if I ran late bound
from within a DLL, my performance problems would re-surface.

Thanks for your input,

TC
(off for today)

 

[Jezebel]

On the contrary: code in a DLL, called from your VBA app (whether as a
reference or late-bound), is significantly faster than code in VBA alone; on
top of which you get the benefit of the more sophisticated coding
techniques, so your app can be more efficient in its design, also.

But if VB isn't available to you, it's irrelevant.

 

[TC]

Ok, thanks for that info. Just one question, if you're still reading this.
Say I obtained VB for the purpose of compiling a suitable DLL. Would that
DLL then stand alone, or would it need the VB runtimes?

TIA,
TC

 

[TC]

"stand alone" in the sense that I could reference & use it from a VBA host -
eg. Access - >without< any VB runtimes.

TC

 

[Jezebel]

You can't just put the DLL on a target machine and have it work, but you can
use the Package and Deployment wizard to create the set of installation
files. Just what these are will depend on what your DLL does, what controls
you use on your forms, etc.

Your target users do not need a VB licence to use the DLL.