I am trying to understand some old Excel VBA code. I would like to create a call graph to help.
Quite some time ago, in other programming languages, I had a lot of success with things like VCG, but I don't know enough about VBA to decide whether such a thing is even feasible. And so far my results of searches like Excel and graph have been difficult to sift. There doesn't seem to be anything here on SO associating Excel or VBA with the existing call-graph tag.
There are some commercial products that will do this analysis.
http://www.vbdepend.com/
But you might also consider Rubberduck-VBA. It doesn't make graphs (yet), but it does do a thorough job of analyzing your code. And it's free and open-source.
Disclaimer - I'm a contributor on Rubberduck.
Related
I have a busy set of routines to validate or download the current client application. It starts with a Windows desktop shortcut that invokes a .WSF file. This calls on several .VBS files, an .INI for settings, and potentially a .BAT file. Some of these script documents have internal functions. The final phase opens a Microsoft Access database, which entails an AutoExec macro, which kicks off some VBA, including a form which has a load routine of its own in VBA.
None of this detail is specifically important (so please don't add a VBA tag, OR criticize my precious complexity). The point is I have a variety of tools and containers and they may be functionally nested.
I need better techniques for parsing that in a flow chart. Currently I rely on any or all of the following:
a distinct color
a big box that encloses a routine
the classic 'transfer of control' symbol
perhaps an explanatory call-out
Shouldn't I increase my flow charting vocabulary? Tutorials explain the square, the diamond, the circle, and just about nothing more. Surely FC can help me deal with these sorts of things:
The plethora of script types lets me answer different needs, and I want to indicate tool/language.
A sub-routine could result in an abort of the overall task, or an error, and I want to show the handling of that by (or consequences for) higher-level "enclosing" routines.
I want to distinguish "internal" sub-routines from ones in a different script file.
Concurrent script processing could become critical, so I want to note that.
The .INI file lets me provide all routines with persistent values. How is that charted?
A function may have an argument(s) and a return value/reference ... I don't know how to effectively cite even that.
Please provide guidance or point me to a extra-helpful resource. If you recommend an analysis tool set (like UML, which I haven't gotten the hang of yet), please also tell me where I can find a good introduction.
I am not interested in software. Please consider this a white board exercise.
Discussion of the question suggests flowcharts are not useful or accurate.
Accuracy depends on how the flow charts are constructed. If they are constructed manually, they are like any other manually built document and will be out of date almost instantly; that makes hand-constructed flowcharts really useless, which is why people tend to like looking at the code.
[The rest of this response violate's the OPs requirement of "not interested in software (to produce flowcharts)" because I think that's the only way to get them in some kind of useful form.]
If the flowcharts are derived from the code by an an appropriate language-accurate analysis tool, they will be accurate. See examples at http://www.semanticdesigns.com/Products/DMS/FlowAnalysis.html These examples are semantically precise although the pages there don't provide the exact semantics, but that's just a documetation detail.
It is hard to find such tools :-} especially if you want flowcharts that span multiple languages, and multiple "execution paradigms" (OP wants his INI files included; they are some kind of implied assignment statements, and I'm pretty sure he'd want to model SQL actions which don't flowchart usefully because they tend to be pure computation over tables).
It is also unclear that such flowcharts are useful. The examples at the page I provided should be semiconvincing; if you take into account all the microscopic details (e.g., the possiblity of an ABORT control flow arc emanating from every subroutine call [because each call may throw an exception]) these diagrams get horrendously big, fast. The fact that the diagrams are space-consuming (boxes, diamonds, lines, lots of whitespace) aggravates this pretty badly. Once they get big, you literally get lost in space following the arcs. Again, a good reason for people to avoid flowcharts for entire systems. (The other reason people like text languages is they can in fact be pretty dense; you can get a lot on a page with a succinct language, and wait'll you see APL :)
They might be of marginal help in individual functions, if the function has complex logic.
I think it unlikely that you are going to get language accurate analyzers that produce flowcharts for all the languages you want, that such anlayzers can compose their flowcharts nicely (you want JavaScript invoking C# running SQL ...?)
What you might hope for is a compromise solution: display the code with various hyper links to the other artifacts referenced. You still need the ability to produce such hyperlinked code (see http://www.semanticdesigns.com/Products/Formatters/JavaBrowser.html for one way this might work), but you also need hyperlinks across the language boundaries.
I know of no tools that presently do that. And I doubt you have the interest or willpower to build such tools on your own.
I have an excel sheet which has many functions split across many modules and classes. I would like to know which functions / subroutines are actually being used and which I can actually eliminate. Is there any way I can produce some sort of log which would tell me this ? (I was told MZ tools may be able to provide this but was unable to find it). Thanks.
Not sure if this is an answer, but have you looked at
http://www.mztools.com/index.aspx
Make sure you download the right version, though.
By the way, I've been using MZtools (free) for a while, and I can guarantee that it's a very good piece of software for that price.
I'm a civil engineer designing a program that allows the user to define number of cross sections of a roadway and then calculate the quantity of the different materials used to build the roadway layers. I need to be able to plot a representation of the cross section that the users has defined. I'm not sure if this would be best accomplished by plotting various series on a chart, or drawing shape objects. Does anyone have any thoughts?
Yeah, not only is Excel pretty good for this, it's also pretty common to use it for this. The Newton Excel Bach blog may be where you want to spend some good time - it's an Excel for engineers site. He's got a great series on drawing with Excel. Here's one that addresses your immediate question: Drawing in Excel 7 – Creating drawings from coordinates
Since I know nothing about your problem domain or your programming skills, I can only give some general thoughts:
Excel is really good for modeling and building certain prototypes. Modeling this problem and building some charts by hand should give you and your users a good idea if the Excel solution is going to fly. If you can't get the graphics you want I would look elsewhere. Perhaps Visual Studio and Visual Basic or C#. These have mature drawing capabilities and also charting controls in recent editions.
Excel VBA has a pretty good programming layer for charts. You can also draw custom objects with VBA. I have not done this but I am sure there are references on the web. In any event, if the manually built Excel prototype looks good, it might be worthwhile to automate it with VBA.
Another factor is how many, and of what skill set will the users be? Fewer users, who know Excel pretty well make a case for using Excel. Supporting a large number of users could become onerous as it is possible to change the code in an individual file.
Finally, how long will this application be around? Versioning Excel applications can be done, but it easier to do this with more sophisticated programming environments. Also if you are going to continue to add features you might run into a wall with VBA's feature set. Hope this helps.
Do any of you use the javascript macro capabilities of Google Apps, particularly for spreadsheets? How do the capabilities compare? Is there anything that Google Apps can't do that can be done with VBA macros?
I am in the middle of conversion of a complex project from VBA to Google Apps Script as an experiment to see what can be done and what can't.
In general, the development environment for google apps script is primitive and frustrating. The language is of course javaScript so if you already know that then you have a head start. The problem though is that many of the advantages of javaScript are not realizable since you don't actually have access to DOM elements, and neither do you have an equivalent of Excel shapes - except through the UI object- which is essentially the same as an excel form, with the same kind of events and objects etc.
Another issue is general slowness. You need to be careful how you structure, so that you minimize calls to the spreadsheet data (I got round this by building a values cache), and scalability is very questionable.
I am equally at home with javaScript or VBA, so putting language aside, VBA is currently more fulfilling and quicker to get things done, although there are increasing capabilities built in to apps script to make it extremely promising.
I am logging the progress of my migration, and the things I come across and the battles to figure out how to minimize structural change (I am trying to see if I can come up with something that would allow dual maintenance on both platforms), so if you are interested, you can follow along here
http://ramblings.mcpher.com/Home/excelquirks/gooscript
Bruce
The VBA in Office has been the same for about 10 years now, still using old VB6. The limitations of that language are endless. No data structures, no logic short-circuiting, limited types, non-object oriented. Google Apps and javascript are presumably on the forefront of technology and so it should not have many of these limitations.
As for what each is capable of doing that the other can't, that's a little more difficult to assert. I would argue that both languages are more or less turing complete, so while it may be more or less difficult to do something in each language, in theory, a good enough team of programmers could do just about anything in either.
Cheers :D
I'm trying to create charts in google spreadsheet using google apps script and is seems not possible... It is fairly easy in VBA, maybe vb6 is 10 years old but on the other hand you're able to do everything what you need with your spreadsheet. This is not the case in google scripts though.
One of the major hurdles is that Google Apps is web based. Thats were most companies cringe at the thought that you would have your own data not stored securely within your own network. I would never trust Google with that sort of data. I'm sure they have secure data connectors, but why take that risk?
Sure VBA is outdated, and not as sexy as javascript. However, its a great tool for quickly writing small applications, and getting it to the user fast. You only really hear nightmare stories about applications that were built by non-programmers using VBA.
It really depends on your project, and what you want to accomplish. Both have their limitations.
Having taken a quick look at Google Spreadsheet API I get the impression that its currently somewhat limited, for instance:
fewer Events, no control of calculation?, no way of writing UDFs?
Has anyone tried using it for serious work?
By its nature, a Google spreadsheet will not be able to do many things a local program will do. Example: a macro that would import all csv files in a user specified folder and consolidate them.
One thing that springs to mind is that VBA has full access to the WinAPI through 'Declare Function' declarations. Google Apps script won't have this access. This is something to watch for if you're converting a spreadsheet between the two.
I would like to learn some VB because I am interested in a few industries that tend to use it exclusively. However, I find most resources far to slow in teaching the language and tools because they are aimed for those who haven't programmed before. Is there a good guide for programmers with experience in other languages like java and ruby?
Thanks,
Steven
The best way to learn is to fire up excel, or whatever version of VBA you're going to use (yes they are subtly different). Turn on the macro recorder, do some stuff, stop recording and then look at the code created. You'll immediately see some of the classes created, they can be looked at in more detail using the Object Explorer within the VBA environment. The syntax is just like any basic language. A couple of good practises, put the line 'Option Explicit' at the top of every source file, if not variables don't need to be declared, which is initially easy but leads to annoying bug hunts.
I'm not aware of a one stop shop to learn VBA, as you've already got programming experience it'll be a matter of unlearning some stuff - like OO, inheritance etc (yes I know VBA supports classes and interfaces but they're not the full enchilada).
BTW I noticed you tagged this as VB.Net, unfortunately VB.Net is not VBA - they're not related at all. Similarly VB and VBA are not the same although the overlap is about 90%.
Writing Excel Macros with VBA, 2nd Edition by Steven Roman, ch. 5-8 has a reasonably compact tour of VBA syntax, built-in functions, etc. You can find it on Google Books. Most of what it says should apply to VB6 as well.
There is also the Visual Basic 6.0 Programmer's Guide available for free on MSDN
However, MrTelly has the best advice if you're already familiar with programming in general. The Excel VBA editor, the macro recorder, and the F1 key are probably all you need, plus the basic help on specific syntax for control structures, etc.
This might be helpful.
Quite a few years ago a DDJ's columnist calling herself Verity Stob wrote a good summary of typical gotchas awaiting an experienced programmer starting developing with VB/VBA:
http://www.ddj.com/windows/184403996;jsessionid=HZEBCTTLEH5XGQSNDLPCKH0CJUNN2JVN?_requestid=378977
Excel is a good place to learn VBA.
A good resource is the book VB/VBA In a Nutshell