Class Conflict On Object Wires

[Mark_Ramsdale]

Hi,

The parent would just have a shell, an empty method, all the children would over ride it.  You put the parent VI in the code, and at run time the VI called will match the Object passed ( from the array).

So the child VI's ( all same named) would exist in the project, but the code would use the parent vi ( same name).

Using that technique, dynamic dispatch,  you don't have to cast.  

Not sure if this is the issue, but on the surface it seems like the VI can't handle all the object types passed into it.

[MGould]

I don't want to scare people off, I really want to understand what my fundamental mis understanding is.  Do I need to rearchitect my code, what is the general solution to the problem where I have two places I need to use an object that implements inheritance?

[Mark_Ramsdale]

Hi,

Not scared    I recommend taking a look at the example in the example finder that uses inheritance and dynamic dispatching.  That explains a lot. 

Not sure your architecture needs changing, maybe the object/inheritance needs a tweak. 

[tst]

I don't want to start commenting about the architecture (I suggest you look up some existing material first and then start a new thread if you have additional questions), but I can explain the DVR error.

The IPE structure requires that the object you put back into the DVR be exactly the same object you took out. You can change the value of the object, but it has to be the same object. To do this, you need to use the Preserve Run-Time Class primitive and cast back to the object coming out of the DVR:

[MGould]

Thanks Tst, that is a helpful piece of information about the perserve runtime class.

As for your architectural comment, I have looked into other Labview OOP white papers (https://decibel.ni.com/content/docs/DOC-2875), but didn't find anything about reference based design patterns.  NI app engineers have told us (the other engineers I work with and myself), the same thing: "Your doing it wrong".  When I ask them to show me how to do it right, all I get are the equivililent of blank stares.  If some one can point me to the information that addresses my architecture then I would be forever in your debt.

This gets into another problem in that there is no 3rd party books on modern labview development... but that can be saved for a later thread 🙂

[tst]

People discuss architectures in general, not necessarily ref-based patterns. Specifically, you can start by looking through the LAVA forums and the large apps group - https://decibel.ni.com/content/groups/large-labview-application-development

[nathand]

---

@MGould wrote:

However, I was under the impression that by overriding, I can make my children have more and more specific functions while retaining the common data between them.  What good is it if I have to include over rideable functions in my parent that are specific to my children?  I might as well just make seperate classes that don't share data.

---

Maybe you've misunderstood how overriding and inheritance works.  This is somewhat repeating what others have already said here, but let me see if I can explain in more detail.

In your inheritance hierarchy, you have a common parent of "V Test."  The output of the build array is an array of "V Test" since that is the common ancestor, and when you index an element out of that array you get a "V Test" object.  You cannot call a method that is specific to only one one child class - such as the "Read Centroid" function that's part of BRSIGHT - on a "V Test" object.

If you know that you will only ever call Read Centroid on the first array element, then you can do a type conversion as you've already found.  Of course, that type conversion will fail if you try to convert a sibling, such as NOISE, to BRSIGHT- you'll get an error and a BRSIGHT object containing default values.

Let's say you do want to be able to call Read Centroid on any "V Test" object.  In that case, you would need to include that function in the parent, and then override it in the children.  That would also solve the error you're getting, because it would make the Read Centroid method valid for any V Test object including children.

Alternatively, you'll need to include some logic to ensure that when you index an object out of that array, that you are only calling methods appropriate for that object.  A cluster might be a more appropriate structure than an array if you choose this approach.

I hope that helps, and if it doesn't make sense yet, please reply, ideally with a more detailed explanation of which part is not clear.