Thursday, January 19, 2017

Parsing UserForm and Code Modules in VBA

Some research into what's possible with VBA and code generation of JavaScript for a proof-of-concept project.

In order to parse a UserForm and VBA code modules, first enable Microsoft Visual Basic for Application Extensibility in the Tools / References feature:

For this example create a simple UserForm:

The Parse button should be wired up to call the Parse() subroutine in the Module1 code module. The entire source will be listed in the worksheet when this Parse routine is run.

Here's the code to place in Module1:

1:  Option Explicit  
3:  Sub Macro1()  
4:    Form1.Show  
5:  End Sub  
7:  Sub Parse()  
8:    Dim cmpComp As VBIDE.VBComponent  
9:    Dim cCont As Control  
10:    Dim lRow As Long  
11:    Dim lLine As Long  
13:    Sheets("Sheet1").Activate  
14:    ActiveSheet.UsedRange.ClearContents  
16:    lRow = 0  
17:    lRow = SetRow(lRow, "Show UserForm and VBA Code Modules")  
18:    lRow = SetRow(lRow, "Workbook " & ThisWorkbook.Name & ", Protected = " & ThisWorkbook.VBProject.Protection)  
19:    For Each cmpComp In ThisWorkbook.VBProject.VBComponents  
20:      lRow = SetRow(lRow, "Component Type = " & cmpComp.Type & ", Name = " & cmpComp.Name)  
21:      Select Case (cmpComp.Type)  
22:      Case vbext_ct_MSForm:      ' UserForm  
24:        ' Form1 is hardcoded here. If you include this code to traverse the  
25:        ' controls in the UserForm Code itself you can use "Me" instead of "Form1"  
26:        ' if you know of a way to parse controls in a UserForm using a string variable  
27:        ' or better yet, from another worksheet, please let me know  
29:        For Each cCont In Form1.Controls  ' Form1 here, could use "Me" in UserForm code  
30:          lRow = SetRow(lRow, " Control type = " & TypeName(cCont) & ", Name = " & cCont.Name)  
31:        Next cCont  
33:      Case vbext_ct_StdModule:    ' VBA code  
34:        lRow = SetRow(lRow, "Lines of code = " & cmpComp.CodeModule.CountOfLines)  
35:        For lLine = 1 To cmpComp.CodeModule.CountOfLines  
36:          lRow = SetRow(lRow, Format(lLine, "00#") & ": " & cmpComp.CodeModule.Lines(lLine, 1))  
37:        Next lLine  
38:      Case vbext_ct_Document:     ' worksheet  
39:        ' not UserForm or Code so other type of worksheet  
40:      End Select  
41:    Next cmpComp  
42:  End Sub  
44:  Function SetRow(lSheetRow As Long, sLine As String) As Long  
45:    SetRow = lSheetRow + 1  
46:    Cells(SetRow, 1).Value = sLine  
47:  End Function  

Here is the partial output when running Macro1:

What I'd still like to be able to do:

  1. Reference the UserForm with a variable instead of hardcoding. I tried using UserForms(cmpComp.Name), but no go.
  2. Reference the UserForm from a different (loaded) workbook. I think the issue might be that the Visual Basic Editor needs to have the UserForm loaded in order to traverse the controls.

Saturday, January 14, 2017

Converting Excel VBA Prototypes to Production Reports on the Web

I'd previously explored how to move Excel VBA prototypes into a production environment and did not find a satisfying path with Microsoft technologies.

An idea for an approach that I may try as a proof of concept:

1. The Excel VBA Macro would need to be created with a specific set of coding rules and form controls. This is not intended to be a general purpose macro converter and is just being designed for some of the practices I have used over the years. It might serve as a basis for a broader converter down the road. There is still a lot of code written in Excel VBA and it's not a market that is attracting a lot of developer tool competition. It's worth looking into building a set of libraries in VBA similar to how the Google Apps Script (GAS) functions are organized for possible leverage there some day, but the intent is not to put one prototype product into another prototype so GAS is not the target of the code generation in step 3 below. A useful site related to VBA and GAS. As I think about it, if my situation allowed for using Google for authenticating users, the GAS environment is fine for low volume usage (or scale for that matter). We just happen to be a multi-vendor environment and Google is not a primary vendor for us.

2. For Excel VBA Macros used to create reports manually it's often not practical to have end users execute it directly for complexity / security / etc. reasons. The easiest solution in a non-production environment is to distribute the reports instead of having end users access the capability to produce them directly.

3. Having written code generators in the past, they are not as challenging as you might think as long as you restrict their flexibility. Node.js is a fertile environment these days and provides a number of packages for manipulating Excel worksheets. Bootstrap is just one of many options, but I'll use it for the POC because I've been experimenting with it recently related to the AppStudio product.

4. Once the code is generated, it will probably be necessary to add enhancements to pull data directly from SQL databases and/or APIs instead of from manually extracted Excel workbooks. The goal is to move as much functionality as reasonable from Excel VBA into modern JavaScript and then enhance. Features like login / authentication don't fall into the domain of Excel VBA so would need to be provided in the web production environment.

This is labeled "low volume usage" because we're taking prototype code and placing it in a production environment as inexpensively and safely as possible. If a higher volume usage or a more sophisticated approach is needed, plan to spend more effort. For example, we'll probably invest and have development staff create an SSIS/SSRS/.NET solution consistent with much of our production environment.

Fredrick Brooks of course has a lot to say about this in The Mythical Man Month (Chapter 11: Plan to Throw One Away). And for another view check out Joel Spolsky on the perils of rewriting code from scratch.