As you say VBA code protection is minimal but perhaps enough to keep out
casual users.

The simplest way to protect would be to port to a VB6 ActiveX dll, and/or
adapt that to a Com addin. By 'simple' most of the vba code might work
pretty much 'as is' subject to fully qualifying absolutely everything, ie
all excel type objects and excel-vba functions. How much work is involved
would depend on how the vba was written rather than what it does. It is a
learning curve, particularly VB6 Forms which may need to be completely
re-written, though you can use your original Office (vba) userforms.

Although VB6 currently works in Vista it is no longer supported by MS who
would prefer you to use dot.net, even more of a learning curve.

Compatibility with future Excel versions is not directly related, your VBA
would need to do that anyway. As for Vista, AFAIK, the main issue is where
you can write to file and registry permissions.

You might want to weigh to potential loss of revenue of your code being
accessed against the cost of your time with learning curve or commissioning
someone to do it. Most casual users probably won't bother to break in.
Perhaps of more concern is the possibility of others distributing your work
as their own, either freely or commercially.

Regards,
Peter T

"alan57" wrote in message
...

I've developed a 2d sketch package for floorplans and calculating areas
using Excel VBA and the native Excel drawing functions. I would like to
distribute the addins and protect the code from other users. My
understanding is Excel VBA addins have only a password protection which
can
be easily broken and VBA addins cannot be protected.

Since Excel VBA addins are not protected, what other options do I have? I
want the distribution, installation, uninstall and possible licensing to
be
as simple as possible and also secure. I'm looking for info which
describes
the entire conversion and usage process.

I have several VBA addin files with approx 10k lines of code. I could
convert this to another format but it would be a non trivial task.

I am currently using XP with Excel 2003. I'm not concerned with earlier
versions of the OS or Excel. I want to be compatible with Vista and
future
versions of Excel/Office.

Any suggestions or links would be appreciated.

thanks.

I did something similar and went the VB6 COM add-in route. It allowed
me to use 3rd party licensing / anti-piracy tools as well as 3rd party
components to obtain XP and Vista styles. But as Peter T mentioned,
VB6 has some drawbacks. If I had to do it all over again, I would
probably take the time to learn Delphi and use that in conjunction
with Add-In Express.

If you use VB6, you will need to likely need to change all your
references to Objects (late binding) and declare an Application object
and derive all Set statements from it, e.g. instead of Me or
ActiveSheet you would need something thing Set ws = xlApp.ActiveSheet.
If you are sinking events such as Worksheet_Change, then you cannot
use late binding.

To use early binding and be backward compatible, you will need to
obtain a license for Excel 2000 and set a reference to that version of
the Object Library. If you go that route, I would strongly recommend
setting up a Virtual Machine - either Microsoft's VPC (free) or VMWare
- and doing your builds in it.

Just my $0.02,

Nick Hebb
BreezeTree Software
http://www.breezetree.com

Hi Nick,

Interesting you say in hindsight you would use Delphi in conjunction with
Add-In Express. Could I ask why the preference vs VB6.

With VB6 I haven't seen the need to use late binding providing the reference
is set to the lowest version of Excel. That of course requires the lowest
version is installed on the development machine. The same principle of
developing in the lowest version holds for a VBA addin.

In VB6, unlike VBA, I don't find a problem with early binding to do
something like the following within the same procedure -

If xlVer < 10 then
xl97/2k method
Else
method only available in later versions

Regards,
Peter T

"Nick Hebb" wrote in message
ps.com...
I did something similar and went the VB6 COM add-in route. It allowed
me to use 3rd party licensing / anti-piracy tools as well as 3rd party
components to obtain XP and Vista styles. But as Peter T mentioned,
VB6 has some drawbacks. If I had to do it all over again, I would
probably take the time to learn Delphi and use that in conjunction
with Add-In Express.

If you use VB6, you will need to likely need to change all your
references to Objects (late binding) and declare an Application object
and derive all Set statements from it, e.g. instead of Me or
ActiveSheet you would need something thing Set ws = xlApp.ActiveSheet.
If you are sinking events such as Worksheet_Change, then you cannot
use late binding.

To use early binding and be backward compatible, you will need to
obtain a license for Excel 2000 and set a reference to that version of
the Object Library. If you go that route, I would strongly recommend
setting up a Virtual Machine - either Microsoft's VPC (free) or VMWare
- and doing your builds in it.

Just my $0.02,

Nick Hebb
BreezeTree Software
http://www.breezetree.com

Hi Peter,

Interesting you say in hindsight you would use Delphi in conjunction with
Add-In Express. Could I ask why the preference vs VB6.

The main reason is sustainability over time. Like VB6 it's a RAD tool,
but despite the persistent rumors of its demise, Delphi will likely be
around (and supported!) longer than VB6. The other thing is that is
produces small executables. As I add more and more 3rd party controls
and functionality to my application, the size is swelling rapidly. I
don't think download size is that big of an issue these days, but I do
consider smaller better. The Delphi community is fanatical and the
more I look into it the more I understand why.

The downside, of course, is that most sample code you'll find is
written in VBA. More and more I'm finding top search results showing
VB.Net and C# code samples. With Delphi, you don't get that knowledge
base. Plus, I prototype most functions in VBA then move the code into
VB6, so that's a plus forVB6 over Delphi as well.

With VB6 I haven't seen the need to use late binding providing the reference
is set to the lowest version of Excel. That of course requires the lowest
version is installed on the development machine. The same principle of
developing in the lowest version holds for a VBA addin.

Agreed. But if you don't already own a license for Excel 2000, non-
pirated copies are getting harder and harder to find. It took me some
hunting to find a legit version last year. Same goes for VB6 as well.
Alan57, I hope have luck with that if you decide to go the VB6 route.


Nick Hebb
BreezeTree Software
http://www.breezetree.com

Thanks for that. I was unaware of Delphi's keep it small attributes. I don't
use any third party controls so that aspect hasn't been a factor for me, but
I will keep your comments in mind.

Hopefully, in view of the millions of VB6 app's out there, MS will not
disable VB6 in the foreseeable future.

Regards,
Peter T

"Nick Hebb" wrote in message
oups.com...
Hi Peter,

Interesting you say in hindsight you would use Delphi in conjunction
with
Add-In Express. Could I ask why the preference vs VB6.

The main reason is sustainability over time. Like VB6 it's a RAD tool,
but despite the persistent rumors of its demise, Delphi will likely be
around (and supported!) longer than VB6. The other thing is that is
produces small executables. As I add more and more 3rd party controls
and functionality to my application, the size is swelling rapidly. I
don't think download size is that big of an issue these days, but I do
consider smaller better. The Delphi community is fanatical and the
more I look into it the more I understand why.

The downside, of course, is that most sample code you'll find is
written in VBA. More and more I'm finding top search results showing
VB.Net and C# code samples. With Delphi, you don't get that knowledge
base. Plus, I prototype most functions in VBA then move the code into
VB6, so that's a plus forVB6 over Delphi as well.

With VB6 I haven't seen the need to use late binding providing the
reference
is set to the lowest version of Excel. That of course requires the
lowest
version is installed on the development machine. The same principle of
developing in the lowest version holds for a VBA addin.

Agreed. But if you don't already own a license for Excel 2000, non-
pirated copies are getting harder and harder to find. It took me some
hunting to find a legit version last year. Same goes for VB6 as well.
Alan57, I hope have luck with that if you decide to go the VB6 route.


Nick Hebb
BreezeTree Software
http://www.breezetree.com