Acquiring references to dynamice VIs belonging to a class

[zen]

Hi,

Does anyone know how to acquire the references to the dynamic VIs that belongs to a class? For example, if my class Foo.lvclass has dynamice VIs bar.vi and xyzzy.vi, I want to get the references to those two VIs.

I am trying to implement a unit test library or framework for LabVIEW. My TestCase class should be able to find its own dynamic VIs whose names start with "test" and run them implicitly. If my FooTest class inherited from TestCase class has testA.vi, testB.vi and testC.vi as dynamic VIs, I want FooTest.lvclass::Run.vi to find and run them.

zen

[Tomi Maila]

When you say dynamic VI do you mean 1) a dynamic dispatch VI or 2) a VI that you want to open using open VI reference and call using call by reference node or 3) a dynamic dispatch VI that you would like to call using the method 2.

Tomi

[zen]

QUOTE(Tomi Maila @ Mar 10 2007, 12:15 PM)

When you say dynamic VI do you mean 1) a dynamic dispatch VI or 2) a VI that you want to open using open VI reference and call using call by reference node or 3) a dynamic dispatch VI that you would like to call using the method 2.

I was trying to mean "3" dynamic dispatch VI called by VI reference. I assume that dynamic dispatch VI is the VI bound to a class which was introduced in LabVIEW 8.2.

Note that this is the only way I could think of to call such VIs without user placing them on a block diagram. If there exists another way, I would love to learn it.

zen

[Tomi Maila]

QUOTE(zen @ Mar 10 2007, 03:50 PM)

I was trying to mean "3" dynamic dispatch VI called by VI reference. I assume that dynamic dispatch VI is the VI bound to a class which was introduced in LabVIEW 8.2.

Note that this is the only way I could think of to call such VIs without user placing them on a block diagram. If there exists another way, I would love to learn it.

zen

Still one more question before any answers. Dynamic dispatch VIs are such methods that the actual runtime method is selected based on the runtime type of a class wire you pass to this method. Do you really want to call base class dynamic dispatch method with call by reference node and get child class method actually called when the wire passed to the method is of child runtime type? Or do you want to execute that method that you specify when you open the VI reference.

Tomi

[zen]

QUOTE(Tomi Maila @ Mar 10 2007, 05:23 PM)

Do you really want to call base class dynamic dispatch method with call by reference node and get child class method actually called when the wire passed to the method is of child runtime type? Or do you want to execute that method that you specify when you open the VI reference.

The first one is what I want(ed).

Tomi, your questions made me think this problem better and I am kind of convinced that I cannot do what I want easily. I will describe a use case in block diagram form.

I want to distribute TestCase class and its method VIs (dynamic dipach VIs) at sourceforge.net or here. Users create child classes from TestCase class and define original method VIs. User's project tree will look like the folloing figure. Here, MyTest class is the child class inherited from TestCase class.

http://forums.lavag.org/index.php?act=attach&type=post&id=5170

Then, a user passes MyTest class to Run.vi which is defined in parent TestCase class. I want Run.vi runs Test1.vi and Test2.vi without explicitly user specifying. I want a simple interface/way to run TestSomethingSomething VI to prevent users from wiring a lot. I do not stick to Run.vi if there exists other way but let me continue now.

http://forums.lavag.org/index.php?act=attach&type=post&id=5172

I found that Run.vi should be able to (1) gather references to method VIs defined in child class and (2) call them with passing the child class. I assume Test*.vi's have the same terminal pattern.

http://forums.lavag.org/index.php?act=attach&type=post&id=5171

After thinking on Tomi's questions, rereading his critial analysis report and playing with LabVIEW, I do not think my approach is the best way. Although my original question was how TestCase class's Run.vi to aquires list of method VI references bound in a child method, it seems I should find another way to implment this mechanism (or wait for NI implementing object reference ;p )

zen

[Aristos Queue]

QUOTE(zen @ Mar 10 2007, 05:04 PM)

After thinking on Tomi's questions, rereading his critial analysis report and playing with LabVIEW, I do not think my approach is the best way. Although my original question was how TestCase class's Run.vi to aquires list of method VI references bound in a child method, it seems I should find another way to implment this mechanism (or wait for NI implementing object reference ;p )

Here's where I think you want to go:

a) Remember that .lvclass files have all the functionality of .lvlib files -- classes are just libraries dedicated to the purpose of defining a data type. Given a path to your class, use the VI Server interface to get a list of all the VIs that are members of the class. This will only work inside the LV editor environment (and not the runtime engine), but that's ok for your purposes. Now you can call each of those methods... but...

b) ... a VI with a dynamic dispatch connector pane cannot be passed currently to a Call By Reference method. The wire will break. This is a deliberate choice on R&D's part to make sure that in the future we can correctly support dynamic dynamic dispatch. To dynamic invoke these methods today, create a non-dyanmic (static) VI that calls the dynamic VI on its block diagram. Then invoke the static VI in the Call By Reference node.

c) You can execute dynamic dispatch VIs directly using the VI's Run method. This might be a better choice for you in general since running the Run method would allow you to invoke VIs even if the conpanes are different.

[Yair]

QUOTE(Aristos Queue @ Mar 11 2007, 01:22 AM)

This is a deliberate choice on R&D's part to make sure that in the future we can correctly support dynamic dynamic dispatch.

