I just exported code & did a git diff. It showed a Private Sub NewMethod() (which, apparently there's a hot-key for in RD, that I've never used before, but accidentally triggered).
I went back to my Access project, deleted the method definition, then did an OASIS export, and it shows zero changed modules.
erm, no, actually. I didn't realize that until I went to close Access and it prompted me to save. I'm usually pretty fastidious about save early save often. But I've had a lot of distraction this morning and musta missed it.
@this Yeah, I usually do that. As noted, was rather distracted today. (Mom's been here visiting. Just left a bit ago, but all the chaos of her packing, son getting up to run her to the airport, wife coming home to say goodbye, etc - chaos...)
OK, fine. Maybe it wasn't OASIS' fault, but, while it works well (possibly better than anything else? don't know haven't tried much beyond default export & RD export), it's still immensely frustrating. Coupled with my lack of git skillz is... just...
"It was him! Drive by fruiting!" Oh, wait, that was Mrs. Doubtfire my bad...
not sure I saw Mr. Mom
Wait, OASIS only exports code that was actually saved, not the code currently in the code pane?
That might just explain some of the confusion I've had...
Lol. Michael Keaton and Sally Fields, I think. There was an episode where kids made a mess, there's plumber here, there's bug man here, and a fireman (?) and the dad just snaps due to the chaos.
Yeah...just kinda taking a poll. I do...but it comes with some downsides. I elected to store them because I just end up managing copies of those files somewhere else..but that comes with some downsides as well.
Just did an experiment where I imported everything from my repo into an empty workbook. It succeeded except that some References are not restored - just couldn't compile immediately. Thought I had tried that before with no success(?)... I may have to rethink my git workflow - my biggest concern was recovering from a corrupted xlsm.
well yeah, that'd be one of them. Another example would be hidden sheet that enumerates lookup values for use somewhere as a formula, and of course the formula defintions themselves
don't forget the pivottable, pivotchart, and tables, of course.
In an ideal world, those would be controlled because they don't actually contain the data but shapes the data in one way or other.
thinking about it some more, this kind of argues for having a VBA module that is responsible for building those objects.
then you can source-control that code and you'd then get the worksheets in the same shape (but not necessarily with data, of course)
In theory, someone could write an extension that could then generate the source code for those objects and thus build the VBA module to be then SCC'd. That way, you don't have to write the code which will be some bajillion lines of code
But the thing is that the extension will never be "complete" since you'd have to know how to enumerate every types of objects and its properties
In Access it's easier because almost all objects implements the properties collection so you can easily generalize For Each Property In Whatever.Properties and write it out which makes generating text representation much easier.
You can't exactly For Each over actual members of a object.
To do that, I guess you need the typeinfo access.
which is not as simple, either but much more generalizable.
VBA Rubberducking
VBA Rubberducking