Error 1448 - To more specific Class Issues

[DailyDose]

Hello (Admins - please remove my other post due to "Duplicate")

My Parent class in lvlibp will not type cast to child class despite the source versions working without issue... take a look below.  Is there something unique that needs to be done with building into Packed Libraries?

[DailyDose]

---

@DailyDose wrote:

Is there something unique that needs to be done with building into Packed Libraries?

---

I figured it out - well... via internet searching and someone mentioning it on a much older thread...  If using Packed Libraries/PPLs, the Source Child Class must inherit from the PPL Parent class (the built Packed Library).  It cannot inherit from the Source Parent class.  So there you go.  You're welcome future person who stumbles across this exact issue.

[tyk007]

A packed library has a different namespace than the original library - and classes are identified through namespaces.

[wiebe@CARYA]

If you don't include the parent in the PPL, you should be able to cast to the parent:

But it seems you have to give the parent it's own PPL or library...

[DailyDose]

---

wiebe@CARYA wrote:

If you don't include the parent in the PPL, you should be able to cast to the parent:

But it seems you have to give the parent it's own PPL or library...

---

I exclude the dependent packed libraries.  But now I'm wondering if maybe the better way to approach this is that source code applications use source Parent classes and not packed library Parents.  I guess the issue becomes how does one plan to use the Parent Classes.

[wiebe@CARYA]

---

@DailyDose wrote:

---

wiebe@CARYA wrote:

If you don't include the parent in the PPL, you should be able to cast to the parent:

But it seems you have to give the parent it's own PPL or library...

---

I exclude the dependent packed libraries.  But now I'm wondering if maybe the better way to approach this is that source code applications use source Parent classes and not packed library Parents.  I guess the issue becomes how does one plan to use the Parent Classes.

---

Yes, I think that's how I would do it.

I'm not sure what you mean with "how does one plan to use the Parent Classes.".

You usually have all users of the class use the parent, so the caller of your code can decide which child object is used. So the parent functions as an interface specification. The (empty, abstract) parent has all methods, each child implements the methods. The users of the class hierarchy call the methods, not knowing (or caring) which child object is actually called.

If each child heavily extends the parent with methods, you'd need another layer. There's simply no way to implement these methods if they only exist in the PPL (well, maybe dynamically if you'd really want to).. You'd have a parent A with all the common stuff, a child B defining the extension methods, and a child C in your ppl implementing the B methods.

[rolfk]

---

@DailyDose wrote:

---

---

I exclude the dependent packed libraries.  But now I'm wondering if maybe the better way to approach this is that source code applications use source Parent classes and not packed library Parents.  I guess the issue becomes how does one plan to use the Parent Classes.

---

That's not that a great idea if you want to build the child into a PPL and have other children of the same parent too. You do not want to let each child pull its own parent into the PPL as that makes them in fact all independen parent classes that are not "related" to each other anymore (other than their parent if it is in a separate PPL, or otherwise the generic LabVIEW object class).