Besides adding a password under Project Properties > Protection (Which I think is actually quite easy to hack), how can I prevent users from viewing / copying my code?
May be this is the good possibility: http://msdn.microsoft.com/en-us/library/office/aa189867(v=office.10).aspx
To provide the highest level of security for your VBA code, use
Microsoft Visual Basic version 6.0 to create a Component Object Model
(COM) add-in. Because the VBA code in a COM add-in is compiled as a
dynamic-link library (DLL), it can't be modified without access to the
source code used to originally create it. Application-specific add-ins
are not compiled; you must use the same protections as templates and
documents.
Related
Is there a way of storing VBA source code that's common and accessible to all Microsoft Office products..? I have a variety of functions which I use in both Access and Excel, and sometimes even Word. I modify and add to the the functions and modules frequently. The copying, pasting, and maintaining of code between projects can get tedious, and I inevitably overlook something.
I know I could do something like write a class/ocx/addin in VB6 or DotNet, compile it, and reference it in my VBA projects, but I was hoping for something more simple.
If there was a way to store VBA code in independent files, and open them with the VBA IDE in a standalone mode of some sort, that would be outstanding, but I know the IDE doesn't work that way...as far as I know.
I know I could do something like write a class/ocx/addin in VB6 or DotNet, compile it, and reference it in my VBA projects, but I was hoping for something more simple.
Unfortunately that's your best bet.
As you know VBA code is hosted, wrapped-up in a host document: a VBA add-in is still tied to its host document (.xlam, etc.), and as such can't be shared with another host.
In VBA-land what's meant to be shared between VBA projects, is type libraries - things you compile separately from the VBA project, and reference from as many projects as you like.
If you have a VB6 IDE, you can compile a 32-bit DLL that VBA projects can reference. The problem is that it won't work with 64-bit hosts - the solution is a .NET type library, written in the .NET language of your choice, made COM-visible. Note that COM-compatibility does restrict what you can expose in your API: for example you can't expose generics, and method overloads will look weird.
If a type library isn't an avenue you wish to explore, then your choices are rather limited, and IMO sub-optimal.
IMO the only thing that can "work" is a bunch of exported code files in some common folder, and the VBA projects that need to use that code need to literally import these code files. The risk here being, that if you make any changes, other VBA projects using an unmodified version of that code will not "see" these changes, IOW by doing that you're multiplying the number of times you need to fix a bug by the number of projects using that code.
Or you could have some code that uses the VBIDE extensibility type library to ensure the set of imported modules always match exactly with the exported files in that common location.
If you want to use VBA in the same Office program (e.g. one Excel file to another, or one Access file to another), you don't need to use any special kind of file. You can add a reference to an external database or worksheet with macro's enabled.
Navigate Tools - References - Browse - Excel/Access file - Add the file
See the following screenshot:
You can't use files across different Office applications this way, but you shouldn't. Each application has different built-in functions, so your code is likely incompatible anyway.
I have a SAP Business Objects Web 7.5 Add-in in Excel 2007.
The add in itself is made up of a compiled .xll file (CtExcelLinksWeb.xll) and a number of dll's.
A bit of vba shows the xll is registered, and all of its registered functions.
However, when I try to use one of these functions in VBA using Application.Run(), I get
Runtime 1004 - Macro may not be available or may be disabled.
I have tried registering the xll within the same sub (Application.RegisterXLL ()) and upon registering a VBAProject called CtEmpty.csv is created
I want to be able to automate the use of this add-in using VBA as it does long winded repetitive tasks, and then I can work on figuring out how to use the functions
Any help will be appreciated
Are the DLLs on the PATH? It may be that Excel can't load the DLLs that the XLL is dependent upon. Dependency Walker (depends.exe) is a handy tool for troubleshooting this kind of issue.
Also, have you tried using File/Options/Addins to register the XLL, as well as VBA code?
I have some VBA code that I use across multiple projects - about 40 or so different data bases all use many of the same functions.
I try to use the same code in application each for consistency. Is there a way I can put all the code in one library and make it available to each data base? I'm getting tired of copying the code to a new data base every time I want to re-use it. I'm especially getting tired of maintaining it in multiple places when I want to change the functions.
I have the same question for Excel - can I create an Excel library and include it in all my workbooks?
If the VBA code works in VB6, you could create a DLL using VB6. The DLL would be a library of methods you could use across board just by referencing the DLL.
If it does not, you should create an Ms Access MDA file (add-in file) for all your reusable code, that can be added into any Access (or probably Excel) project.
Create one or many excel's per project, save those as *.xla. (Excel Add-In)
Go to your Excel Options and configure to load automatically those add-ins or thru VBA in your workbooks.
Using VBA Automation:
Application.AddIns.Add(XLA_Path)
So I want to capture some key-commands in our Docuement-level Excel VSTO addin. I can't seem to find a way to do it, other than to use VBA and have our addin talk to the VBA. Any help/examples would be greatly appreciated.
I am using Excel 2007.
One method involves using the 3rd party solution from Addin-Express. Their product includes the ability to add a keyboard shortcut as a property to the ribbon menu commands.
The other way is to make use of low level keyboard hooks, through some Win32 API's which is generally referred to as windows subclassing. Here is an excellent explanation with code sample of how to do it. Note that the only "extra" thing you need to do to get this code to "work" in VSTO is moving the SetHook() method to the Startup event, and the UnhookWindowsHookEx() method to the Shutdown event.
Check out the article on MSDN here by Stephen Toub.
Finally there is the use of the OnAction property of the Addin class. This method requires the use of some VBA (in terms of a callback method that points back to the underlying .net addin), and works ok so long as you are willing to distribute some VBA in your solution (i.e. a xls or doc w/ vba project, or perhaps a native addin). Note you will also need to mark comvisible = true, and expose the GetAutomationServiceObject method so that your VBA can reference your addin from VBA code.
see here for a thread on it...
You can only do this through API calls to subclass Excel and watch for key commands. This is older, but it still applies.
We have an existing add-in that we publish to users via click once. We would now like to use this as a vehicle to publish some of our existing C# methods directly into Excel so that the users can call them as a UDF.
For example - I have an assembly called MyAssembly, that has a class called MyClass with a public method called MyMethod. I also have an excel addin which adds some item to the ribbon for some custom functionality. I would now like to publish MyAssembly with my existing addin so that a person who has the addin installed can enter =MyMethod into a cell and have my custom method run.
How would one go about doing this?
I solved this quite comprehensively by using ExcelDna, an open source XLL implementation which is very simple to use, and pretty much avoids the whole COM debacle all together. So far it has matched our requirements perfectly...
http://groups.google.com/group/exceldna
you have not been very verbose about what you want to do. What do you mean with "users can call them"?
If you mean that add-in methods should be exposed to VBA you can find two articles on that here:
http://blogs.msdn.com/andreww/archive/2008/08/13/comaddins-race-condition.aspx
http://blogs.msdn.com/andreww/archive/2008/08/11/why-your-comaddin-object-should-derive-from-standardolemarshalobject.aspx