Issue in calling a class and VI dynamically from exe

[AristosQueue (NI)]

---

P@Anand wrote:

 I was under the impression that the child class wouldn't be able to link to a class which is inside EXE, please correct me if I am wrong.

---

That is false.

A child class will be saved pointing to the source directory -- it is true that you cannot save it in such a way that it saves a path that leads inside the EXE. But, when the child class is loaded by the EXE, if the parent class is already in memory as part of the EXE then the child class will use the version already in memory.

Where people run into problems is when they make a parent class a part of the EXE file but never actually use the parent class anywhere in their application. The parent is sitting inside the EXE file on disk but isn't in memory. If the EXE then loads the child class, the child will use the path it was saved with -- and load the version back in the source directory, or search if not found (if you've enabled searching on the Get LV Class Default Value.vi flags). Search never searches inside the EXE (for security reasons).

[Ajay_MV]

Hey Anish,

That's a great finding.  Thanks for bringing the out of box thought here.  I added a new child class to base class (without rebuilding the EXE) and the exe launched new Child2 class perfectly. 

I never expected "Separate compiled source" will cause that issue.  Do you know why we need to un-check separate compiled code in order for this to work?

Also, do you have any idea on PPL way of doing the plug-in architecture?  The issue I posted earlier?

[தமிழ்நேரம்]

LabVIEW 20xx(any version) is having the build in compiler in it. it converts the block diagram in to code that runs for the current OS.

Application build out of LabVIEW only contains runtime engine but not complier or editor to edit any VIs.

Previous to Lv2011:

Whenever a VI is saved  to hard disk, it saves Front panel, block diagram, icon/connector pane and complied code into single file (.VI). So when a VI is called from a application(build out of LabVIEW), it uses the complied code (inside the VI) to run the VI.

After LabVIEW 2011:

                      Saving the complied code into the same VI became optional by VI setting. if you enable this feature there are lot of benefits like VI size is small, unnecessary checkout and check in of toplevel VI is avoid in Source code control if the subVI is edited. But the side effect is observed when Calling a VI in Runtime engine, dynamically. The Application will look for complied code and if it is not available, then it will fail to run the VI.

[தமிழ்நேரம்]

if you are using PPL there is one more challenge, while building the application. The namespace of a PPL is different from namespace of the Library in source code. So the application has to be build in the reverse order. i.e. lowermost library needs to be converted into PPL and the Callers need to be relinked to the PPL and then build the caller PPL and so on.

[தமிழ்நேரம்]

Hi Ajay,

         I was looking at your code. The following things you need to make in order to make it work with executables.

1) split the base class library from the child class library. build a PPL for the base class and use that in the toplevel VI.

2) create child class library containing all the plugins inherited from the PPL as shown in the below diagram.

[தமிழ்நேரம்]

Hi Ajay,

           Please find the attached modified PPL files

[parthabe]

---

@தமிழ்நேரம் wrote:

After LabVIEW 2011:

                      But the side effect is observed when Calling a VI in Runtime engine, dynamically. The Application will look for complied code and if it is not available, then it will fail to run the VI.

---

Thanks Anish! That answers my doubt reg how come this setting in the context of SCC is affecting the application.

However, I still have a question. When I load a DynVI (which contains a VI from the vi.lib inside it) dynamically, should I take apply this setting to the DynVI, or should I apply this setting to the vi.lib VI?!

[parthabe]

On probing further, I see this setting (Separate compiled code from source file) is left unchecked by default for any VI we create, but I do not understand why this has been checked for the vi.lib VIs.

Anybody (esp from NI R&D) got any idea?!

[தமிழ்நேரம்]

Hi Ajay,

             Let us understand the root cause of the issue that is observed in the demo application you have provided.

we all know that "LabVIEW (or application built out of LabVIEW) can not load two VIs with same name".

The same concept is true for Libraries. i.e. "LabVIEW (or application built out of LabVIEW) can not load two Libraries with same name". In the below explanation i am discussing the issue without creating PPL and Class.  As the root cause is nothing to do with PPL or Class.

In the example provided initially the plugin library contains members (A,B,C) Animals.vi,Birds.VI,Cats.VI and Application(executable) is created containing of Animal.VI. which makes the library definition(A,B,C) to be included inside the executable. Later the Library definition is modified to contain one more Vi. Now the new Library contains members (A,B,C,D,E). ie. Animals.vi, Birds.Vi,Cats.VI, Dogs.VI and Elephants.VI.

Now if the executable is trying to load the VI D or E from the Disk. which will try to load the library plugins. Since the library is already in memory with definition (A,B,C). library will not be loaded and the D vi will say i am part of plugins library as per the definition but the library will not claim that D is not a member of the library. so the VI D (or E) loaded with broken arrow.

So in my solution all i did was to create two different library. one containing all the VIs that are used inside the executable and another library containing all the VIs that are added (or going to be modified) after the executable is created.

[guna11]

Hi Anish,

              The solution provided by you works fine for the API's inside "NI_AALBase.lvlib" alone. In the same demo application i replaced the mean(DBL).vi in the child1 class with linear fit.vi ( this is inside NI_AALPro.lvlib) and I unchecked the Separate compiled code from source file option for the same and also for its dependent API's. Now when i tried to call the child1 class from the exe it is giving error 1498.  

               I unchecked the "separate compiled code from source file option" in all the API's inside "C:\Program Files (x86)\National Instruments\LabVIEW 2017\vi.lib\Analysis & C:\Program Files (x86)\National Instruments\LabVIEW 2017\vi.lib\gmath" folder and created the exe, then copied those files next to the exe. Even then the issue continues.

               I have attached the modified code with this. Can you please check this one.