I have always wondered if whatever actions we do are actually translated into VBA Macros before it is executed. Is that how we are able to record macros? If not, would you call it a redundancy in design? Would it be faster/slower it ain't the way it is now?
No, they aren't translated. What happens is that most UI commands execute the same code as the VBA commands.
Also, VBA isn't executed directly but the code is first translated to byte code, a compact form of the code which allows to quickly look up which compiled routine to invoke.
In recent years, with much more powerful computers, I've toyed more than once with the idea to turn an application into a huge library for a scripting language and then implement the UI with said scripting language - that would allow for the ultimate personalization of the app.
Sadly, people still hang to the idea to do UIs in XML or C++ than in Python or LUA which would be much faster to write and change. Can you say "It's always been that way"?
Related
Alright, so I don't really know much about COM. What I do know is that if you write code in one of the Microsoft-sponsored programming languages, then you can write something like 3 lines of code to launch Excel, open a blank workbook, stuff some data into the cells and tell Excel to graph it. But I have no idea how this black magic actually works; all I know is that it's related to COM somehow.
Is it possible to do this kind of thing with Haskell? Is it "easy", or is it going to be hellishly difficult? Because if it's easy, I might try and get this to work, but if it's really hard, there are simpler ways to make Excel graph things...
I'm aware that you don't actually need to learn COM just to graph stuff. (E.g., I could use GraphVis or GNUplot, or Google Chart, or write a small Cairo function, or...) I'm interested in how easy or hard it is to do COM with Haskell, and this is just a motivating example.
HDirect used to be the standard, as it was last uploaded 3 years ago I imagine it's bitrotted a fair bit.
Looks like there's a new package aimed at doing the same sorts of things.
Sorry, I'm may be a little bit late.
There is already someone who plays with excel:
Excel Automation with haskell gives a seg fault
I've written some scripts who communicate with Clearcase and Clearquest.
It was quite easy until I get problems with variant StringArray (look
at my question on SO).
I've used HDirect in order to generate the Haskell glue code. The procedure is:
launch the OLE/COM Object Viewer and select View Typelib in the File menu
select the DLL (e.g. ccauto.dll for Clearcase)
save the IDL file
run HDirect on this IDL file in order to get the haskell glue code
import it in your project
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.
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/
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.
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