Improve source file detail for MSForms 2.0 exports

[joyfullservice]

I have reached a point in one of my projects where we are needing to incorporate a traditional VBA form (Microsoft Forms 2.0) in the application to overcome some limitations with native Microsoft Access forms. (VBA forms provide the ability to create dynamic controls at runtime and don't have the height limitation of Access forms.)

From a version control standpoint this surfaces an issue with the export of traditional VBA forms. While the VBA code is contained in the .frm header file, the majority of the layout and design information is buried in the companion binary .frx file. On top of that, the .frx file changes on every export, so it is quite difficult to track the actual design changes taking place on the form.

For my purposes, I really only want to see a human-readable rendition of the design elements and properties on my form. I am happy to use the binary file as the primary source file for export and building, but a serialized rendition of the design would be helpful to maintain in version control for the purpose of tracking changes to this form.

Thankfully, someone else out there has faced the same issue, and fleshed out the code to serialize the design of a VBA form. A huge thanks goes to @gkuenzli for piloting this approach on the vbaDeveloper project. I agree with his assessment and conclusion that the companion JSON file approach sufficiently meets the need of tracking changes in VBE forms. (Especially in Microsoft Access where they are seldom used.)

[joyfullservice]

One of the more significant changes I made to the original code was to refactor a bunch of independent functions to a single abstract property reader function that uses CallByName and a list of property names to get the values of the control properties. I feel that this simplifies the readability and maintainability of the code since each property name is only listed once. I do realize that there is a performance hit when going from early binding to late binding with CallByName, but in my testing, this only added 1 second to a loop of 1.4 million property accesses. (var = o.Name vs. var = CallByName(o, "Name", VbGet)) In real life, I don't think performance is going to be an issue, especially in a Microsoft Access application.

[joyfullservice]

I am satisfied with how this is working in my project for now. We can always build this out more in the future.