modDatabase.RunSubInCurrentProject / modAPI.RunInAddIn: avoid rename VBProject

[josef-poetzl]

The VBProject is currently being renamed so that Application.Run uses the correct procedure.
Alternatively, you could use the full path without file extension.
Application.Run "c:\....\Version Control." & ProcedureName

This variant has the advantage that it also works with a compiled add-in.
Is there a particular reason why this variant is not used?

Example code (changes):
josef-poetzl@4bf9f99

[joyfullservice]

The main reason is that I was not aware of this approach using the full path of the add-in file. 😁 I do like this much better! If you want to put together a pull request, I can merge that in.

[josef-poetzl]

Done. :)

Note:

Public Function RunInAddIn(strProcedure As String, blnUseTimer As Boolean, Optional varArg1 As Variant, Optional varArg2 As Variant)

    Dim projAddIn As VBProject
    Dim strRunCmd As String

    ' Make sure the add-in is loaded.
    If Not AddinLoaded Then LoadVCSAddIn

In principle, you could also do without LoadVCSAddIn if you always use the full path.
I created the pull request without this customization so that only the renaming is omitted.

[joyfullservice]

Thank you, @josef-poetzl!! This also solves a long-standing issue with trying to load the add-in for ADP projects. I was relying on another hack to launch the add-in, but this hack only worked in regular Access databases, not ADP projects. This breakthrough will finally allow developers to utilize the ribbon interface within ADP projects! 🚀

[josef-poetzl]

Note: I use this technique to move the calls to Access add-ins to a ribbon.
see: https://github.com/AccessCodeLib/ACLibAddInStarter
Side effect: the add-ins do not have to be registered as menu add-ins.