Automagically Run Dynamic Dispatch VIs

[Norbert_B]

Steve,

i think you refer to the fact that P1 displays 0 as Object data after execution. That is expected behavior.

You call after the decrement an increment by calling "who_am_i.vi" of Base.......

Norbert

EDIT: Also note that what you are doing has nothing to do with dynamic dispatching. Also, the m* VIs do not require dynamic dispatch in/output connectors.

EDIT 2: You can directly cast the variant to Base.lvclass. No obscure cast to LVObject and To More Specific necessary!

[Norbert_B]

I think you really have to understand what "dynamic dispatch" means in context of LVOOP:

The base class defines a basic function (VI) which can be overriden by child classes. In the calling code, the developer only uses VIs from the base class without caring about the *possible* child classes which will be included and called during execution.

During execution, the LV runtime evaluates the class of the object and, if present, calls the override of that specific child class. If no override is present, it will execute the base method of the parent.

EDIT: This is done per "static" call to parent class VIs configured for dynamic dispatch. This is NOT done for static dispatch VIs!

I *assume* what you are looking for:

The P1 class should also execute the m2 and m3, but from Base as P1 doesn't implement those.

The point is that the dynamic dispatching replaces dynamic vi calls for the developer and the other way round. So no "standard" call in LV => no dynamic dispatching.

That means that your main.vi would call all four m-VIs from the Base. In case of selection of P1, m1 and m4 would dispatch dynamically, m2 and m3 call into Base implementation.

Norbert

[Pie566942.0]

Your assumption is spot on.  I apologize if my careless use of terms caused confusion.  I attached a revision of the same project that shows the difference between what I have that works, and what I'm trying to implement that doesn't work.  So, is there a way in LabVIEW to load a list of base class methods from disk and dynamically dispatch plugin methods where they exist?  Hopefully that's worded correctly, or close enough.

Thanks,

Steve K

[tst]

---

@Pie566942.0 wrote:

Scripting...My fears are I'll either reach a similar result, or that I'll spend a lot of time joining class data from scripted objects with the object already loaded in my application.  Or both.

---

I'm not sure what you're afraid of here. The idea behind this is that you write code which will duplicate your working code and then run it. Since I'm guessing there's no way to do what you actually want, this seems like a reasonable option. I expect that if you were to base it on your existing code, it would basically require duplicating the frame N times (once for each m* VI), setting the value of each frame, then replacing the subVI with the correct VI. Seems easy enough, although I haven't verified that all the methods exist.

This still only answers the technical question of how to (sort of) do what you're asking, not whether it's the right thing to do or if there are better options.

[Norbert_B · Accepted solution]

---

@tst wrote:

[...]not whether it's the right thing to do or if there are better options.

---

I am not sure if there is a "right thing to do" at all in this context in LV.

Though i think that your suggestion is the closest to what makes sense.....and does the job.

As i said, LV has to call explicitly into VIs for dynamic dispatching. So the dynamic dispatch approach requires a caller for each method. Dynamic dispatching does not work if you call VIs by reference (as you encountered).

However, you could write your own dispatcher to check for present override VIs and "missing" ones. In case it is "missing", you reference to the parental version and in case it is present the child version. You still have the advantage of the "generic dynamic dispatching" in case you need it and of course: Call parent method and all other advantages why you'd might have chosen LVOOP.

In order to prevent misunderstandings:

Though that custom dispatcher might reflect your need of "dynamic dispatching" as you called it, from a LVOOP point of view, that should have another term. I recommed something like "custom dispatching".

Norbert

[Intaris]

I've been following this thread with interest.

Have I understood properly:

You have a base class with 300 Methods, M1 to M300.  You want to be able to pass in a string to launch the respective method.

You don't want to have static links to each method on the BD of the VI doing the selection.

You want to be able to override any of these given methods in a child class but retain the selection by string method and have them also call the parent implementation.

?

To which extent do you really need dynamic dispatch because it sounds like you want to do your own version of that.

[Norbert_B]

I still don't understand the purpose of this "feature", however, attached you can find a prototype. It should work similar to what you are looking for.

Norbert

[Intaris]

What I also don't get is why try to solve this "problem" with LVOOP if you're actively ignoring the methods LVOOP gives you to do this (Command pattern or placing the methods directly on the BD).

I think if you want to ignore the cornerstones of what LVOOP gives you to do this, you're going to have to LVOOP yourself and ditch classes for this part.

[Pie566942.0]

Good morning interested and helpful people, I hope you had a nice weekend.

To reply to earlier questions on this thread:

• In my specific case, M1 through M300 have no inputs and return a single reference output.  Our framework needs these references, i.e. the method VIs return something.
• I don't want to have static links to each method on the BD, but only because there are a lot of them.
• That's exactly what I'm doing with the irksome sequential state machine, and it works as expected.
• I do want the cornerstones of LVOOP.  I'm simply trying to avoid placing lots of base methods on the BD.
• I do want to be able to override any method in a child class.
• I don't want to also call the parent implementation.  If, for some reason I did, then I'd "Call Parent Method" in the override.
  • I do want to call the parent implementation if a child implementation doesn't exist.
  • Again, I do want the cornerstones of LVOOP.
• I do want the ability for future projects to redefine the behavior of M<xyz>, where M<xyz> has already been defined in the base class.

Thanks for this code Norbert.  I understand your objections to my approach.  In fairness, the "custom dispatching" thingy requires four hours of demo involving three architectures to understand.  I was trying to ask a general question about my very specific use-case.  I appreciate your patience.

The best design for me is to crawl up the VI class hierarchy, run parent methods where child methods don't exist, and do this recursively based on a standard file name prefix.  I would not have to impose anything more than I already have (i.e. only a standard file name prefix), and it allows an arbitrarily deep LV class hierarchy.  I'll might leverage this: Get LabVIEW Class Hierarchy at Run-Time.  I can see my solution flowing out of this class list quite naturally.  Here's a related thread with an idea that doesn't work for my specific case, but it's interesting nonetheless: Open reference to a dynamic dispatch VI.

With appreciation,

Steve K