Property node names

[Tomi Maila]

Hi All,

Happy Holidays! I am back for more. JKI has been keeping me busy. Property Definition folder LabVIEW project item has properties DataName, LongName and ShortName. When you look at LabVIEW class file, the XML contains all three types of names for a property definition folder as well. However LabVIEW IDE does not expose these names to the user, at least not in a way that I can change anything but one common name.

Is there a difference between all these three names? Does LabVIEW differentiate between the names? If not, is this planned for the future?

Cheers,

Tomi

[Yair]

I don't use 2010, but I would have assumed that this would affect the "Name Format" right click option you get with every property node. Are you saying it doesn't do that?

Also, I would guess that data name is something that you would use so that you can localize the name of the property but keep it referring to the same property. Does the documentation not say anything about these?

[Mr Mike]

Property Definition folder LabVIEW project item has properties DataName, LongName and ShortName. When you look at LabVIEW class file, the XML contains all three types of names for a property definition folder as well. However LabVIEW IDE does not expose these names to the user, at least not in a way that I can change anything but one common name.

Is there a difference between all these three names? Does LabVIEW differentiate between the names? If not, is this planned for the future?

Cheers,

Tomi

Believe it or not, there are four names. All are exposed via scripting; three are exposed in the editor. Here's a first second draft of something I typed for a KB:

There are a lot of names associated with LabVIEW Class Properties. There are four actually. You can access them all using an LVClassPropDefFolder reference (which is a ProjectItem reference). There are three that all properties in LabVIEW have -- two you may recognize and one you probably won't.

1. Long Name
   . The long name is what shows in the property selection menu (when you click on an item in the property node). This name is also used to structure that menu. If there is a colon in the long name, you'll get a submenu ("pull-right"). e.g.: If you had two properties with long names "Color:Foreground" and "Color:Background," they would both be in a "Color" menu listed as "Foreground" and "Background." You can show long names in the property node by right clicking on it, and selecting "Name Format » Long Name." The Long Name can be set in the editor by going to the class properties dialog (i.e. right clicking on the class and selecting "Properites"), selecting "Item Settings" and choosing the property you want to edit.
   
   
   Long Name is readable and writable. Long Name will be matched when using the SetProperty method on a PropertyItem reference if you set AllowAlternateNames? to True. The Long Name can be localized without having to change code using the property.
   
   
    
2. Short Name
   . The short name is what shows in the property node by default. This is readable and writable, too. Within NI, we generally make the short name an abbreviated version of the long name, but using periods instead of colons. Other than that it has the same behavior and uses as the Long Name.
   
   
    
3. Data Name
   (Also called UniqueDataName). A (not quite) internal representation of the property name, but useful for scripting. When you use the SetProperty method of scripting, it takes in an IDString. The Data Name is that ID string. The Data Name is unique within the class and is read only. The data name is the names of all the folders in the class leading to that property definition folder separated by colons. e.g. If you have the following class, the data name for the property definition folder "d" will be "a:b:c:d".
   
   

   C.lvclass+-...+-a (Folder)  +-b (Folder)	+-c (Folder)  	+-d (Property Definition Folder)    	+- Read d.vi 

   
   

    
4. Name
   . The Name property actually comes from ProjectItem, the parent type of LVClassPropDefFolder. This is the name that shows on the folder in the project window. When you update this name, it'll update the short name if and only if they're the same and it'll update the long name if and only if they're the same. To ensure that the Data Name is unique, the Name cannot have a colon in it. None of the parent folders of a property definition folder (a, b, and c in the example above) can have colons in their names either.

I hope that sufficiently explains the names associated with a property node. Let me know if you need more information.

[Tomi Maila]

Believe it or not, there are four names. All are exposed via scripting; three are exposed in the editor. Here's a first second draft of something I typed for a KB:

...

I hope that sufficiently explains the names associated with a property node. Let me know if you need more information.

Thanks Mike, that was a comprehensive answer. Now I assume I know how to change those names in scripting and editing lvclass files. But how do you have an access to all those names in the class editor (LabVIEW project)?

Second question is that do the names in an inheritance hierarchy need to be the same or is it enough that the DataName is unique? If there are conflicting definitions for long name and short name, will LabVIEW show an error? I ask this because if I create a class, specify the long and short name for a property, then someone creates a child class for that class and wants to override the property accessors, does he or she need to set the long and short names to be exactly the same or would LabVIEW use those of the parent class that first defined the property?

Third question, how do I localize the long name and short name, not likely I am going to do that but just in case I might?

[Mr Mike]

Thanks Mike, that was a comprehensive answer. Now I assume I know how to change those names in scripting and editing lvclass files. But how do you have an access to all those names in the class editor (LabVIEW project)?

The Long Name can be set in the editor by going to the class properties dialog (i.e. right clicking on the class and selecting "Properites"), selecting "Item Settings" and choosing the property you want to edit. The same for the Short Name.

Second question is that do the names in an inheritance hierarchy need to be the same or is it enough that the DataName is unique? If there are conflicting definitions for long name and short name, will LabVIEW show an error? I ask this because if I create a class, specify the long and short name for a property, then someone creates a child class for that class and wants to override the property accessors, does he or she need to set the long and short names to be exactly the same or would LabVIEW use those of the parent class that first defined the property?

