"Get LV Class Default Value.vi" equivalent in 8.5

[Jim Kring]

Is there an equivalent to "<LabVIEW 8.5>\vi.lib\utility\LVClass\Get LV Class Default Value.vi" in 8.2?

I tried down-saving this VI from 8.5 to 8.2 and it complains that the function doesn't exist in the shared library (LabVIEW.exe).

I have tried using the "LVClass.Open" function, in conjunction with the LVClassLibrary.DefaultInstance() method, but the "LVClass.Open" function fails (error 53: Manager call not supported) in a built executable (dispite the fact that the help docs claim that this method works in the run-time engine).

Thanks,

[Tomi Maila]

QUOTE(Jim Kring @ Aug 23 2007, 01:19 AM)

Is there an equivalent to "<LabVIEW 8.5>\vi.lib\utility\LVClass\Get LV Class Default Value.vi" in 8.2?

Not to my knowledge, no. What's your use case, there may be a work around.

[MikaelH]

QUOTE(Jim Kring @ Aug 23 2007, 08:19 AM)

Is there an equivalent to "<LabVIEW 8.5>\vi.lib\utility\LVClass\Get LV Class Default Value.vi" in 8.2?

I tried down-saving this VI from 8.5 to 8.2 and it complains that the function doesn't exist in the shared library (LabVIEW.exe).

I have tried using the "LVClass.Open" function, in conjunction with the LVClassLibrary.DefaultInstance() method, but the "LVClass.Open" function fails (error 53: Manager call not supported) in a built executable (dispite the fact that the help docs claim that this method works in the run-time engine).

Thanks,

What I thought was that the new 8.5 VI "Get LV Class Default Value.vi" is just the 2 VIs you mentioned wired together.

I use it like that in 821, but haven't tried it in an executable.

BTW I like the new "Get LV Class Path.vi" found in 8.5 in the same folder :thumbup:

//Mikael

[Aristos Queue]

The Get Default Value VI is new in 8.5. In 8.2, there was a property on an LVClass Library reference that would get you the default value. This was depricated because it does not work in the runtime engine. The subVI in 8.5 will work in the runtime engine.

QUOTE(Jim Kring @ Aug 22 2007, 05:19 PM)

function fails (error 53: Manager call not supported) in a built executable (dispite the fact that the help docs claim that this method works in the run-time engine).

The documentation says that all LVLibrary properties and methods do not work in the run time engine. Perhaps a specific method or property got mislabeled, but the top level docs are pretty clear on this point. There was some misinformation posted to LAVA by me early in the 8.2 release because I thought that the properties/methods were available in the run time engine. That lack of functionality lead my team to develop the 8.5 subVI.

[Jim Kring]

QUOTE(Tomi Maila @ Aug 22 2007, 03:33 PM)

Not to my knowledge, no. What's your use case, there may be a work around.

I am dynamically loading plug-ins (child classes of a base class). I was using the .lvclass path as the "path to the plug-in". I then obtain the plug-in object (typed as a generic LabVIEW object, using the aforementioned technique) and then call To More Specific Class to convert it to my base class.

[Jim Kring]

OK, now I've hit another brick wall...

"Get LV Class Default Value.vi" can't open lvclass within LLB in built EXE

The work-around is to distribute each of my plug-ins as two separate files (my_plugin.llb + my_plugin.lvclass)

[Aristos Queue]

Jim:

Query... once the VI is loaded into memory, thereby loading the class, can you give a path to the Get Default Instance.vi that is just the class' name and have it work successfully? I can't look at the code right now, but my memory of how it is implemented suggests this might work.

-- Stephen

[Tomi Maila]

Jim, I've used class plugins myself since the times of LV 8.20. The way I do it is that for each plugin, I create a single VI that simply returns the class constant. Then simply dynamically open a reference to this VI. If you use certain naming convention for the VIs (as I do), you can search directory structure for these VIs and open plugins as needed. It's very simple way and doesn't require any special features of LabVIEW 8.5

[Jim Kring]

QUOTE(Aristos Queue @ Aug 23 2007, 08:32 PM)

Jim:

Query... once the VI is loaded into memory, thereby loading the class, can you give a path to the Get Default Instance.vi that is just the class' name and have it work successfully? I can't look at the code right now, but my memory of how it is implemented suggests this might work.

-- Stephen

I just tried (in LabVIEW 8.5) to use Open VI Reference to open a reference to a VI that is contained inside an LLB and that doesn't work in built apps, either!!!

Am I going crazy?

[Tomi Maila]

QUOTE(Jim Kring @ Aug 24 2007, 09:09 PM)

Am I going crazy?

Sure

[Aristos Queue]

QUOTE(Jim Kring @ Aug 24 2007, 01:09 PM)

I just tried (in LabVIEW 8.5) to use Open VI Reference to open a reference to a VI that is contained inside an LLB and that doesn't work in built apps, either!!!

Am I going crazy?

Ok, Jim. Let's take a deep breath and start from the top. First, is the computer plugged in?

Seriously... the Open VI Reference from LLB is used on every single test of the nightly autotest suite. It works. Not sure what's wrong with your code, but that definitely works.

[Jim Kring]

QUOTE(Aristos Queue @ Aug 24 2007, 01:28 PM)

Ok, Jim. Let's take a deep breath and start from the top. First, is the computer plugged in?

Seriously... the Open VI Reference from LLB is used on every single test of the nightly autotest suite. It works. Not sure what's wrong with your code, but that definitely works.

> Ok, Jim. Let's take a deep breath and start from the top. First, is the computer plugged in?

Actually, you're supposed to ask the customer to unplug the computer and blow the dust out of the connector because sometimes that causes problems

