Polymorphic Object??

[MacDroid]

Ok, so I'm missing something. In the above example the class spec'd in the class path is a child, with Init.vi, of Obj_Equipment. But the path between WriteVISA Name and Read VISA Name is apparently not a child.

[MacDroid]

"the final executable has the ability to support more widgets in the future by just adding the new child classes to the application folder"

Yes that is my goal, I want to be able to add metrology without changing the main app, just add a child for the new meter/powersupply, scope, etc.

[elset191]

---

@MacDroid wrote:

Ok, so I'm missing something. In the above example the class spec'd in the class path is a child, with Init.vi, of Obj_Equipment. But the path between WriteVISA Name and Read VISA Name is apparently not a child.

---

The To More Specific is wired with the parent class, so the data on the object wire is of the Parent type, but it's actual type is that of a child.  I'm guessing the Init.vi that is dropped there is the child implementation, and has not been made polymorphic with dynamic dispatch.  (In this case, the parents icon is shown, but will call the child's implementation if it is available.)  

To unbreak the pictured code you could insert another To More Specific with the child class before the Init.vi, or create a parent implementation of Init.vi and make it dynamic dispatch (likely the better option).

[Ben]

---

@MacDroid wrote:

Ok, so I'm missing something. In the above example the class spec'd in the class path is a child, with Init.vi, of Obj_Equipment. But the path between WriteVISA Name and Read VISA Name is apparently not a child.

---

Dynamic dispatch terminals put extra conditions on how they can be wired to maintain "the contract" between the class and the methods (that is heavy OOP jargon saying that if you do something to the object instance it really does something to the instance or something like that).

By branching you class wire you now have two insnaces of that class and the Init acts on one instance and the Read is acting on yet another. I suspect it you wired

More Specific >>> Init >>> Write VISA Name >>> Read VISA name it may fix the error.

Ben

[MacDroid]

Umm...Init.vi is dyn-disp.

There is not Init.vi in the parent. Is that the issue?

If so, does every child need an implementation of each vi I want to have in a child?

[MacDroid]

Nope:

[elset191]

---

@MacDroid wrote:

Umm...Init.vi is dyn-disp.

There is not Init.vi in the parent. Is that the issue?

If so, does every child need an implementation of each vi I want to have in a child?

---

Yes I think Init needs to be in the parent for it to work as it is currently wired.  Alternatively you could use a To More Specific node to turn it into the child class, and it would work as well (I'm guessing with a VI like Init though, you'd be better served adding it to the parent).  

Not every child needs an implementation of every VI.  The parents implementation will be called if it does not exist in the child.

Alternatively, not every ancestor has to have the same VI's as the children.  As mentioned though, if you have an ancestor object wire, and want to run the child VI that does not exist in the ancestor, a To More Specific node is necessary.

[Ben]

You can only call methods VIs that are part of a Class or inherited from the parent.

So yes the parent class need the method.

The children only need the method if the method for the childer is unique from it parent.

I'd guess that the VISA name will be the same so you can just use the Parents method.

Now if you want to make sure each of your classes is complete in itself then you can add over-rides for the children and just let them call the parent flavor.

Ben

[Ben]

Thank you for the help Tim!

I am going to go do something else for now but I'll let you handle this for now.

Send me a personal message if you want me to step in again.

Go Tim!

Ben

[MacDroid]

Init.vi is specific to the child. The parent has no knowledge of it.

If I understand what's happening here, the wire from To Specific is carrying an instance of the parent and knows not about the child object that was specified in the class path. The definition of the child has Init.vi.