Need Advice about PPL Usage

[CoastalMaineBird]

If your problem is "how do I find plugins not included in my EXE as a plugin architecture".  By relative path is the only simple method.  If the plugin architecture uses VIs, or classes, or PPL, you will always need to enumerate the plugins not included in the EXE.  The easiest way is to enumerate a folder of files and say each one is a plugin.

There are two use cases here.

1... The addons themselves -I let the user find them.  There is an ADDONS folder, and the user can have any organization of folders he wants inside that.  He builds the PPL and puts it into whatever folder is appropriate.  I track them all down and put them into a menu,  When he chooses one, I have the path to it, and so can dynamically open the PPL and execute VIs from it.

That works fine now.  They can even move the addon around and change folders - the next time they pop up the menu, it's in the new path and they can select it again. Nothing breaks.

2... Using the "Managers" or FGVs.  If  I have an FGV that I want the host to use and any addons to share, then it has to be in a PPL.  THAT's where my difficulty comes in.  How does an addon find the FGV?  Where does it actually exist?  My test shows that the PPL file doesn't even have to exist - I can throw it away and the addon will do the right thing anyway.  Can I bet on that?  Even if the addon moves into a different folder?  I'm trying to test that now, to find out the rules.  Just wondering if anyone knows a reference to the rules already.

[Hooovahh]

Name space wise there is only ever one FGV in memory at once.  So lets say you built an EXE and in it is a "System Status VIG.vi".  You then build your EXE and it works fine.

Then you build an add on, and in your source you call the "System Status VIG.vi" to get the status of some system.  Then you build a PPL.  That PPL needs to include a copy of the "System Status VIG.vi" or else the code is broken.

Now if your EXE tries to load the PPL from disk, as soon as the reference is opened it will look for all the dependencies and load those.  It will see that "System Status VIG.vi" is already in memory from the copy in the EXE and it will use that assuming the name space is the same.  If when you built your PPL you didn't do anything like put "System Status VIG.vi" into a library, or cause it to be renamed that is.

Your "System Status VIG.vi" will exist in two places, in the EXE and in the PPL, and there is the potential that the two don't have the same code in them.  But if your two versions are the same exact code, then it doesn't really matter who is loaded first, just that the same one is used everywhere, and it will be because another copy can't exist in memory at the same time.

Note that this all assumes the same application instance, and same run-time version.

[CoastalMaineBird]

It needs to be external to your application so that your plugins can also reference it

OK, I see a little bit more now.

When I build the ADDON, it placed a COPY of the shared PPL next to the ADDON.  

When I build the host EXE, it ALSO places a copy in the SUPPORT folder.

If I delete ALL copies, then things break.

If any of those exist, then I cannot rebuild the shared PPL.

[CoastalMaineBird]

Name space wise there is only ever one FGV in memory at once.

--- Well, in the DevSys, I can have an FGV from an LLB and the same FGV from the PPL and they coexist, but are separate.  The name is "Some Library.lvlibp:MyFGV.vi" on one of them though.

So lets say you built an EXE and in it is a "System Status VIG.vi".  You then build your EXE and it works fine.

--- OK, I did exactly that.  I eliminated all traces of the shared lvlib and lvlibp I've been working with.  The host calls something called the "Data Object" in my code (it's not an object, as in OOP classes, just a FGV, with READ and WRITE functions).  I went back to calling the version in the LLB code.

Then you build an add on, and in your source you call the "System Status VIG.vi" to get the status of some system.  

--- I changed the addon to call this same Data Object vi, from the LLB.

Then you build a PPL.  That PPL needs to include a copy of the "System Status VIG.vi" or else the code is broken.

--- OK, I built the addon PPL.  I don't know what it contains.  I specified the DESCRIPTOR vi and the WORK vi that I will use.  It now calls this DATA OBJECT vi, but I didn't specify that in the LVLIB.

--- If I pull it (the PPL) into the project, the only things in it are those two items.

Now if your EXE tries to load the PPL from disk, as soon as the reference is opened it will look for all the dependencies and load those.  It will see that "System Status VIG.vi" is already in memory from the copy in the EXE and it will use that assuming the name space is the same.

--- That doesn't seem to be the case.  It does NOT use the one from the EXE.

 If when you built your PPL you didn't do anything like put "System Status VIG.vi" into a library, or cause it to be renamed that is.

--- I didn't do that.

Your "System Status VIG.vi" will exist in two places, in the EXE and in the PPL, and there is the potential that the two don't have the same code in them.  

--- Understood. If I change that VI, then I need to rebuild BOTH pieces that use it.  Fine.

But if your two versions are the same exact code, then it doesn't really matter who is loaded first, just that the same one is used everywhere, and it will be because another copy can't exist in memory at the same time.

--- OK, In theory, I understand you.  In practice, not so much. 

If I understand you correctly, you're saying that I do NOT need to put the shared FGV into a library.  If I just call it from a PPL, it will use the one that's already in memory, rather than the one carried in the PPL.  But that doesn't seem to be what's happening.