OK... "Open VI Reference" is working now... whew... I was just going crazy Actually, I think that I was attempting to open a VI that was saved in 8.2 from an app built in 8.5 (oops )

I created a simple project (Bug.zip) to test three things at run time:

1) "Open VI Reference" for VIs inside LLBs (works)

2) "Get LVClass Default Value.vi" for VIs inside LLBs (fails)

3) "Get LVClass Default Value.vi" for VIs inside LLBs after using "Open VI Reference" to open a class member and bring the class into memory (fails). Note: I've tried passing both the absolute path to the .lvclass and a relative path of only the lvclass name -- both fail.

Thanks,

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

QUOTE(Tomi Maila @ Aug 24 2007, 01:06 AM)

Jim, I've used class plugins myself since the times of

LV

8.20. The way I do it is that for each plugin, I create a single VI that simply returns the class constant. Then simply dynamically open a reference to this VI. If you use certain naming convention for the VIs (as I do), you can search directory structure for these VIs and open plugins as needed. It's very simple way and doesn't require any special features of LabVIEW 8.5

Ya, I was thinking about this. I wasn't a big fan because its yet another VI/convention that I have to add to my plugin template.

[Jim Kring]

QUOTE(Jim Kring @ Aug 24 2007, 02:12 PM)

QUOTE(Tomi Maila @ Aug 24 2007, 01:06 AM)

Jim, I've used class plugins myself since the times of

LV

8.20. The way I do it is that for each plugin, I create a single VI that simply returns the class constant. Then simply dynamically open a reference to this VI. If you use certain naming convention for the VIs (as I do), you can search directory structure for these VIs and open plugins as needed. It's very simple way and doesn't require any special features of LabVIEW 8.5

Ya, I was thinking about this. I wasn't a big fan because its yet another VI/convention that I have to add to my plugin template.

I just realized that the problem with this (a single VI that simply returns the class constant) is that the VI that returns the class constant must be a static method otherwise it cannot be called using a Call By Reference node. The means that if you plan on having multiple levels of plugin inheritance, you have to make sure that each subclass uniquely names the "GetClassConstant" method (e.g., GetClassConstant_Motor.vi and GetClassConstant_StepperMotor.vi, if StepperMotor is a child of Motor) since static methods cannot have the same name in two classes that are part of the same inheritance hierarchy.

[Aristos Queue]

QUOTE(Jim Kring @ Sep 11 2007, 04:42 PM)

Ya, I was thinking about this. I wasn't a big fan because its yet another VI/convention that I have to add to my plugin template.

I just realized that the problem with this (a single VI that simply returns the class constant) is that the VI that returns the class constant must be a static method otherwise it cannot be called using a http://wiki.lavag.org/index.php?title=Call' By Reference" style="background: url(http://wiki.lavag.org/skins/monobook/external.png) center right no-repeat; padding-right: 13px; border-bottom: 1px dotted #3366BB; color: #3366BB; cursor:pointer; text-decoration:none;" class="wiki">Call By Reference node. The means that if you plan on having multiple levels of plugin inheritance, you have to make sure that each subclass uniquely names the "GetClassConstant" method (e.g., GetClassConstant_Motor.vi and GetClassConstant_StepperMotor.vi, if StepperMotor is a child of Motor) since static methods cannot have the same name in two classes that are part of the same inheritance hierarchy.

Or it means that the intermediate levels of your inheritance hiearchy should not have such a method; then the VIs can be named the same on all the leaf classes. This is actually good practice since it means that your intermediate classes are just API classes, not actually functionality, which is something I'm recommending more and more as time goes by. It solves an awful lot of programming bugs if the class levels that are not leaf level are not actually instantiated in your application. (There's a conversation somewhere in LAVA and/or DevZone about why LV doesn't have formal "abstract classes", but I can't find the link to it at the moment. If anyone knows where it is, please link it here.)

[Jim Kring]

QUOTE(Aristos Queue @ Sep 11 2007, 02:50 PM)

Or it means that the intermediate levels of your inheritance hiearchy should not have such a method; then the VIs can be named the same on all the leaf classes. This is actually good practice since it means that your intermediate classes are just API classes, not actually functionality, which is something I'm recommending more and more as time goes by. It solves an awful lot of programming bugs if the class levels that are not leaf level are not actually instantiated in your application. (There's a conversation somewhere in LAVA and/or DevZone about why LV doesn't have formal "abstract classes", but I can't find the link to it at the moment. If anyone knows where it is, please link it here.)

That's a great point and is very applicable to what I am doing. I think that I'll try to go this route.

Thanks,

-Jim

[jaegen]

QUOTE(Aristos Queue @ Sep 11 2007, 02:50 PM)

Or it means that the intermediate levels of your inheritance hiearchy should not have such a method; then the VIs can be named the same on all the leaf classes. This is actually good practice since it means that your intermediate classes are just API classes, not actually functionality, which is something I'm recommending more and more as time goes by. It solves an awful lot of programming bugs if the class levels that are not leaf level are not actually instantiated in your application. (There's a conversation somewhere in LAVA and/or DevZone about why LV doesn't have formal "abstract classes", but I can't find the link to it at the moment. If anyone knows where it is, please link it here.)

Is this why your http://forums.lavag.org/Map-implemented-with-classes-for-85-t8914.html' target="_blank">Map example had an "Empty Node" class, which did nothing? I still haven't figured this one out.

Jaegen

[Aristos Queue]

QUOTE(jaegen @ Sep 11 2007, 05:27 PM)

Is this why your http://forums.lavag.org/Map-implemented-with-classes-for-85-t8914.html' target="_blank">Map example had an "Empty Node" class, which did nothing? I still haven't figured this one out.

Yes. It leaves room for future expansion of functionality that differs between leaf nodes and branch nodes.