VBa- code to DLL

[helpasap]

Is there a way to convert VBA-code into a .DLL (Dynamic Link Library)?

Jan

 

[Dr. Stephan Kassanke]

In

Is there a way to convert VBA-code into a .DLL (Dynamic Link Library)?

Jan

Hi Jan,

not directly as far as I know. Convert the code to VB.NET or VB (more or
less manaula adjustments necessary)

Stephan

 

[Jonathan West]

Is there a way to convert VBA-code into a .DLL (Dynamic Link Library)?

Jan

Hi Jan,

You can copy the code into a VB6 ActiveX DLL project. If you set the
appropriate references back to Word Office, the other changes to the code
will be fairly minimal. These are the kinds of things you will need to do

1. Make sure that the main public class(es) have methods that provide entry
points to the rest of the code

2. You may have to modify some of your Dim statements for object variables
where these is a name clash between Word and VB. For instance you will need
to change the following

Dim oShape as Shape

to this

Dim oShape as Word.Shape

because VB already has a Shape object in the Forms library.


--
Regards
Jonathan West - Word MVP
www.intelligentdocuments.co.uk
Please reply to the newsgroup
Keep your VBA code safe, sign the ClassicVB petition www.classicvb.org

 

[Jay]

Hi,

A curiosity question: what's the advantage in converting to a DLL?
Does the code run faster?

Thanks,

Jay

 

[Jonathan West]

Hi,

A curiosity question: what's the advantage in converting to a DLL?
Does the code run faster?

The VBA project password is easily broken if you have the right tools. If
you have proprietary code you want to protect, it is better to move it to a
DLL so that the source code is not included in the package sent to the
customer.

--
Regards
Jonathan West - Word MVP
www.intelligentdocuments.co.uk
Please reply to the newsgroup
Keep your VBA code safe, sign the ClassicVB petition www.classicvb.org

 

[Jay]

Thanks Jonathan. So is there no change in execution speed? I assume
that a DLL is compiled, whereas VBA is interpreted, but maybe I'm
wrong here.

Jay

 

[Jonathan West]

Thanks Jonathan. So is there no change in execution speed? I assume
that a DLL is compiled, whereas VBA is interpreted, but maybe I'm
wrong here.

Both are compiled after a fashion. The old distinction between interpreted
and compiled is much muddier than when the terms were distinct about 30
years ago. The key issue with regard to performance is the speed of access
to objects, and that is a much more difficult thing to provide hard & fast
rules for.

All I can say is that when a VB6 ActiveX DLL is compiled and uses early
binding back into the Word object model, I have found execution speeds to be
broadly comparable for my own code. I have not attempted to use VB.NET or C#
for this purpose, so I cannot say whether the same is true for an ActiveX
DLL compiled in a .NET language.


--
Regards
Jonathan West - Word MVP
www.intelligentdocuments.co.uk
Please reply to the newsgroup
Keep your VBA code safe, sign the ClassicVB petition www.classicvb.org

 

[Jay]

Thanks, I now understand.

Jay

Both are compiled after a fashion. The old distinction between interpreted
and compiled is much muddier than when the terms were distinct about 30
years ago. The key issue with regard to performance is the speed of access
to objects, and that is a much more difficult thing to provide hard & fast
rules for.

All I can say is that when a VB6 ActiveX DLL is compiled and uses early
binding back into the Word object model, I have found execution speeds to be
broadly comparable for my own code. I have not attempted to use VB.NET or C#
for this purpose, so I cannot say whether the same is true for an ActiveX
DLL compiled in a .NET language.


--
Regards
Jonathan West - Word MVP
www.intelligentdocuments.co.uk
Please reply to the newsgroup
Keep your VBA code safe, sign the ClassicVB petition www.classicvb.org

 

[Karl E. Peterson]

Both are compiled after a fashion. The old distinction between
interpreted and compiled is much muddier than when the terms were
distinct about 30 years ago. The key issue with regard to performance
is the speed of access to objects, and that is a much more difficult
thing to provide hard & fast rules for.

All I can say is that when a VB6 ActiveX DLL is compiled and uses
early binding back into the Word object model, I have found execution
speeds to be broadly comparable for my own code. I have not attempted
to use VB.NET or C# for this purpose, so I cannot say whether the
same is true for an ActiveX DLL compiled in a .NET language.

Jay, I would definitely agree with Jonathan's assessment in cases where most of the
code is object model manipulation. However, if you're doing intense processing
(outside the application's object model) of some sort or another, such as encrypting
multi-megabyte files, you absolutely can achieve quite noticable performance
enhancements with fully-optimized, native compilation. I've seen several orders of
magnitude benefits in certain circumstances, amounting to 2-hour processing times
being reduced to mere minutes, for example. (Now, whether my experiences are
"normal" -- well, that's an entirely different question! <g>)

Later... Karl