--- The PPL has its own namespace, which is why, if you open a VI from a PPL, the window title bar will show "Some PPL.lvlibp: Some VI.vi".  You can have the two versions open at once, even.

It acts as if the FGV that I'm sharing is COPIED into the PPL, given PRIVATE status (not visible from the outside) and given it's own name ("Some PPL.lvlibp: Some VI.vi").  It is thus independent from the host's copy.

Note that this all assumes the same application instance, and same run-time version.

--- Understood. Not applicable to my situation.

[Hooovahh]

Wall of text so sorry if I missed something.

---

@CoastalMaineBird wrote:

 If when you built your PPL you didn't do anything like put "System Status VIG.vi" into a library, or cause it to be renamed that is.

--- I didn't do that.

---

You are controdicting yourself.  Here you say you didn't put it in a library, but earlier you said this:

---

Name space wise there is only ever one FGV in memory at once.

--- Well, in the DevSys, I can have an FGV from an LLB and the same FGV from the PPL and they coexist, but are separate.  The name is "Some Library.lvlibp:MyFGV.vi" on one of them though.

---

If the name has a library given infront, then it was included into a library, giving it a different name, and now they can be loaded at the same time.  

If I get some time I'll try to demo this concept.

[CoastalMaineBird]

You are controdicting yourself.  Here you say you didn't put it in a library, but earlier you said this:

I meant when I reworked it to follow your example, I didn't put it into a library.

[CoastalMaineBird]

If I get some time I'll try to demo this concept.

I don't need a demo of that concept;  I get that inclusion in a library changes a VI's name.

But I thought you were suggesting I didn't need a library.

[Hooovahh]

---

@CoastalMaineBird wrote:

But I thought you were suggesting I didn't need a library.

---

That's what I was suggesting, but when I went to make a demo of this I had other issues, so I confused myself.

[CoastalMaineBird]

OK, I have boiled this down to a simple case.   Attached is a PROJECT with these pieces:

--- an FGV.  It simply has a WRITE switch and a VALUE input and a VALUE output.

--- an ADDON.  This one simply calles the FGV and reports the value received.

--- a HOST.  This one writes a value to the FGV on demand, and then loads and runs the ADDON on demand.

This host therefore has to connect to the FGV directly, and to the ADDON directly with the FGV indirectly.

You should be able to WRITE a value via one button, then RUN the addon with the other button to retrieve the value.

THINGS I FOUND OUT:

1... You MUST build the FGV *-BEFORE-* you build the ADDON.  That makes sense, as the ADDON calls the FGV in the PPL, and fails if it doesn't exist.

2... Because of #1, the BUILD ALL will FAIL unless the build specs are in the correct order.  They are, in this project.

3... Don't open the HOST VI before you BUILD ALL.  the missing PPL will confuse it.

4...If things get gorched up, delete ALL the PPLs, close ALL VIs, and then BUILD ALL again.

5... When you BUILD the ADDON, LV places a COPY of the FGV PPL alongside the ADDON PPL.  I don't know why or how, it just does.  The Build Spec doesn't specifically ask for that.

6... If you put the ADDON PPL into a folder called FOLDER (leaving the FGV PPL where it is) and change the path in the host to point to ADDON\FOLDER, then it still works.

7... If you put the ADDON PPL into a folder called FOLDER (and move the FGV PPL in with it) and change the path in the host to point to ADDON\FOLDER, then it still works.

8... If you put the ADDON PPL into a folder called FOLDER (deleting the FGV PPL altogether) and change the path in the host to point to ADDON\FOLDER, then it still works.  IT DOESN'T NEED THE FILE THAT IT INSISTS ON PUTTING THERE.

9... If you delete BOTH the FGV PPLs: the one in \Addon and the one in \PPL, then IT DOESN"T CARE. ( As long as you do that after things are loaded).

10... If you delete BOTH of them and then close the HOST vi, then the next time you open it, it's unhappy. You have to close the host, BUILD ALL, and then open the host again.

[CoastalMaineBird]

It looks like your original thought has the right idea:

Now if your EXE tries to load the PPL from disk, as soon as the reference is opened it will look for all the dependencies and load those.  It will see that "System Status VIG.vi" is already in memory from the copy in the EXE and it will use that assuming the name space is the same.  If when you built your PPL you didn't do anything like put "System Status VIG.vi" into a library, or cause it to be renamed that is.

--- If you use a LIBRARY, then it appears to work exactly like you said.  The LIBRARY (PPL) is included in the EXE.  If the host EXE uses something out of there, it refers to the namespaced version (EXE\MyPPL\MyFGV.vi).  When the ADDON is loaded it needs a VI called MyPPL\MyFGV.vi and it finds it already loaded within the EXE.

But it doesn't work that way UNLESS you put the VI into a lbrary and use it from there in ALL cases.  

That's why you can throw away the PPL file with no harm - the EXE has one inside itself, and since it loads first, it wins.

But you can't load the host SOURCE code without the FGV PPL in place (already built) or else things are broken.