The long name must be the same. This is because the properties in the property selection menu (i.e. the menu you get when you click a property node) are populated based on the long names from the property node's class and all parent classes. If we changed the name in the menu, it would appear you're using a different property. If we didn't change the long name in the menu, then the end user wouldn't get what the developer intended. So, you can't override and specify a different long name.

The same should probably apply for the short name, but it isn't. (That's probably an oversight on our part, but it'd be incredibly hard to change since we've allowed it, we don't want to break existing code.). In any case, the short name of the child (overriding) class is used.

The long name must be unique. You will get an error message if you do it in the editor or an error on the error wire if you do it via scripting. If you do it with a text editor, then when you open the class the VIs in the property definition folders with conflicting long names will be broken with an error message explaining what's wrong.

Third question, how do I localize the long name and short name, not likely I am going to do that but just in case I might?

You need to copy the class file and set the localized names on it (using LabVIEW, a text editor, or scripting), then ship the localized class file with your localized product.

[Tomi Maila]

The long name must be the same.

...

You need to copy the class file and set the localized names on it (using LabVIEW, a text editor, or scripting), then ship the localized class file with your localized product.

Mike, there is a contradiction in what you are saying. You are saying that the long names can be localized, but on the other hand the long names must be the same the whole inheritance hierarchy, i.e. the long name together with the DataName specify the interface of the property to child class developers.

Assume I create a class A. I create a property Length with the following names

DataName = Dimensions:Length

Name = Length

LongName = Dimensions:Length

ShortName = Dim.Length

I publish my class for developers and people in the LabVIEW community create decedent classes of it using these property names. Now I want to localize my class for Finnish market (I am originally from Finland). So I create a localized version of the lvclass file for Finnish market with the following names.

DataName = Dimensions:Length

Name = Length

LongName = Mitat:Pituus

ShortName = Mitat.Pituus

This should be possible, as you told the Long and Short names can be localized. However, now according to the requirement that the Long Names must always be the same throughout the inheritance hierarchy, the descendant classes created by the community no longer are compatible with this localized class.

My interpretation is that localization should never change any interfaces of a class. If long name is required to be the same, then interface is changed.

EDIT: Just tested the above mentioned behavior and changing the localized names indeed breaks the inheritance hierarchy of your class. If you are intending to allow third party developers to inherit from a class that you develop, my recommendation is that never use localized names.

[Mr Mike]

Tomi,

This is the expected behavior. Suppose there were static properties that you wanted to localize. You couldn't do that by overriding. Furthermore, an override should provide a different behavior, not a different name.

If someone wants to create a localized version of a class they cannot modify, they should wrap the class and any parent classes that have methods/properties that need to localized too.

[Tomi Maila]

If someone wants to create a localized version of a class they cannot modify, they should wrap the class and any parent classes that have methods/properties that need to localized too.

I really hope that NI will not localize class property names either as then the child class developers' classes would only work with one localized version of LabVIEW. This would be a nightmare to LabVIEW Tools Network tools developers. Assume there is a class in <vi.lib> that uses localized properties. LabVIEW tool developer creates a tool has a class that inherits from this class in <vi.lib>. The tool is distributed via NI Tools Network. Now someone in Germany downloads that tool with German version of LabVIEW. It will not work, because the localized property names are not matching with the localized version of LabVIEW. The German LabVIEW developer cannot used but German versions of reusable LabVIEW tools. Is this really desired behavior?

[Mr Mike]

I really hope that NI will not localize class property names either as then the child class developers' classes would only work with one localized version of LabVIEW. This would be a nightmare to LabVIEW Tools Network tools developers. Assume there is a class in <vi.lib> that uses localized properties. LabVIEW tool developer creates a tool has a class that inherits from this class in <vi.lib>. The tool is distributed via NI Tools Network. Now someone in Germany downloads that tool with German version of LabVIEW. It will not work, because the localized property names are not matching with the localized version of LabVIEW. The German LabVIEW developer cannot used but German versions of reusable LabVIEW tools. Is this really desired behavior?

This is now CAR 280980. I aim to fix it in the next version of LabVIEW (not 2010 SP1 ). The current solution we're considering is allowing overriding properties to have different long names, but to always show the name from the base class.

Suppose you have the following code:

vi.lib/someClass.lvclass (English LV)  - [Property] One (Long Name = One)	- Read One.vi	- Write One.vivi.lib/someClass.lvclass (French LV)  - [Property] One (Long Name = Un) *** LOCALIZED ***	- Read One.vi	- Write One.viCustomerCode/Child.lvclass (derives from vi.lib/someClass.lvclass; based on English LV)  - [Property] One (Long Name = One)	- Read One.vi (overrides Read One.vi in vi.ib/someClass.lvclass)

If I'm a customer and I ship my Child.lvclass to a French LV user, in 2010 my Child.lvclass will be broken because the long name is different. When this CAR is fixed Child.lvclass won't be broken, but any use of its One property in English LabVIEW will show as "One" and as "Un" in French LabVIEW.

Solution: get the long name from the parent class and allow classes to give a different long name.

[Tomi Maila]

This is now CAR 280980. I aim to fix it in the next version of LabVIEW (not 2010 SP1 ). The current solution we're considering is allowing overriding properties to have different long names, but to always show the name from the base class.

Thanks Mike, your proposed solution makes sense to me.