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
Related
Hi I have this code and I want to translate it to any other programming language such as Python Java ruby
As you can see this is a raffle game user presses f5
And generates a raffle number such as Aqua 2231 7533 and stores all entries and at the end makes a random selection
This part is generation part
=LOOKUP(RANDBETWEEN(1,3),{1,2,3},{"Aqua","Blue","Red"})&" "&TEXT(RANDBETWEEN(0,9999),"0000")&" "&TEXT(RANDBETWEEN(0,9999),"0000")
And this part is the random selection
=INDEX(A:A,RANDBETWEEN(1,COUNTA(A:A)))
There are a couple of libraries which may be able to help. I don't know if they support the LOOKUP, RANDBETWEEN or TEXT functions specifically but as they are open source libraries there's potential for you, or someone you know, to add that particular functionailty (all of these projects welcome such input).
The libraries for Python that read Excel and generate Python code are;
PyCel
Formulas and Schedula
xlcaclulator (This is my project)
Koala
In each case these libraries have an "evaluator" which can actually run the generated Python code. Some of these evaluators are integrated with the Excel file reading functionality, in other cases it's separate.
PyCel and Koala2 have the evaluation functionality integrated with the Excel file reading functions. xlcalculator has them in separate objects. Formulas and Schedula have them in separate projects.
It's not easy for them to print out or save "vanilla" Python code due to what needs to happen to evaluate the generated code. The evaluation code needs access to the Python implementation of the Excel formula and, as things are at the moment, all of these projects use their own libraries with their own objects and their own mechanisms to call said objects. xlcalculator has attempted to extract the Python implementations of the Excel formulas to have a library anyone can use but it is also the most recently written so who knows how successful that will become. That library is called xlfunctions.
Providing the above mentioned projects support LOOKUP, RANDBETWEEN and TEXT functions, they will be able to read the function you've written (without the need for Excel to be installed), translate the function into Python code and execute the resulting code in Python.
Shouldn't be that hard.. Just :
Copy the formula & break it up in notepad++
For each function used, read up WORD-BY-WORD its documented documentation.
One you understand the data flow/change/list/start/end in the program.. use your mother tongue language, Ink it (the understanding) down. you may draw if it helps..
In the programming language of your choice, implement the "mother tongue" algorithm in that language.
Test the program with exactly the same input you gave to the original excel formula.. edit if necessary.
Since you didn't share ANY form of tries.. this is the best I have.. which works for me.. sorry if hurts/didn't solve..
Hope someone can improve/edit my answer for the better. (:
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'd like to give my boyfriend a taste of programming. If it was up to me, I'd teach Scheme, Haskell or F# but since he'd rather learn something that can be useful in his job as a fiscal consultant, i.e. programming Excel.
What are the options for programming Excel? Which one would you recommend for someone who's just learning to program and yet wants to get things done? Are there any books / resources you recommend for him (advanced Excel user, beginner programmer) or me (intermediate Excel user, advanced programmer)?
Thanks. I've started a blog about programming Excel to document our findings.
As a long time (business) Excel user and programmer, I recommend starting with a good VBA book that focuses on the key features of the Basic language, and how to communicate with the Excel objects (workbooks, sheets, etc). I wouldn't worry about userforms, initially - I haven't used those for years - and I wouldn't worry too much about databases at first either.
I suggest focusing on two areas in particular, starting with the Basic language itself, writing output to the Immediate window with Debug.Print and ignoring the fact that Excel is attached. You can get very good practice in this by solving some of the Euler problems, which favour pure code solutions with no user interface.
After that, I would learn how to talk to the Excel objects, and read as many Excel forums and web pages as possible to pick up tips. For example, it is much faster to read and write many cells at once, than one at a time.
And yes, VBA is not as full featured as most 'professional' languages, but it has one crucial advantage over most of them - it is much easier to write and for the average user to check, modify and maintain - and checkability and flexibility are crucial in the business world. Together with Excel, it is an amazing business tool.
There's basically two big options: he can write VBA code (macro's) or .NET code.
VBA code, being built on a simple language, has a low threshold. But if he's interested in programming in general, he might be much better off learning .NET (preferably C#). It's much more powerful than VBA and will teach him a lot more about proper software construction and essential concepts behind it.
I think it would be best to have him program some silly little Winforms applications first to get the basics down, and then look in to Excel interop. You can find a bunch of examples of C# / Excel intererop code by googling for "C# Excel". Here is one example:
http://dotnetperls.com/Content/Excel-Interop-Performance.aspx
VBA is VB6, in terms of runtime at least. It has enough OO capability to allow understanding of encapsulation and (sorta, without wanting to start a religious war) polymorphism/inheritance, if you'll accept that interfaces provide some aspects of those. If he spends a lot of time in Excel, then I'd expect there to be some repetitive things he does at present that could benefit from recording a macro, then learning to clean it up. That can lead to writing his own worksheet functions, loops, all kinds of useful stuff. If he's genuinely advanced (pop quiz: does he know about putting formulae in names? Is he comfortable with array formulae?) then there will be things that he's annoyed with where VBA can help.
I think I'd ignore .Net for now, it's too big and it will take too long for him to be able to produce his own solutions.
Alternatively, just teach him Ruby. It's what I'll be starting my kids on when they move on from Scratch.
VBA is a great starting point for someone new to development and wants to get a handle on the basics. It is possible to program Excel through many different languages by leveraging the Excel or Word COM libraries. This can be done easily in languages such as C# but is not suitable for someone starting off with programming.
Just word of caution. Although VBA is a fully featured programming language and is capable of supporting complex applications it can encourage poor programming practises. I have seen this occur in large organisations that use Excel extensively for actuarial calculations. Essentially the code was written by actuaries with finacial calculations in mind - not software engineering.
In the long run enterprise programming languages such as Java or C# are better.
Macros are one way to program Excel.
Check out this YouTube video:
http://in.youtube.com/watch?v=k_fWcffRAG4
It demonstrates how to Record and use Macro.
You can do a great deal with VBA, probably more than someone in finance would ever wish to do. VBA is intended, I believe, for just such people, but it generally gets bad press. I think that if you, a programmer, taught your boyfriend VBA, he would develop some understanding of programming and also have to hand an extremely useful tool for work, far in advance of anything that can be achieved by recording macros. In addition, it is a very short step from VBA to VBScript.
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