LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Jon_Kokott

LVClass By Reference Features

Status: Declined

Any idea that has received less than 3 kudos within 3 years after posting will be automatically declined.

Property nodes for LVClasses are a tease, this is what I really want:

 

Invoke nodes that correctly wire call dynamic dispatch by value VIs (this includes the ugly wireing of the "preserve runtime class" inside the in place element structure.  Its ugly, just obfuscate it for me.

 

References to Data value references that correctly respond can use the "to more generic" and "to more specific" class so that I have the DVR to the more specific.generic class REFERENCE.

 

Justification for Invoke nodes:

I work with lots of different Classes, and libraries.  I can quick drop alot, but I do not know all the publicly exposed functions in a give class especially since 90% of the time it is still in development.  Generally a pallete won't see the light of day in internal development (somewhat of a pain to make/maintain, definately not a single click operation), so getting the correct methods involves paging back and forth between the project explorer, this is slow.  I want to code quickly, if I can have the Public api exposed by an invoke node it means I dont' ever have to make a pallete of VIs (we can argue over this all you want, it just isn't simple/fast enough)  and I can access the functions much more easily/quickly.  Even if every class had a pallete, it would still be inferior to the invoke node solution because A.) I have to remember where every pallete is. B.) Sharing/installing pallete changes for other developers is PAINFUL.  I want to give them a zip file that they can chuck anywhere.  I sure do not want to make a scripting function to update there palletes, so it requires file moving/installation/making sure they actually put the class in the right folder (which someone will always do wrong and invariable cause me to right arrow enter 1000 times when I receive their project.)

 

 

------------------------------------
Jon Kokott
CLA, CLED, CTD, MCP C#
5 Comments
AristosQueue (NI)
NI Employee (retired)

DVRs of class types already work with To More Specific and To More Generic.

 

I'll leave the other parts of this idea to discussion by the community.

AristosQueue (NI)
NI Employee (retired)

A chunk of your idea -- the part about by value functions accepting reference types -- is duplicated by this idea:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Have-Dynamic-Dispatching-terminals-accept-Data-Value-r...

 

Jon_Kokott
Member

I do want the same thing, I simply want it to be in an invoke node.

 

It does marked advantages over a simple by reference Dynamic dispatch, in that labview can enforce the following rules at edit time:

 

1.) the method includes error handling terminals.

2.) the method can strictly not execute in the event that the reference is not valid.

3.) Required that the same object leave as was originally wired.

 

the invoke node will force a specific reference type of implementation (which I beleive is the most common.)   I think this will solve a number of issues that were brought up regarding a direct by reference dynamic dispatch call.

------------------------------------
Jon Kokott
CLA, CLED, CTD, MCP C#
Jon_Kokott
Member

Regarding the to more specific/generic class of DVRs, I'll try it out again.  Last time I tried (lv2010 no sp1) I had some "difficulties."  this may have been because of CAR 255982 and I incorrectly attributed it to the to more specific/generic casting not working correctly.

------------------------------------
Jon Kokott
CLA, CLED, CTD, MCP C#
Darren
Proven Zealot
Status changed to: Declined

Any idea that has received less than 3 kudos within 3 years after posting will be automatically declined.