Dynamic Dynamic Dispatch

[DowNow_]

Inheritance newbie question. I built a class for a TCP-based motion instrument. Some commands to the instr. are context-dependent. For example, depending on the variation of the UUT being tested, there are five different commands that implement "move-to-next-position." So I could have a parent move-to-next VI, and then override it depending on the UUT. But I already have a live TCP session on the class wire, how do I change the wire to a child? I'll need to change UUTs, and thus the wire, over and over.

Can I typecast the wire? Or should I have a different, has-a, class for the context-dependent commands? I could reconnect the TCP session and change the class using class constants at the start of each UUT 😞

Many thanks!

[Kevin_Price]

On the diagram, you should place parent functions and connect them with parent-type class wires.  Any child UUT you instantiate gets to travel along these wires at run-time (based on the "child IS A parent" notion of inheritance, which sounds odd when I type it out explicitly) and dynamic dispatch will know to use a child override function when it exists.

So in short, you don't change or cast the wire on the diagram at programming time.  The diagram is all about parent-looking wires.  Run time is all about child-functioning objects doing their own thing along these wires by means of dynamic dispatch.

-Kevin P

[Jacobson-ni · Accepted solution]

I probably wouldn't make child classes of the TCP motion instrument for what you want to do. I think doing so would unnecessarily couple the TCP motion instruments to the UUT. Without knowing too much about your application I would investigate having a UUT class which uses a TCP motion instrument to perform it's measurements.

[crossrulz]

---

@DowNow_ wrote:

But I already have a live TCP session on the class wire, how do I change the wire to a child? I'll need to change UUTs, and thus the wire, over and over.

---

The only thing that should have to change is the initialization.  If you initialize the child class, nothing else needs to change.  Now loading the correct class is the hard part.  Look to the Load LV Class Default Value.vi in order to load up the class you need to.  From there, I use To More Specific Class to change the generic LabVIEW Class into the parent class that you actually care about. Dynamic Dispatch will take care of the rest.

[AYanez]

I think if the communication is handled by normal TCP and not with a specific instrument driver, probably the suggestion of Matt would be the best, a composition of UUT Class and a TCP instrument class, I understood that only the payload of the frame changes so of this way you can adapt the command inside a Move-to-next method with dynamic dispatch and reuse the communication API.

[DowNow_]

I'm going with this solution, also mentioned by SYanez below

[DowNow_]

I'm sorry, I don't know how to use the forum. I selected the solution by Jacobson and AYanez. Thanks.

---

@DowNow_ wrote:

I'm going with this solution, also mentioned by SYanez below

---

[RavensFan]

You can select multiple solutions if more than one message applies.

Just click the Accept as Solution on syanez's post also.