Metadata property on gObject

[falkpl]

I have always disliked storing extra data with controls in the description section of controls, vis....  This section already has a use for documentation.  I have seen this hijaced for language information, user access security even requirements gateway.  It would be nice if there was a properys similar to a string/binary data section that was devoted for meta data.  This meta data is only accessed programatically.  Users could use this to keep extra information about any Gobject (read or write to this maybe even lock it)  that is useful for coding.  I dont know if this is even possible since it would not be backwards compatable.  This allows metadata to be shared and linked to a reference.  Is there a beter way to do this.

Message Edited by Support on 01-08-2010 04:43 PM

[JackDunaway]

I have tried to think of a way to request this feature, but could never figure out how to word it properly, and it would seem like one of those far-left field ideas. I think the essence of this idea is exactly what I want: a Read/Write property node for every FP object called "MetaData" that is either a string or variant.

[falkpl]

I tried to implement this in an Xcontrol once but it seemed that a native property high up in the gObject hierarchy would solve many problems at once, essentailly a pointer to a memory space for programmers to use for whatever the want to do, for me user access would be a great one, all fp controls get a tag appended to this memory space (Access = 0...10).  then in the program I can do for all controls if access level < current user level, disable or hide, but the possibilities are endless.  I never thought of putting a variant here but a string/binary with a header length would be a catch all,  could use flatten to string, U8 binary data, ini type strings, XML strings ...

Message Edited by falkpl on 01-08-2010 02:54 PM

[falkpl]

Also to the moderator, the title should have read 'gObject' not 'subjects'  spell checker got me here.

Message Edited by falkpl on 01-08-2010 02:53 PM

[JackDunaway]

(In my original post, I had another sentence describing how I had once implemented this as an XControl also for a single ring-type FP control, but a native solution would have been MUCH more elegant. Don't know why, but I decided not to post that....)

Going back to the original post, it looks like you're talking about a reference to the MetaData for a control.... I think it would be better to pass around the ref of the control, then read/write the MetaData property through a property node. I don't think it's necessary for the MetaData field to have a public reference. It would be potentially more powerful to have several objects pointing to one common MetaData, but I would be content with each object having it's own memory space for MetaData. The uses described above and the uses I could have used it for would not need excessively large memory allocations, so data duplication between a few controls is not a big deal. It would be more confusing to have to link an object to MetaData memory space set up somewhere else via some ref, so I would rather the data be read/written by value in a PN.

[tst]

Maybe I'm misunderstanding what you want, but I think this already exists. LabVIEW has the concepts of tags for objects - you call the Set Tag method on the object, give it the name and value of the tag (a variant) and from now on that object has the tag.

Caveats:

1. I think the tag VIs belong to the GObject class, but I can't check. They belong to a lower level (although no lower than Control).

2. They're currently private and will probably stay that way. In 8.6 and later, there are two sets of VIs in vi.lib to store and read user tags - one for VIs and one (I think) for GObjects. The VI also adds a namespace, so the tag name does not collide with NI tags.

3. I believe they can't have LVClasses data stored in them.

Does this do what you want?

[tst]

P.S. You can find a quick example of using tags here. The nice thing about tags is that if you have the ability to save the VI, you can set them to be persistent.

[falkpl]

Interesting, I will look into tags.  Persistance is important since metadata needs to stay between runs. I just am looking for a method af marking objects for later use (such as for security access).  Thanks

[JackDunaway]

This already exists as a private method: see Darren's nugget. There's a newer Idea that asks for these tagging wrappers to be placed on the palette. Paul, would you agree we can mark this Idea as complete?

[Todd S.]

Included as part of LabVIEW 2009.

[G-Money]

Available in NI LabVIEW 2009