Dynamic Dispatch VI icon - a nagging doubt for a OOP beginner

[PaulOfElora]

Me again blundering thru learning LVOOP.  I have a class structure with 4 levels, and today I'm working with one particular child at the bottom of a hierarchy.  Maybe I had the wrong impression, but I thought that when I connect an object of the child's class to the input (DynoDispatch) input terminal, the icon should change to reflect my icon for that child. But it consistently shows the icon of its grandparent.  The weird thing is - it works as it should, that is, this child at the bottom of the hierarchy is the only one I've put any real code in, and it's working as it should.  None of its ancestors contains any code.  Being so new to this, I'm 97.038% sure that I'm hosing it up somehow.  Are my expectations incorrect?  Thanks, paul

[tst]

Working with text can be confusing, so it's hard to say what's going on in your case.

When you connect a class wire of type X to a DD VI, the VI shown on the diagram is the one closest up to class X (the one from X, if X has it).

Since you say the code does call the VI from the lowest class (let's call it D), I would guess it's one of two things:

1. The wire type is not D, but one of the classes above it. That still allows it to carry D at run time. You can easily check that by hovering over it with the context help window open.
2. You manually created a copy of the override to include in class D, and that override still has the icon of class B. I'm assuming that's not your case, because I understand from your description that you can see the icon.

[PaulOfElora]

Thank you tst, will check these things this morning.  OOP still very blurry & squishy for me! paul

[crossrulz]

---

@PaulOfElora wrote:

Maybe I had the wrong impression, but I thought that when I connect an object of the child's class to the input (DynoDispatch) input terminal, the icon should change to reflect my icon for that child. But it consistently shows the icon of its grandparent.

---

Yep, I think you had the wrong impression.  It sounds like you purposely put down a VI form the grandparent.  So it will accept any object that inherits from the grandparent.  The OO VIs do not act like Polymorphic VIs, which can change to show the icon of the actual VI being called.

[PaulOfElora]

I think I've narrowed it down.  I've attached the whole barge-load project, but also a little snippet that illustrates the phenomenon.  I bundle my class objects to carry around, and in the cluster there are objects that represent "Stepper Motion Controllers".  So this is a "HAL-ish" situation where, 5 years from now somebody might need to replace controller hardware with different makes/models, but it's not a dynamic HAL - a new stepper controller or IO controller (and their associated child classes) will have to be written and added and "plugged in".  I have no idea today what specific methods might look like for those future potential replacements.  The new motion controller might not be a stepper at all, but a servo.  Some assembly required.

So I guess I'm beginning to see that the cluster has to contain the most generic Motion Controller class object to accommodate any possible motion controller child class.  So, if I'm going to use this cluster to carry objects around, there's no way to bundle a specific child class object into it and expect to see that lowest level child's icon on a block diagram.  Am I thinking straight? Thanks, and EVERYBODY STAY HEALTHY! paul

[PaulOfElora]

Ahh, that explains it, crossrulz.  All still very blurry for me - will just need to practice practice practice.  But the quarantining will be ending soon, I'll have to go back in to work, and then LET THE DISTRACTIONS BEGIN! paul

[paul_cardinale]

When I want to drop a method on a block diagram, I always use the attached .xnode.  The dropdown list shows all available methods, with separator lines between generations.  I have it on my "Cluster, Class, & Variant" palette.

Note that this is a zero-risk xnode because when you choose a method from the list, it replaces the instance of the xnode so there is no trace of the xnode remaining in your code.

[PaulOfElora]

Holy cow, thanks Paul!  I'll try it out.  A whole New Thing for me to learn about, that's good! paul

[paul_cardinale]

---

@PaulOfElora wrote:

Holy cow, thanks Paul!  I'll try it out.  A whole New Thing for me to learn about, that's good! paul

---

Use considerable caution if you decide to develop your own xnodes.  They are very challenging and fraught with many pitfalls.  You can inadvertantly create giant headaches.

[PaulOfElora]

Hah! I haven't even dipped a pinky toe into scripting yet - just the name "xnode" sends shivers down me spine! But I'll use your kung-fu, very useful - Thank you Paul!