Open reference to a dynamic dispatch VI

[Vladimir Drzik]

For application based on LVOOP and using asynchronous modules, it is often needed to open reference to a dynamic dispatch VI to be run asynchronously. For Open VI Reference (OVR) node, you have to supply a path to the VI you are opening. Is there any way how to get the path of the correct override VI?

I can think of some workarounds. However, all of them require altering the classes in question (adding some helper member VIs). I am seeking a solution, which can leave the original classes intact.

[Yair]

If I understand what you want correctly, you can do this:

Wire the class wire into the Get LV Class Path VI. This should return the path of the specific class on the wire.

Use that path to open a ref to the VI (it should already know it's a part of the class) or append the DD VI name to the class if it's already in memory (remember that you need to use the format A.lvclass:myVI.vi to get a fully qualified name) and use that to open the reference and run the VI.

I don't remember ever running DD VIs using the Run VI method, but I believe this should work.

[Vladimir Drzik]

Wire the class wire into the Get LV Class Path VI. This should return the path of the specific class on the wire.

Use that path to open a ref to the VI (it should already know it's a part of the class) or append the DD VI name to the class if it's already in memory (remember that you need to use the format A.lvclass:myVI.vi to get a fully qualified name) and use that to open the reference and run the VI.

Yes I was thinking about using Get LV Class Path. However, I can't find a reliable way to use the class path to get the path of the overriden DD VI. Appending the string ":myVI.vi" is unfortunately not reliable, because the VI might not be implemented in the child class itself, but in one of its ancestors.

I don't remember ever running DD VIs using the Run VI method, but I believe this should work.

It works indeed. The only trick is to get to the overriden VI's path .

[Yair]

Without changing the code, you will probably have to reimplement some of the stuff the DD does yourself. If the class has an exposed property which links to its parent (and it probably does have it somewhere), then you can iterate over the override VIs from the bottom class to the top one. You will get an error for each VI which doesn't exist. Of course, this doesn't cover the Call Parent Method issue (the override VIs don't have to use it).

[Vladimir Drzik]

If the class has an exposed property which links to its parent (and it probably does have it somewhere), then you can iterate over the override VIs from the bottom class to the top one.

I'm not sure if this is possible in the run-time environment. I tried experimenting with opening a reference to the LVClass, but skipped my effort immediately because it's unsupported in run-time engine.

[Aristos Queue]

Write a static dispatch VI -- it does NOT have to be a member of the class, assuming the dyn disp VI you're trying to invoke is public -- that has the same conpane as the dynamic dispatch VI except that the terminals aren't dynamic. Have the static dispatch VI call the dynamic and then use OpenVIRef to open ref to the static dispatch VI.

[Vladimir Drzik]

Write a static dispatch VI -- it does NOT have to be a member of the class, assuming the dyn disp VI you're trying to invoke is public -- that has the same conpane as the dynamic dispatch VI except that the terminals aren't dynamic. Have the static dispatch VI call the dynamic and then use OpenVIRef to open ref to the static dispatch VI.

Actually, I am currently using this method. However, I also need to get the reference to the newly run DD VI, because I need to insert its FP into a subpanel. In my current workaround, I have to send the reference of the DD VI from itself back to the calling module through a queue. Which is not nice and requires modification of the existing code. That's why I was searching for a simpler solution.

[Shaun Hayward]

Actually, I am currently using this method. However, I also need to get the reference to the newly run DD VI, because I need to insert its FP into a subpanel. In my current workaround, I have to send the reference of the DD VI from itself back to the calling module through a queue. Which is not nice and requires modification of the existing code. That's why I was searching for a simpler solution.

For inserting an object's UI into a subpanel, I have used the reverse approach successfully - I have a DD VI that accepts a reference to a subpanel called something like "Insert UI", then its up to the individual class to decide what VI gets inserted and give the opportunity for the class to do any housekeeping before actually displaying its UI to a user. Here's a pic:

[Aristos Queue]

For inserting an object's UI into a subpanel, I have used the reverse approach successfully - I have a DD VI that accepts a reference to a subpanel called something like "Insert UI", then its up to the individual class to decide what VI gets inserted and give the opportunity for the class to do any housekeeping before actually displaying its UI to a user.

Excellent strategy. This isn't formally documented as a pattern but probably should be.

[crelf]

For inserting an object's UI into a subpanel, I have used the reverse approach successfully...

Oo - I like that - that's nice.

[Shaun Hayward]

Excellent strategy. This isn't formally documented as a pattern but probably should be.

Oo - I like that - that's nice.

Thank you!

It works really well in a little internal project I have on the go, where the host application has many "modules" of which some have a user interface and some don't (or where a particular module launches an external app instead of displaying in the subpanel). For example, if a module wanted to launch Notepad.exe as it's "user interface" instead of displaying a VI in the subpanel, that child's "display UI" VI, would use the subpanel ref to clear the subpanel and then use System Exec to launch notepad, all the while the OO-ness of the interface nicely decouples the host application from the module's user interface. Obviously this has limits and checking to make it smooth and robust, such as the parent class having functionality to ensure that if a child wants to display in the subpanel then it should be of an appropriate size for the subpanel etc, but it seems to be promising.

[zack13532]

Sorry for reviving a dead topic, but I need to do something very similar in my application and I wanted to ask a few quick questions to clarify how to implement the various suggestions in this thread.

 

Write a static dispatch VI -- it does NOT have to be a member of the class, assuming the dyn disp VI you're trying to invoke is public -- that has the same conpane as the dynamic dispatch VI except that the terminals aren't dynamic. Have the static dispatch VI call the dynamic and then use OpenVIRef to open ref to the static dispatch VI.

My application doesn't need to do anything funky with front panels, and probably won't need to collect any results from the VIs called besides error statuses. Would this static dispatch VI basically just implement polymorphism manually? I would still have to create some sort of case structure (perhaps not, though, because all my child classes will probably have overridden the VI in question) and/or a sequence that would rely on working with the paths of the VIs, correct? 

 

I'm just trying to figure out the best way to go about this. Also, there will be a few rendezvous in the VIs, but I'm hoping that won't mess anything up.

 

Thanks for any help!

[drjdpowell]

I would still have to create some sort of case structure (perhaps not, though, because all my child classes will probably have overridden the VI in question) and/or a sequence that would rely on working with the paths of the VIs, correct? 

No.  The static VI just calls the dynamic VI, passing in the class instance and so allowing dynamic dispatch.  Below is the static VI I use:

[zack13532]

Oh of course!
 

Thanks for your help!