Question : MDB, Library MDA, open a 2nd instance of a Form in MDB from MDA.

Here is the setup - simplified description:

MDB with a Reference set to a Library MDA containing many Functions.

FormA is currently open in MDB (opened from within the MDB).

A menu item in the MDB calls a Function in the MDA and opens FormZ ... which resides IN the *MDA*. FormZ is now open in the Access window, ie the CurrentDB. No problem so far.

** What needs to happen next - and basically the question:

A button click on FormZ (again, which is physically in the MDA) needs to run code ... from within the MDA ... which will open a *2nd instance* of FormA in the MDB.

Keep in mind that the following construct ...

Dim frm As Form
Set frm = Form_FormA
frm.Visible = True

.... etc.,

is not going to directly work because FormA is *not* physically in the MDA.

We somehow need to reference FormA in the CurrentDB (where FormA resides) from within the MDA (CodeDB at the moment) ... and open a 2nd instance of FormA.

Also note that  ...

DoCmd.OpenForm "FormA"

... is not going to work because DoCmd.OpenForm would never open a 2nd instance of a form.

So, the question is ... how do we do this?

Further notes:
1) I can think of one way ... using DoCmd.OpenForm to open a small hidden form in the MDB, which then executes the code in the first construct I mentioned above. But, this is *not* desirable.

2) Both the MDB and MDA are in the same folder, FWIW.

mx

Answer : MDB, Library MDA, open a 2nd instance of a Form in MDB from MDA.

4 cats. (2 dogs... and a partridge in a pear tree)

I'm afraid I've lacked the time to get to this (I did get your email a few days ago MX, just been mad mad busy).
Grabbing a few minutes to put down a thought or two.

The exact issue isn't a resolvable one I feel.
The problem is indeed simply scope. Even with an AddIn loaded - the objects of the running application aren't available - as they're in a different VBA project. AFAIK you can't refer to another project simply with any ProjectName.ObjectName syntax. The object simply isn't accessible.
While you could tempt providence by attempting to alter or create new procedures at runtime - that has far too many limitations for my liking (for example runtime and MDE distributions).

I also feel a second copy of the form is not pretty as solutions go.
Still a workaround - but less of an upheaval - it occurs to me that if you know/create the form name in advance (which you must do when instantiating such an object) then you must have a prepared form in place - so why not a sister prepared procedure.
This procedure would perform the form instantiation on what is a local form object to the running code. (Using the standard code as you've shown in the question).

Calling a procedure in the running application instance is perfectly viable.
Of course since the procedure will need to be in each of the running applications, and the call to it is from the library MDA then, by itself, it would fail to compile and you mustn't let that happen - it'll not be pretty as it loads the MDA proc.
So instead of calling your proc
Call MyFormInstanceSub
just wrapping it with
Application.Run "MyFormInstanceSub"

This will prevent compilation of the named proc - but when called at runtime will execute it in the locally running application.
You'll want to add the necessary error handling in case you're running an application in which you haven't yet created the appropriate procedure - but that's no hardship obviously.

So as a summary - IMO you'll not be able to create a class instance by external reference to another VBA project.
But the procedure workaround shouldn't be much effort.

Must dash.

Cheers.