Auto-save should run any time the compiler is invoked

[comintern]

I lost track of how many times I've done something bone-headed and either crashed the host application or put it into an irrecoverable not responding state and had to end-task it. One of the more overlooked features of Visual Studio is that it saves all of your open documents when you build a project. It would be nice to be able to recover from one's own stupid decision to run something before the host document is saved.

[retailcoder]

Any ideas on how to capture that "build" event?

[comintern]

This would definitely go in the "experimental" category at this point - I need to poke around to see if I can find a suitable COM event. That would go far beyond lucky though.

If not, it would probably be substantially more work. My current thought from that angle would be to put a trampoline function on the entry points of the compiler that calls back to RD and delays compilation until RD says it's OK.

This is tangentially related to my pondering about replacing the code pane - it would very likely need to respond to a compilation event also.

[Hosch250]

I like this. Visual Studio and NetBeans (the two IDE's I've used) save all changed files when the solution is built, so this is definitely a standard feature for modern IDE's.

[ThunderFrame]

I think we need to be conscious of event driven code. As VBA can run in response to a selection change in a worksheet, you may end up with a compilation event and save event when you don't expect it. And the workbook might even have a save event wired up, so saving the workbook would itself trigger code.

I suspect that most VBA developers are conditioned to the explicit save requirements, and that Office document recovery is fairly robust. But many will have called an API function badly and made Excel go Boom, and lamented the lack of AutoSave.

If we implement this feature, then I think we need to:

1. Make it obvious in the IDE that the feature is ON.
2. Have an option to always show a warning that AutoSave is ON, when opening the VBE.
3. Have a "Cautious" option that does perform AutoSaves, but prompts the user for confirmation before actually saving.

[ThunderFrame]

Also, what to do when a save will prompt for the name of a new unsaved module/form/report in Access?

I.e. Even when you create a new module in Access' IDE, the Module isn't yet an Access Module object. You can edit and run code in the new module, but saving your VBA changes will result in an Access dialog about saving the modules as Access objects.

[Hosch250]

@ThunderFrame I don't know for sure, but when Excel is working with an unsaved workbook, it can detect that and not save. Access may need special code to account for this situation, or it may already detect it.

[PeterMTaylor]

Isn't the unsaved workbook all in memory tho? Isn't Visual Studio detecting changes in the memory state, just thinking aloud here when I checked my email this morning. Visual Studio often would have a set of conditions to "force a save state" what that is I don't know, perhaps a period of time has passed or as @retailcoder suggested "capture that build" by the sounds of it an event/trigger had occured.

I recall reading somewhere that there is VBA property called "dirty" to put a name to this scenario which indicates new or exisiting information being changed (such as a workbook or worksheet) is not saved which enable people to do by VBA to make a save.

[retailcoder]

How about we steer this toward source control, and save the project whenever a commit/push is made?

I realize this is a wildly different use-case, but hear me out: modern IDE's don't "save on build" just for the heck of it, or even as a convenience for the dev - yes, it's convenient, but IMO it's merely a side-effect of how the compiler works: it compiles source files, so if source files are "dirty" (i.e. different content in the IDE vs the physical file), compiling without saving changes would build an essentially stale version of the source code, and then confusion ensues - so the IDE first writes all changes to all modified source files, and then launches the compiler.

In VBA the modified modules aren't "source files, they're embedded in a document that may or may not be marked as "dirty" when its VBA code changes (at least, it used to be the case, I remember losing hours of unsaved work several times after inadvertently closing the Excel window and screaming NOOOOO! as the VBE also shut down without saving my changes. Seems newer versions of Office don't do that though. Also worth noting that Office hosts have a built-in "autosave" feature (which of course is utterly annoying and so, disabled).. a timed autosave in the VBE would have the same "drop everything you're doing, I'm saving your 20MB workbook now, over that slow network, because I care for you" effect.... and I'd probably end up disabling it.

Saving when building/running makes sense (especially if the code can hang or crash the host app!), but AFAIK we don't have a hook on that "play" button (or that Debug/Compile menu command).

Now, VBA modules are proper source files when they're exported to a git repository. It would make sense that these files contain the same source code as what's embedded in the host document when these files are created. So how about saving the host document whenever we commit/push/sync?

[Merlin2001]

I second that saving the workbook on every build/compile is not a good idea for the mentioned reasons.

But it would still be great to (incrementally or build-triggered) save some project state to recover from. This could be as little as exporting the currently displayed module to %temp%\RD\.
RD could even check this directory for lingering files on startup and show some (non-modal, I mind you ^^) hint on the existing backups.
Of course, the "full" solution would be to trigger Export All to the temporary folder every time a build happens - but I guess this may take too long.

[Inarion]

Anecdotally there is this "SaveBeforeRun" attribute in the HKCU\Software\Microsoft\VBA\7.1\Common key. Google suggests it is not in any way wired to an actual function within the VBE (and there is certainly no corresponding option), but at least the developers were thinking about adding such a feature. I would totally enjoy an autosave feature - having also lost hours worth of code while quickly testing an idea due to forgetting something like incrementing a counter within a while loop... :)

[daFreeMan]

Interesting find, @Inarion! @retailcoder, could RD hook into the registry key since MS nicely provides it to us? This is, of course, subject to breakage on any Office update...

[ThunderFrame]

@Inarion That looks like a feature from VB6, which does expose a user option, and does persist it to a similar key under the VB6 keys:

SaveBeforeRun key values: Save Changes = "2" Prompt To Save Changes = "1" Don't Save Changes = "0" (default value)

[comintern]

Bumping this. An option to auto-save on reparse would be a lot easier to implement now that we're hooked into this a little better.