01-18-2013 09:50 AM
Spurred on by a conversation about the special abilities of the "Ref" Property Attribute of a ProjectItem Property...
I wonder what other types of Property Attributes grant super-power abilities -- Sumedha, can you (or someone ) peek into the source of the "Set Tag" function to see if there exist any additional interesting Type Property Attributes other than "Ref"? Of course "Str" and "Bool" and "Int"exist, and to my knowledge have no ability other than data persistence -- but are there other "active" Property Attributes in addition to "Ref"?
What other datatypes can be wired into "Value" that grant the tag "active" abilities?
Or, to better constrain this interest into a request rather than an expedition: can we just get a list of all ProjectItem Property Attributes that exist? And bonus points for a brief explanation of the "special" ones
01-18-2013 04:22 PM
Jack,
Perhaps I missed something but.What do you mean by "Active" attributes? I would imagine any LabVIEW data type that you wire into there will work and it will just pull the type from the LabVIEW data type.
01-18-2013 05:50 PM
David_L wrote:
Perhaps I missed something but.What do you mean by "Active" attributes? I would imagine any LabVIEW data type that you wire into there will work and it will just pull the type from the LabVIEW data type.
I'm giving the name "active" to a Property whose value is automatically mutated by the Project based on certain events.
A "Str" or "Int" Property has "static" (as opposed to "active") XML values. The Type="Ref" Properties have values that automatically update to refer to the new ProjectItem name/location. (It can also be silently deleted by the Project.)
Are there any other Types that are "active" rather than "static"? (Maybe the terminology is bad here.)
01-20-2013 02:49 PM
There may be another 'special' ProjectItem Property that automatically goes through a transformation when read/written: the Password property of a distribution.
It appears this property is just Base64 encoded, but it's not readily evident that existing code writing these properties are using explicit conversions themselves -- the conclusion is that perhaps Base64 encoding/decoding happens automatically with Get/Set Tag... maybe?? If so, what datatype can be wired to Set Tag in order for this automatic coding of the value to take place?
Below is some example source demonstrating this property:
<Property Name="Source[3].properties[0].type" Type="Str">Password</Property>
<Property Name="Source[3].properties[0].value" Type="Str">dGVzdA==</Property> << This one is Base64 encoded -- I wonder if that encoding took place automagically with Set Tag??
01-23-2013 01:38 PM
Sorry for the late response, I got caught up in other things. I am looking intoo the Set Tag method and will update here soon if there are any special transformations applied for certain data types in there.
01-25-2013 12:26 PM
Jack,
I can't find where in SetTag, if anywhere, the Base 64 endcoding is happening. That said because the code for this method propagates down quite a bit, it is hard to do an exhaustive search of all the methods. Could you tell me where in LabVIEW did you witness this behavior exactly? May be I can debug that and see where the conversion happens.
Also, there is no evident special behavior for any other types. The types I noticed being handled in SetTag were - boolean, unsigned int, int, double, string, path (relative and absolute), refNum and binary
01-25-2013 07:10 PM
Sumedha wrote:
Also, there is no evident special behavior for any other types. The types I noticed being handled in SetTag were - boolean, unsigned int, int, double, string, path (relative and absolute), refNum and binary
That's all the info I need. Learning about the special "Ref" type reticulated some significant refactoring, and just wanting to make sure as early as possible we don't have any other game-changing hidden gems and abilities 🙂