You gotta love modern LV.

[zen]

Aristos,

Thanks for your comments.

QUOTE(Aristos Queue @ Mar 10 2007, 11:22 PM)

a) Remember that .lvclass files have all the functionality of .lvlib files

Oh, I did not know that. That was a good thing to know. I have not thought of open reference from path to a class, eighter. I think I am more comfortable in working on this. Thanks, Tomi and Aristos.

zen

[Aristos Queue]

QUOTE(yen @ Mar 10 2007, 05:51 PM)

QUOTE(Aristos Queue @ Mar 10 2007, 05:22 PM)

This is a deliberate choice on R&D's part to make sure that in the future we can correctly support dynamic dynamic dispatch.

You gotta love modern

LV

.

Just be glad that we decided to call it "dynamic dispatching." In Java and C++, this behavior is called "virtual," which would have given us "virtual virtual instruments."

In LV, each control has a default value.

Each data type has a default default value.

Which means that a LabVIEW class -- which is a data type whose default value is defined by the default value of a set of controls -- has a default default default value.

Let's suggest that someday we add the ability of a LabVIEW class to set its default value by running a VI at load time -- a feature requested by more than one user. Child classes would be able to override and extend the parent class' default value. You might initialize that value using a CBR to a run-time chosen subVI. That would give us "dynamic dynamic default default" values.

Then, if we add templates to the whole structure, we might end up with a dynamic dynamic dynamic dispatch VI which overrides the default default default default value of the class.

N layers of indirection is never enough. And now you understand why good tech writers are so valuable.

[Jim Kring]

QUOTE(Aristos Queue @ Mar 10 2007, 06:19 PM)

N layers of indirection is never enough. And now you understand why good tech writers are so valuable.

I know a good technical writer with experience in http://forums.lavag.org/index.php?showtopic=4895' target="_blank">the 5th dimension...

[Yair]

QUOTE(Aristos Queue @ Mar 11 2007, 04:19 AM)

That would give us "dynamic dynamic default default" values.

:laugh:

QUOTE

In

LV

, each control has a default value.

Each data type has a default default value.

Not to get nitpicky, but shouldn't that be the other way around (each data type has a default value [e.g. numeric is 0] and each control has a default value [which is 0 by default for numerics])?

Or is this just a matter of semantics?

[Aristos Queue]

QUOTE(yen @ Mar 11 2007, 01:12 PM)

Not to get nitpicky, but shouldn't that be the other way around (each data type has a default value [e.g. numeric is 0] and each control has a default value [which is 0 by default for numerics])?

Or is this just a matter of semantics?

I suppose I should phrase it as "Each control has a default value. For each data type, there is a default default value for controls of that type."

[orko]

QUOTE(Aristos Queue @ Mar 10 2007, 06:19 PM)

we might end up with a dynamic dynamic dynamic dispatch VI which overrides the default default default default value of the class.

Brain spasms resulting from clauses like this are one of the reasons why I try my hardest to stay away from the LVGOOP forum...

"Just when I thought that I was out they pull me back in."

[Aristos Queue]

QUOTE(orko @ Mar 11 2007, 04:12 PM)

Brain spasms resulting from clauses like this are one of the reasons why I try my hardest to stay away from the LVGOOP forum...

Oh, I hope not. This is the absurd part of LVOOP, not necessarily the useful part of it. Weirdness like this exists in many corners of LV or any formal system. The "tongue twisters" I've presented here result from the worst possible presentation of a concept, rather than a clear explanation of of the concept. Just having a bit of fun, not trying to scare anyone off.

[orko]

QUOTE(Aristos Queue @ Mar 11 2007, 03:53 PM)

Just having a bit of fun, not trying to scare anyone off.

Notice that I said I "try" to stay away.

Fortunately, the alure of what LVGOOP could do for me if I could wrap my brain around it is what keeps me coming back for more. Sorry if I sounded a bit "stand-offish" there. I was also just having a little fun by laughing at myself and my inability to simplify compound adjectives. :laugh:

The truth of the matter is that I haven't really had the time to fully explore the GOOP side of things yet. It really isn't taught through the NI courses I've taken so far (Basics,Int,Adv). Although I heard a little rumor that it *may* be considered as an Advanced II topic...

-- Joe "orko" Sines

[Yair]

QUOTE(orko @ Mar 12 2007, 12:12 AM)

"Just when I thought that I was out they pull me back in."

:laugh: :laugh: :laugh: :laugh:

Thank you. I needed a good laugh very much just now. :thumbup:

[Aristos Queue]

QUOTE(orko @ Mar 11 2007, 10:53 PM)

Although I heard a little rumor that it *may* be considered as an Advanced II topic...

REALLY?? (watch me jumping up and down excited)

Where did you hear this? Who do I need to encourage?

[Michael Aivaliotis]

QUOTE(orko @ Mar 11 2007, 09:53 PM)

The truth of the matter is that I haven't really had the time to fully explore the GOOP side of things yet.

How is it possible to program LabVIEW without LVOOP? You like running around with loaded handguns with the safety off?

[Tomi Maila]

QUOTE(Michael_Aivaliotis @ Mar 13 2007, 02:12 AM)

You like running around with loaded handguns with the safety off?

That's what they do in the States, run around with loaded handguns with the safety off. Isn't Texas one of the traditional handgun states? Here in Europe we use LabVOOP