Dynamic Dispatch VI not in memory when built into PPL

[ImreSzebelledi]

Hello Everyone,

 

i have stumbled upon a problem which i need help from someone more experienced in this field: Labview gives me the following error when trying execute the Attribute.List.Get dynamic dispatch vi when I build the containing class into a PPL and try to execute it. The class must be in the memory because I have already inserted a few instance of it into the map collection which the for loop iterates through (as seen on the picture). The problem is resolved if I cast the object back to its parent object and try to execute its method that way. Can someone explain this behaviour to me? Thank you!

 

[Neil Pate]

The error probably goes away in your last scenario as dropping the class constant onto the block diagram causes the LabVIEW compiler to automatically include that class in the build. This kind of thing happens all the time with factory pattern type stuff in LabVIEW, where everything works perfectly in the IDE because all the classes are in memory. 

If that is the problem you can solve it in a number of ways, one of the easiest I have found is to make a dummy VI that you can then include in the build or place somewhere on your top level VI, in this VI just drop down all the class constants of the classes you are using. The kinda breaks the lazy loading paradigm, but you win some you lose some.  

Just as a side note, I avoid PPLs like the plague as I just cannot see a good use case for them for "normal" applications. The sheer number of problems that arise with PPLs have caused me to put them in the same category as Shared Variables; nice in principle but never to actually be relied upon... 

[ImreSzebelledi]

12 hours ago, Neil Pate said:

The error probably goes away in your last scenario as dropping the class constant onto the block diagram causes the LabVIEW compiler to automatically include that class in the build. This kind of thing happens all the time with factory pattern type stuff in LabVIEW, where everything works perfectly in the IDE because all the classes are in memory. 

If that is the problem you can solve it in a number of ways, one of the easiest I have found is to make a dummy VI that you can then include in the build or place somewhere on your top level VI, in this VI just drop down all the class constants of the classes you are using. The kinda breaks the lazy loading paradigm, but you win some you lose some.  

Just as a side note, I avoid PPLs like the plague as I just cannot see a good use case for them for "normal" applications. The sheer number of problems that arise with PPLs have caused me to put them in the same category as Shared Variables; nice in principle but never to actually be relied upon... 

Thank you for the answer! I thought the same and placed the class constant on the same block diagram but it didn't solve the problem. The other problem is that this dependant class (TreeNode.lvclass) is already built into the PPL so it shouldn't be a problem. The top level VI also contains a constant of this class so it should already be in the memory. This vi (Attribute.List.Get) is a Dynamic dispatch method of the TreeNode class and at this point there is no one to override it so the Class which travels on the Wire of the Parent class is the parent class itself (TreeNode.lvclass)

On side note: PPLs have a few pain in the neck features but we need some easily distributable package format and at this point there is no nice alternative!

[Neil Pate]

Sorry, I know way too little about the subtleties of PPLs!

The only other thing I can think of is making sure the class is being loaded from the right place on disk. From your screenshot you have a bit of the path in the first dialogue can you try figure out the whole path and then pass it to the Get Default Class VI (or something like that, I am not at my PC).