RunBeforeExport/RunAfterExport: calling a procedure from an Access add-in

[josef-poetzl]

Allow to start a procedure from an Access add-in with export option Run Sub Before Export.
Example to start automated tests: %appdata%\Microsoft\AddIns\AccUnitLoader.AutomatedTestRun

Possible implementation:
josef-poetzl@7921149

[josef-poetzl]

Note:

Since Application.Run does not forward the error description, I now use this interface:

• Public Function ProcedureNameInAddIn() as String
  => if len(return values) > 0 => show text
  optional with eErrorLevel code like "Error: Error description" or "Warning: warning message to show"
• Public Function ProcedureNameInAddIn() as Boolean
  => if false then Error (eelCritical)

Details:
josef-poetzl@fc902e4

See modification in action:
https://www.youtube.com/watch?v=pGJr5YjuVn4

[josef-poetzl]

New Version (4.1.0): https://github.com/josef-poetzl/msaccess-vcs-addin/releases/tag/v4.1.0-call-add-in-procedure

Are you interested in implementing the functionality of calling an add-in procedure in the original?
Note: The advantage is that you don't have to have cleanup functionality or similar in the main application.

[joyfullservice]

Sorry, I guess I must have missed your original discussion from last year. Yes, I do like the idea of being able to surface a return value in the console/log display.

As food for thought, we could even take this a step further and expose an API in the add-in that would allow the external process to post incremental progress back to the log window and even increment the progress bar. When the external process is complete, it would call the add-in to resume the process, and the add-in would pick back up from there.

Essentially, you would have three ways to utilize a hook.

1. Simply call an external function, like what you have right now.
2. Call a function, but also handle a return value, posting a message in the log window. (Like what you are proposing.)
3. Call a function, and release processing to the function (or add-in) to do it's work, and handle log posts sent back to the add-in. The external process would then be responsible to call a .Resume function in the add-in, signalling that the external processing is complete, and optionally passing a status code or error level.

For something more advanced like unit testing, I could see that third option as providing lots of flexibility for a more integrated build/test experience. If a developer is using a very complex AfterBuild process, it might be nice to see periodic messages posted in the log window as various steps are completed.

[josef-poetzl]

An interface for adding log lines is already available: VCS.AddLog.

[josef-poetzl]

Next step: Run several processes at RunBeforeExport/RunAfterExport
Video (youtube): https://youtu.be/WpU58qZiZsY

Without an add-in call, this feature requires little code customization (see: dev...josef-poetzl:msaccess-vcs-addin:dev-call-multiple-procedures).
But it is only useful with the add-in procedure call.

Note: I separate the procedures with : (VBA syntax)

in TextBox:

as list: