I am doing a lot of similar tasks among some VBA scripts I am writing and would like to develop a library (a bunch of convenience functions using the typelib I'm working with) which I can call from all my various scripts. I am new to the VBA world and do not know how this is done and have had a surprisingly hard time trying to figure it out.
I think what I was looking for is an Add-In. Thanks everyone for your information.
Does this example help? It appears to also have a fix to a common issue when setting this up - You didn't mention which version of office - But 2003 is mentioned in that thread, so should be the fairly straight forward common case.
http://socko.wordpress.com/2008/06/01/vba-code-library/
Another option you have though it depends on the nature of your functions, is to create a COM object that you can call from your VBA scripts.
You can easily create a COM object using many languages including Delphi and VB (old style) it is also possible in .NET though a little more involved. You can then do your calculations in your COM object and even pass in the excel worksheet etc you wish to manipulate if required.
Depending on the nature of your functions this may or may not be useful.
You will need to use VB to do this. With Microsoft plug-ins to VB, you can manipulate Excel files without even opening them, much like you do now. The code will be very similar once you have the file open.
I would transfer all my code to VB and after its working like you have your VBA macros start making libraries out of the common stuff.
Lots of work, but if you really are doing a lot of this stuff, it will be great in the long run. (Job security too ;)
Check the comments here
http://www.dailydoseofexcel.com/archives/2004/10/15/code-libraries/
Related
I've put together a simple Excel database that performs a few macro functions and I need to distribute this database to a few people - but they cannot see how the macro function actually works (stupid rules I have to follow!). What is the best way to achieve this?
I've done a bit of research and I found two ways:
Password protect the VBA project; but this is apparently very easy to break using readily available tools online (it would be in the best interest to the people I'm sending this to find out how the macros and functions work; so I'm almost 100% sure they will try to get into it.. hence a password protection seems inadequate.
Move to a fully compiled language like C++; my skills are very limited to VBA on Excel and Access so this being the ideal solution; isn't a solution for me :(
Are there any other ways? I thought of having a 'master excel document' with all the macros in that and then send 'children' databases to the end users and have the 'children' databases connect to the 'master' - is something like this possible? By hosting the master online or even sending the end users the master but making it completely inaccessible unless accessed by the 'children' databases?
You can create Automation Add In.
An Automation Add In provides several advantages
Execution Speed : An Automation Add In written in VB6 is compiled to
native machine code which runs much faster than the interpreted VBA
languange.
Security : Unlike an XLA add in, you never distribute the source code to the end users. If your code has proprietary information or
intellectual property value, that remains safely protected on your
own computer. It is never distributed to the user. Your code can
never be compromised.
http://www.cpearson.com/excel/automationaddins.aspx
There aren’t too many ways to protect your Excel VBA code reliably.
You can try to use passwords or VBA obfuscators, but all of that protection is limited. Passwords are easy to break, and obfuscated VBA code can still be traced back and recovered.
The other answer to this question mentions using VB6, but that limits your code to 32bit Excel. Also VB6 can be decompiled by VB decompiler.
Converting your code to a compiled language is indeed the best way to protect your VBA code, but be warned that in this case not all code is created equal.
Converting your code to VBA.NET is a flawed solution because the compiled code of .NET assembly can be converted back into the original source code.
Converting your VBA code to C or C++ is the most effective form of protection, but this takes a lot of experience and effort since C/C++ and VBA are very different languages.
I would suggest you have a look at a tool called VBA Compiler for Excel (https://vbacompiler.com/how-to-compile/). It compiles your Excel VBA code into a DLL file with a click. You do not need any knowledge of C or C++ languages to use it.
If you're still looking for a good way to protect your Excel VBA code from copying or tampering, then you should consider the Excel VBA compiler of XLS Padlock.
Because XLS Padlock offers an integrated VBA compiler that can compile your VBA code into binary code, making it completely secure and inaccessible to others.
it's really binary code and not simple obfuscation.
You open the VBA compiler of XLS Padlock, move some vital parts of your existing VBA code into it (subs or functions) and it compiles live. You can then invoke this compiled code directly from your normal VBA project using dedicated functions.
It's like having several modules, except that some modules are compiled into bytecode and thus secure.
No need to learn a new language C or C++ or VB, nor COM add-ins.
Plus, XLS Padlock can wrap your Excel workbook into a secure shell application, which you can then distribute and even sell to your customers.
It does not create DLL files that must then be distributed among your workbook files (imagine if your other non-tech users lose the DLL or don't know what it is), the software compiles spreadsheets + compiled code into a single EXE file.
It is even possible to add licensing features, online activation if you want to sell your workbooks or control who uses them, while keepking your VBA code secret.
For security purpose, I want to save my macros from VBA in Excel workbook to DLL library file I'd be calling from the file later.
This way it is possible to deploy any version of my macros to company's PCs but noone would ever see the real code behind it.
How is this possible? I've read on converting to C++ and creating DLL. Is there any step-by-step solution for this?
First off, let me warn you against this in general. We did this once with a corporate app and the time it took to port was approximately the same as the time it took to write the app originally. A step-by-step guide won't exist for this because you're basically rewriting the app from scratch.
Secondly, not everything your Excel VBA can do is necessarily available in COM, or XLL. The events available are different; in the case of XLL there are entirely new structures to use for all of the data types. In COM there are no UDFs; in XLL there are no macro actions. You will no longer be able to attach code to worksheets (only Excel sessions) and the install procedures are much more complex. I would spent a long time researching what your VBA does exactly before embarking down one particular path.
It depends how large your app is, but I would encourage you to invest the money in getting watertight licenses drawn up and doing some basic code obfuscation (as per the original comments) rather than starting from scratch with a different architecture.
You can protect your VBA, code by converting it to a password-protected XLA and obfuscating the code. but the password security is weak. Its easy to make the XLA work with all Excel versions.
An easy alternative is to convert to a compiled VB6 Automation addin. Security is good, its easy to convert, it will handle both UDFs and Command addins. But it won't work with Excel 2010-64 or early versions of Excel like XL 2000. You will need a VB6 compiler, which can be hard to find.
A harder alternative is to convert to .NET. If you use one of the many obfuscators then security is reasonable. Performance will be poor unless you use one of the tools that allow .NET access via the XLL interface, such as Excel DNA or Addin Express. 64-bit capability is also available.
If performance and security is critical you would need to convert to a C++ XLL, but this is hard work when coming from VBA.
a) You can save your macro in a separate file and protect it with password but, exist program for "recover password" that can break such protection.
b) While is possible to do a c++ dll, is smart to do instead using visual basic 6 because the syntax is pretty similar to vba. In vb6 you can create a COM component, register it and later add to you excel sheet.
You did not mention your target Excel version, but I will give a general view.
Make sure your code is appropriate for an AddIn. E.g: instead of ThisWorkBook, use ActiveWorkbook.
Also decide if you need to create a menu or use shortcut keys, and modify your code accordingly, and protect it.
In VBE, change to IsAddin property to True.
"Save As" your file and select Excel add-in. Alternatively, just save it and rename the extension from .xls to .xla
Now either inform your users to "open" that .xla, or reference it in your projects, or put it in the autostart folder or....
You're done
http://www.ozgrid.com/VBA/excel-add-in-create.htm
http://excel.tips.net/Pages/T002927_Creating_AddIns.html
http://msdn.microsoft.com/en-us/library/aa140936(v=office.10).aspx
Converting VBA code to C++ is a pretty arduous process, since C++ and VBA are very different languages, but such a conversion with compilation to a DLL file really does provide the best VBA code protection out there.
If you want a tool that does exactly that, I would recommend the VBA Compiler for Excel. It converts your VBA code to C and compiles that C code into a DLL file.
It's easier and faster than converting your VBA code to C by hand.
VBA Compiler website has a simple 10-step guide on how to compile VBA code into a Windows DLL file https://vbacompiler.com/how-to-compile/ and it doesn’t even require any knowledge of C or C++.
I ve heard things like you cannot manipulate tables in C# but can through VBA.
Does any one know what can be done via VBA which cannot be done via C# PIA?
One thing I remember while working on a Excel addin was that the OnAction method of pictures/shapes added on a worksheet will not call into the C# addin which seems like a limitation. You can set the OnAction to a VBA macro only.
This might not be directly related to your question on the differences in C# and VBA but it just crossed my mind when I saw the questions.
Fundamentally, there is no real difference. You can do pretty much anything in either environment, especially if you're talking about VB.net and C# - they are more or less different syntaxes that target the same libraries and platforms.
There are some syntactical differences where certain features of one language do not have direct equivalents in the other, but as long as you have a few basic elements you can write code to achieve the same ends in both.
In some programs you can use VB script (which is a variant of VB) for macros, and in those cases C# can't be used as a direct replacement. But that is a limitation of the host programs, not of VB/C# per se.
edit:
You've changed the question completely now, so this answer is probably no longer relevant.
You cannot debug a problem as it happens on a user's PC with C# because you will not have Visual Studio installed there. With Excel VBA, you can debug from any PC you run the code on.
EDIT (response to Anonymous' comment)
Whilst you can remotely debug this is not the same, as far as I understand. It requires at least the firewall to be opened up to permit the debug traffic (will likely require some major signoff in big corporates) and you cannot debug and repair an ongoing user problem as it happens. Obviously this can't be done with most programming environments, but it was one of VBA's strengths - well, depending on your point of view, I suppose.
i think the most important difference from a business perspective is that with C# you no longer have as many "non programmers" lob managers, etc that can produce code (macros).
The process is inherently more formalised.
In terms of syntax there are lots of differences... but none that are really an issue in terms of the ability to make use of the object model.
Sometimes you will find C# requires a few more lines of code, but in others less. Also you will find that alot of the times where you were required to use System API calls are now redundant.
Although I've done VBA projects within a single application for both MS Access 2007 and Excel 2007, I haven't automated multiple applications at the same time. The generalized project is to open access, run some update queries that appends data to various tables. Then Excel needs to get the data. Some formating changes are needed in Excel, such as grouping that doesn't automatically change the date range. Finally, I plan to build it out such that the excel file will be emailed automatically.
Some parts of this are clear how to accomplish it, such as Excel will be getting the data by ODBC from Access. But where should the master VBA live? I could have a button in Access that would start running Access VBA, but is it a good practice to have the Access VBA start manipulating Excel? Does that make it difficult to debug?
To get started from Access, add a reference to the Excel object library. Then use the object browser to familiarize yourself with how the Excel object hierarchy looks from within Access. It is going to be somewhat difference, because the top-level object in Excel code is implicit (as it is in Access), and has to be explicitly referenced when coding in Access.
The Access Developers Handbook has excellent chapters on automating the rest of Office from Access.
Last of all, it's best once you've coded using the reference to the other app's automation library to help you program, you want to switch to late binding so you can remove the reference. This means not using any of the external library's specific data types (you mostly use plain object variables) and using none of the constants defined in the external library. My production code with late binding usually includes the early binding version commented out, alongside the late binding version.
I think the keywords you are looking for is "microsoft office automation".
Make an application in you favorite programming language that supports COM interfacing and then use automation to do the manipulations in the different office applications.
Look here c# How to access an excel cell? and here How to read data of an excel file using c# ? and Google.
I have recently done something quite similar to this, and have found that I can output HTML with built-in CSS for formatting that loads quite nicely into Excel. I used Access to allow users to build their required output, only opening Excel to display the results. You may find that HTML output makes for nicer emails.
Do all the work in Access VBA. See the following URLs for some sample code
Modules: Sample Excel Automation
Modules: Transferring Records to Excel with Automation
Also note that if you are dealing with multiple versions of Excel late binding becomes a necessity. Late binding means you can safely remove the reference and only have an error when the app executes lines of code in question. Rather than erroring out while starting up the app and not allowing the users in the app at all. Or when hitting a mid, left or trim function call.
This also is very useful when you don't know version of the external application will reside on the target system. Or if your organization is in the middle of moving from one version to another.
For more information including additional text and some detailed links see the Late Binding in Microsoft Access page.
As far as emailing goes there are a number of options at the Microsoft Access Email FAQ
You may put the code in Access, or Excel. In my experience, that is easier to work with than splitting the code between the two (which also works).
If you find that the automation code runs too slowly, you can split the code, so that Access is run by functions in Access, and Excel from functions in Excel, and the master code just runs routines in both. In this case, you can put the master code where-ever you get the nicest user interface for starting things. I've used C,Access,Word and Excel, and where you put the start button doesn't matter a whole lot if all the code is somewhere else.
If your users or maintainers are more familiar with one application, you may wish to put your main or master code there, but more often I find it is better to put the main or master code with the guts of the application, so that I can have no code at all in the other partner.
From the brief description, it sounds like more work will be done in Excel, so I would put all the code there.
Pulling the data out of Access doesn't even need an Access Application object - a DAO or ADO or ODBC object will work (or even DDE), which will be much faster, much more robust, much easier, much better than having both applications open and automating one from the other.
If you start from Access, it sounds like this project will require an Excel automation object. That works well now, but it is still much slower and more fragile doing it with just Excel and a DAO object.
I haven't done VBA for ages although Access was my entry-point into the world of programming. Moving from Access 97 to Visual Basic was easy and I remember that I wrote a lot of stuff using Access more like a VB-form for doing many kinds of tasks (not necessarily database-stuff).
This is the reason why I think you should stick to Access and from there, with help of VBA, do your stuff in Excel etc..
Good luck
I have an old Excel 4 macro that I use to run monthly invoices. It is about 3000 lines and has many Excel 5 Dialog Box sheets (for dialog boxes). I would like to know what the easiest way would be to change it into VBA and if it is worth it. Also, if once I have converted it to VBA, how to create a standalone application out of it?
I have attempted this before and in the end you do need to rewrite it as Biri has said.
I did quite a bit of this work when our company was upgrading from Windows NT to Windows XP. I often found that it is easier not to look at the old code at all and start again from scratch. You can spend so much time trying to work out what the Excel 4 did especially around the "strange" dialog box notation. In the end if you know what the inputs are and the outputs then it often more time effective and cleaner to rewrite.
Whether to use VBA or not is in some ways another question but VBA is rather powerful and extensible so although I would rather use other tools like .NET in many circumstances it works well and is easy to deploy.
In terms of is it worth it? If you could say that you were never ever going to need to change your Excel 4 macro again then maybe not. But in Business there is always something that changes eg tax rates, especially end of year things. Given how hard it is to find somone to support Excel 4 and even find documentation on it I would say it is risky not to move to VBA but that is something to balance up.
(Disclaimer: I develop the Excel-DNA library)
Instead of moving the macro to VBA, which uses a COM automation object model that differs from the Excel macro language, rather move it to VB.NET (or C#) running with the Excel-DNA library.
Excel-DNA allows you to use the C API, which mirrors the macro language very closely. For every macro command, like your dialogs, there is a C API function that takes the same parameters. For example, the equivalent of DIALOG.BOX would be xlfDialogBox - there is some discussion and example in this thread: http://groups.google.com/group/exceldna/browse_thread/thread/53a8253269fdf0a5.
One big advantage of this move is that you can then gradually change parts of your code to use the COM automation interface - Excel-DNA allows you to mix and match the COM interfaces and C API.
AFAIK there is no possibility to somehow convert it. You have to basically rewrite in in VBA.
If you have converted to VBA, you cannot run as a standalone application. As VBA states Visual Basic for Application, it is living inside an application (Word, Excel, Scala, whatever).
You have to learn a standard language (not a macro-language) to create standalone applications. But you have to learn much more than the language itself. You have to learn different techniques, for example database handling instead of Excel sheet handling, printing instead of Excel printing, and so on. So basically you will lose a lot of function which is evident if you use Excel.
Here is a good artikel about this topic: http://msdn.microsoft.com/en-us/library/aa192490.aspx
You can download VB2008-Express for free at: http://www.microsoft.com/express/default.aspx