Leaderboard

Q: What is the value of a Kudo in the Idea Exchange? A: Not much. I've made an interesting observation. Roughly a month ago, two ideas were proposed within a day of each other. My suggestion was that Error Wires should be placed under other wires, and Darin suggested that the Read/Write status of property nodes should be determined by how you wire them. Both ideas were fairly straight-forward, both are coding-related, both had a simple image and clear explanation, and as of now, both have attracted about the same number of comments (12 vs 16) and kudos (65 vs 70). I haven't fully compared the kudos, but it appears there's even about the same number of NI voters and "high-rank" voters for each. However, and I don't think it would be just my opinion, Darin's idea is infinitely more useful and valuable than mine. It's an idea that would allow faster and easier programming, and be a noticeable improvement. Whereas error wire layering - it would be "nice" if it was implemented, but it's just cosmetic, not a game-changer. Yet they've attracted about the same number of kudos. So I can now understand when AQ and other NI reps say that popularity of an idea is a pretty poor indication of its value. PS - go vote for Darin's idea if you haven't already.

Courtesy of Brian Powell:

Remeber that property nodes causes a switch to the UI thread, they can be 1000 times slower than a local variable. //Mike

Property nodes are notoriously slow. There’s an advanced technique called “Defer Panel Updates” that can be used to speed things up.

Check out this long thread which referred to this issue with probes (which I'm assuming is what you're looking at) - http://forums.ni.com/t5/LabVIEW/What-does-quot-refnum-not-valid-in-this-context-quot-mean/m-p/1048044#M465846

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. 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. 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. 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 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.