Can we protect VBA code?

Is there a way to encode or similar our VBA code, or make it not accessible/viewable to users, so that others can't copy/modify our code?

Regards,

Graham

Parents Reply
  • DanPaul,

    I used to give password to my vba codes. Now, I understand that I have to compile my code to make "really" protected tool.

    If you mean to use compile under Debug menu, then I compiled my password protected mvba code now. But I dont understand how much I protected it.

    What is the difference between compiled mvba and only password protected mvba?

     Regards,

    Olcay

     

Children
  • oebcin:

    I used to give password to my vba codes.

    The password protection built in to VBA by Microsoft is weak. It can be broken using publicly-available methods. Its purpose is to reduce idle curiosity by users: if a macro is modified, a user must have broken the password.

    oebcin:

    If you mean to use compile under Debug menu, then I compiled my password protected mvba code now. But I dont understand how much I protected it.

    VBA compile doesn't do a lot, and it certainly doesn't stop someone breaking your VBA password and examining your source code. If you really need secure code, then move non-MicroStation functionality into a ActiveX (COM) DLL built with another tool (i.e. VB6 or C++), and reference that from your VBA code.

    Regards, Jon Summers
    LA Solutions

     
    Regards, Jon Summers
    LA Solutions

  • Jon Summers:

     If you really need secure code, then move non-MicroStation functionality into a ActiveX (COM) DLL built with another tool (i.e. VB6 or C++), and reference that from your VBA code.

    Why only non-MicroStation functionality? If you reference COM object inside of ActiveX DLL, then its internal MicroStation functionality will be usable only within MicroStation so it should be legal, or not? 

    oebcin:

    I never really needed compiled MVBA code, but I made some DLLs (to test it only) by simple exporting modules from VBA and then inporting them into VB6. Problems becomes with Forms, because there is little bit different meaning about forms in VBA and forms in VB6, because forms from VBA needs MDI container, so it's better to compile only functionality, not UserForms... 

    There is also option to use .NET and compile as new COM...

  • DanPaul:

    Why only non-MicroStation functionality? If you reference COM object inside of ActiveX DLL, then its internal MicroStation functionality will be usable only within MicroStation.

    You're absolutely right. The reason that I don't put MicroStation functionality in an ActiveX component is that I can use that same component from outside MicroStation. For example, I can build a database interface component as an ActiveX, then use that component from both MicroStation VBA and a VB application executable.

    DanPaul:

    There is little bit different meaning about forms in VBA and forms in VB6, because forms from VBA needs MDI container, so it's better to compile only functionality ...

    There's another reason not to put all your VBA stuff into a DLL!

    This discussion is somewhat moot — anyone who doesn't have Visual Studio 6 (with VB6) is going to have a hard time acquiring it now. Microsoft wants us to use .NET, and does not want us to use VB6.

    Regards, Jon Summers
    LA Solutions

     
    Regards, Jon Summers
    LA Solutions

  • Jon Summers:

    You're absolutely right. The reason that I don't put MicroStation functionality in an ActiveX component is that I can use that same component from outside MicroStation. For example, I can build a database interface component as an ActiveX, then use that component from both MicroStation VBA and a VB application executable.

     

    Aha, now I see how did you mean it :), but this is discussion about protecting a MVBA code, so we can suppose that it can be completely based on MicroStation functionality...

    Jon Summers:

    Microsoft wants us to use .NET, and does not want us to use VB6.

    Yes, they wants and it is not problem. It just needs a very little bit more of work to do it and still it is just close to copy-pasting of existing code, but now into VB.NET COM Class, but we should not forget about obfuscation :)

  • Thanks a lot.

    you helped me a lot.

    Now, I can protect my codes better than before :)

    regards,

    Olcay