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.
Related
I'm doing a gig where there is a need to write a few simple VBA macros for Word and Excel. This is a skill I haven't used in about 8 years -- and things have changed! Aside from the little detail that VBA is clearly in legacy mode, with minimal support, there's all the new security measures designed to close VBA as a malware vector.
Most of this can be worked around with a little effort. But here's a biggie: on some machines (not all for various reasons), the IT people have disabled VBA's ability to reference external libraries. If you give a user a VBA application that uses the MS scripting runtime (handy regular-expression API) or the automation library for another application (for controlling Word from Excel) they just don't work. If you open the VBA IDE on the user's machine, Tools/References is grayed out.
I could work with the IT people to re-enable library references, but there are also external users who might have this limitation. So I need a way to bypass it.
If I buy a certificate and sign the macros, will this give me back references? I can get them to spend the money, but I'm not going to do it unless I'm convinced it will solve the problem.
Can you use late binding?
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 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"?
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
Any good recommendations for a platform agnostic (i.e. Javascript) grid control/plugin that will accept pasted Excel data and can emit Excel-compliant clipboard data during a Copy?
I believe Excel data is formatted as CSV during "normal" clipboard operations.
dhtmlxGrid looks promising, but the online demo's don't actually copy contents to my clipboard!
I'm currently using dhtmlxGrid and we have the Excel copy/paste functionality working. dhtmlXGrid is the most full featured javascript grid package that I've found.
On their website, dhtmlXGrid claims to support Clipboard functionality in the Professional version. (However, I noticed the Sample on their site isn't working on my Firefox. EDIT: It's probably the permissions issue that Nathan mentioned.)
In any case, we had to do some extra work to get the exact Excel copy and paste functionality we wanted. We essentially had to override some of their functionality to get the desired behavior. Their support was pretty good in helping us come up with a solution.
So to answer your question, you should be able to get them to support copy and paste if you purchase the Professional version. I'm just warning you that it may take some additional work to fine tune that behavior.
Overall, I'm happy with dhtmlXGrid. We use a lot of their features. Their support is pretty good. They usually take one day to respond since they are in Europe (I think). And Javascript is by its very nature open source so I can always dive in when I need to.
Not an answer, but a warning: my company bought the 2007 Infragistics ASP.NET controls just for the Grid, and we regret that choice.
The quality of API is horrible (in our opinion at least), making it very hard to program against the grid (for example, inconsistent naming conventions, but this is just an inconvenience, we have complaints about the object model as well).
So I can't say that I know of a better option, I just know I will give a try to something else before paying for Infragistics products again (and the email support we got was horrible as well).
I was wrestling with this problem several years ago (2004 I think). We ran into the problem that Firefox doesn't allow scripts to read the clipboard by default (but you can grant access to the clipboard).
There's other ways of reading the clipboard data as well...Flash, for instance, can read the clipboard. There's a good article on ajaxian to explain how do to this behind the scenes.
In the end, we couldn't find a web-based Grid that fit the bill, so we had to create our own in a mixture of Actionscript and Javascript.
I'd hate to be Captain Obvious here...but what about a plain old .NET Gridview control? You can copy Excel data into it and out of it...and you can run it on any system with the .NET platform installed.
http://dhtmlx.com/dhxdocs/doku.php?id=dhtmlxgrid:clipboard_operations