 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussionsAccessExcelInfoPathOutlookPowerPointPublisherWordDirectoryUser Groups Related Topics Outlook ExpressInternet ExplorerWindowsMS Server ProductsMore Topics ... |
MS Office Forum / Word / Programming / October 2005VBa- code to DLL
Is there a way to convert VBA-code into a .DLL (Dynamic Link Library)? Jan > 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 > 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.  SignatureRegards 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 Hi, A curiosity question: what's the advantage in converting to a DLL? Does the code run faster? Thanks, Jay > > Is there a way to convert VBA-code into a .DLL (Dynamic Link Library)? > > [quoted text clipped - 20 lines] > > because VB already has a Shape object in the Forms library. > 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. SignatureRegards 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 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 > 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. > 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. SignatureRegards 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 Thanks, I now understand. 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 [quoted text clipped - 11 lines] > for this purpose, so I cannot say whether the same is true for an ActiveX > DLL compiled in a .NET language. >> 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 [quoted text clipped - 11 lines] > 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 SignatureWorking Without a .NET? http://classicvb.org/petition |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.