Results 1 to 3 of 3
  1. #1
    5 Star Lounger
    Join Date
    Jul 2001
    Location
    Terneuzen, Netherlands
    Posts
    895
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Over the years I've been doing quite some small programming 'projects'. My thing is Excel and I use VBA a lot. Sometimes, I write code which I'd like to protect (for various reasons, one could be that there might be confidential information in the code). Now of course one can password protect the VBA code but I know there are a zillion crack programs out there. I also know I can program in VB (I know how to do VB6) and 'control' Excel from there but I think (unless someone can convince me otherwise) this is quite complex. Then one could build external code and have that run as "DLL" (or XLL?) from Excel. I also don't know how to do that and I think that is complex too.
    So I'm looking for a way to program e.g. most or some in normal VBA but put crucial parts 'somewhere else' or use them in a way that cannot be cracked simply with a password crack program [by the way; I'm not looking for super protection; things like reverse engineering and/or debugging EXE code is way beyond what I need protection for].
    Hey, and maybe there is a program / code that can encrypt en decrypt VBA code before it starts to run. Problem remains then, how do I protect that program itself.... For the record; I have ways to restrict operation of code on certain systems that's not the problem. The problem is that people can see and change that code so it is basically useless...

    Any tips, wild ideas, suggestions are welcome...

  2. #2
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Weert, Limburg, Netherlands
    Posts
    4,812
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Programming Excel from vb6 is very simple. Stephen Bullen's book Professional Excel development has a chapter dedicated to it.
    You can copy just about 99 % of your code and it will work, as long as you qualify the Excel objects properly.
    Just make sure you never qualify Excel objects by using "Excel.", but use a global variable that holds the Excel instance instead. The only place where you can use "Excel." is in Dim statements:

    Public goXL as Excel.Application

    Then in your code you must:

    Dim oCell as Excel.Range
    'goXL has been instantiated by the connect class module
    Set oCell=goXL.ActiveCell

    And NOT:
    Set oCell=Excel.ActiveCell
    Jan Karel Pieterse
    Microsoft Excel MVP, WMVP
    www.jkp-ads.com
    Professional Office Developers Association

  3. #3
    Super Moderator jscher2000's Avatar
    Join Date
    Feb 2001
    Location
    Silicon Valley, USA
    Posts
    23,112
    Thanks
    5
    Thanked 93 Times in 89 Posts
    [quote name='ErikJan' post='771738' date='22-Apr-2009 07:10']Then one could build external code and have that run as "DLL" (or XLL?) from Excel. I also don't know how to do that and I think that is complex too.[/quote]
    Back in the old days of Office 2000-2002, there was an edition that included a compiler to create COM object add-ins for office. This was a little clunky to learn at first because you have to work harder to expose your functionality in the UI. However, the rest of the code was still good old VBA. Although Microsoft has moved on to "Visual Studio Tools for Office" and .Net assemblies for programming Office applications, I think you can still create COM add-ins (or stand-alone DLLs) even for Office 2007 in VB6. At least it's worth a try.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •