Dynamically calling child classes

[Brant at VIE]

I am hoping all of the collective knowledge of LVOOP here can help me out. I'm having an issue with dynamically calling external child classes from an executable. The parent classes is currently build in the exe. When saving those child classes with all dependencies, the parent class is also saved in the hierarchy. I think I know why, but a some discussion on why this occurs would be helpful. The real problem is that when running the executable the child classes see the path of its parent has changed (i.e. in the executable) and is broken.

Is a possible fix to make the parent class dynamic as well? Wondering if anyone has tried this before, I go down this route. I also wouldn't like to as the parent should never change, unlike the child classes, but that may be more of an academic argument at this time.

Any ideas would be helpful. Thanks!

[Aristos Queue]

I am hoping all of the collective knowledge of LVOOP here can help me out. I'm having an issue with dynamically calling external child classes from an executable. The parent classes is currently build in the exe. When saving those child classes with all dependencies, the parent class is also saved in the hierarchy. I think I know why, but a some discussion on why this occurs would be helpful. The real problem is that when running the executable the child classes see the path of its parent has changed (i.e. in the executable) and is broken.

Are you *sure* that the break is merely because the *path* to the parent has changed? The RTE generally doesn't care about that. Usually it requires that the substance of the dependency have changed to cause a break. Just a guess, but I suspect that the version numbers are being changed. That's what this *feels* like. It would help if you posted the exact text of the error you're seeing.

(closing eyes, imagining setup... all of the following is speculative)

Let's see... you have a parent class that is built into an EXE and a child class that is going to be dynamically loaded into that EXE but which is not built as part of the EXE.

1. The child is actually produced through its own Source Distribution build (I presume that's what you mean by "when saving child classes with all dependencies"). A copy of the parent class ends up sitting next to the child because the child depends upon the parent class. See #4 for further thoughts about this copy.
2. The EXE runs and tries to dynamically load the child. I assume you've worked out the path issues to successfully point to a file not inside the EXE (otherwise you wouldn't be getting the kind of error that you describe).
3. The child was saved thinking its parent is at path XYZ. When it loads into the EXE, it finds that its parent is at path PDQ. That should be fine... as long as the parent classes are identical.
4. Tangent: In fact, after the source distribution is built for the child, you should be able to safely delete the unneeded copy of the parent class. You only need that laying around if you are going to be loading the child someplace where the parent doesn't already exist. Now, back to the loading problem...
5. The load should work if the two parents are identical. What could cause the two parent classes to not be identical? Well... how about if you built the EXE with "strip typedefs" but when you built the source distribution you did not "strip typedefs"? If the parent class had a typedef inside of it, it would now have different type (and thus a different version number). Hm... no, that shouldn't be the problem, because the parent in memory would have a future version number and a future version number should be fine... of course, that's assuming I've written the C++ code for loading in a run-time engine correctly, so this is worth checking.
6. Ah, but if we reverse the equation, then there's a problem: If you did NOT strip typedefs when building the EXE but you DID strip typedefs when building the source distribution. Then the child class would be saved pointing to a parent whose version number had been bumped forward but the parent class in memory in the EXE would not be bumped, so the child class would complain about being unable to load with an old parent (because there is no way to unflatten data to older versions of the class, only newer ones). Ok, so this is worth testing: are the source distribution and the EXE both being built with the same "strip typedefs" settings?
7. Assuming that isn't the problem, look through your EXE build specification for anything else that could cause a change to the parent class. Note, this isn't a change to the parent class' member VIs... for the version bump break, we're only looking for things that could change the .lvclass file itself (which includes the private data control, thus the typedef possibility).
8. Having said that... does your parent class include any polymorphic VIs? Those get stripped by default when you build an EXE and are not stripped by default when you build a source distribution. I do not know enough about poly VI behaviors -- I pretty much never use that feature of LV -- so the following might be completely off base, but suppose that some member VI of the child class used the poly VI from the parent class. The parent in the EXE no longer has such a subVI. Does the polyVI node from the child's member VI cause the child's VI to break when the poly VI is missing? Or is LV smart enough in the RTE to ignore all references to polyVIs since those don't exist? I don't know. Perhaps someone on the forums knows?
9. I can't think of anything else...

That's all I can come up with from the data provided. Try the strip typedefs idea. If that doesn't work, post more details of the problem and maybe I'll think of something else.