LabVIEW Project Providers

Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.

Re: Persistent Item IDs or GUIDs

JackDunaway wrote:

It appears NIIM.Item ID is unique for each LabVIEW session. See this post (https://decibel.ni.com/content/message/44611#44611) for a quick-and-dirty VI that confirms this.

So if NIIM.Item ID from one session is persisted (say, to the project root tag, or even an external file!), in the next LabVIEW session, with the Item From Item ID Project method be able to resolve this old Item ID into a the correct ProjectItem reference? Because if we were to snag NIIM.Item ID from this newly created reference, it would be a different NIIM.Item ID than was persisted.

That's a blunderous, wordy setup, but in a nutshell -- is the Item From Item ID method smart enough to resolve Item ID from a previous session?

Looks like when saved as a reference using the Set Reference provider API, NIIM.ItemID is saved as <Property Name="RefValue" Type="Ref">/My Computer/<Folder>/<item name></Property> in the property bag. This property gets updated to point to the modified item if any changes are made to the project item by say renaming or moving to another virtual folder. The Get Reference API converts this value to a valid Item ID. As long as you get the correct project reference the Item From Item ID should be able to resolve this Item ID to the unique project item.

Saving it in an external file might not work because you need the project reference to get the Item ID.

JackDunaway wrote:

I have not yet tried this solution since it takes a little while to set up a test, but can confirm a concept past you before trying?

Yes, please let me know once you have some test set up. I have tested it a little bit and it was working for a simple test I ran.

Thanks!

Sumedha Ganjoo | LabVIEW R&D
Message 21 of 30
(124 Views)

Re: Persistent Item IDs or GUIDs

Mellroth wrote:

Interesting, I have tried the SetRef and GetRef method but always got errors.

What kind of references can be used in these methods?

I have only tried it with the NIIM.Item ID and am not sure what's the scope of values that work on it. I will have to test it some more to find that out. What value did you use that errored out?

Sumedha Ganjoo | LabVIEW R&D
0 Kudos
Message 22 of 30
(124 Views)

Re: Persistent Item IDs or GUIDs

Sumedha wrote:

Looks like when saved as a reference using the Set Reference provider API, NIIM.ItemID is saved as <Property Name="RefValue" Type="Ref">/My Computer/<Folder>/<item name></Property> in the property bag. This property gets updated to point to the modified item if any changes are made to the project item by say renaming or moving to another virtual folder.

This sounds promising -- can't wait to try! Will report back this weekend.

0 Kudos
Message 23 of 30
(124 Views)

Re: Persistent Item IDs or GUIDs

Sumedha wrote:

Yes, please let me know once you have some test set up.

OK, it took some studying, but I finally "get" it now. To start with a quote from my post #11 on this thread:

JackDunaway wrote:

...if I understand correctly, the Provider would have to actively monitor for these rename operations and update the referencing Project Items -- it feels like this could get messy.

This subscribe-for-mutations-and-update-references is *exactly* the native ability that Sumedha has shared in post #17!!

The mxLvSetVIRefProperty.vi and mxLvGetVIRefProperty.vi functions create properties with the special ability to auto-mutate when their referenced items are renamed/moved in the IDE.

One thing to point out -- these function names can be misleading -- might better be suited as mxLvGetProjectItemRefProperty.vi -- since fortunately this referencing ability seems to work for any arbitrary Project Item (even non-LabVIEW filetypes). Niiice.

Another, potentially glaring gotcha: if the referenced project item is removed from the project, the <Property Name="RefValue" Type="Ref"> property is silently deleted from the referencing ProjectItem.

This is perhaps an entry for the Idea Exchange, but if one project item is referencing another, and the referenced project is removed from the project, the removed ProjectItem should fall into the Dependencies section of the project. That way, static linkages between project items could exist, just as static linkages between VI call hierarchies will always land in 'Dependencies' if removed from the project.

(This idea could also be a freebie to solve a few bugs/deficiencies with App Builder Build Specs who statically declare build resources such as Readme Docs, Icons, Additional Files, etc... yet the linkage is silenty stripped from the build spec if the project item is removed.)

Gotchas aside, a huge +1 and thank you Sumedha!

0 Kudos
Message 24 of 30
(124 Views)

Re: Persistent Item IDs or GUIDs

JackDunaway wrote:

if one project item is referencing another, and the referenced project is removed from the project, the removed ProjectItem should fall into the Dependencies section of the project.

A little more thinking about this...

Does there already exist an API method, or ability to apply some secret-XML-attribute-sauce to a ProjectItem, to declare it as Dependency if removed from the Project?

0 Kudos
Message 25 of 30
(124 Views)

Re: Persistent Item IDs or GUIDs

Reporting back more information to add to the tribal knowledge:

Going back to the conversation about choosing the Project Provider API domain versus the VI Server domain, and the advantages of each, I was a little nervous to think that mxLvSetVIRefProperty.vi and mxLvGetVIRefProperty.vi might be the only way to create Reference Properties....

And on a hunch tried this construct just as a test:

Screen Shot 2013-01-17 at 9.10.14 PM.png

And got this new ProjectItem Property as a result:

Screen Shot 2013-01-17 at 9.13.44 PM.png

SUCCESS! We can manipulate Reference Properties in both ItemID and ProjectItem domains. For now I will choose this VI Server method, because it works better simulating in development.

I'm continually delighted with the intuitiveness and discoverability of the VI Server API. :thumbup1:

0 Kudos
Message 26 of 30
(124 Views)

Re: Persistent Item IDs or GUIDs

Sumedha wrote:

Mellroth wrote:

Interesting, I have tried the SetRef and GetRef method but always got errors.

What kind of references can be used in these methods?

I have only tried it with the NIIM.Item ID and am not sure what's the scope of values that work on it. I will have to test it some more to find that out. What value did you use that errored out?

I don't remember what value I tried to set or get. It was probably in the lines of what Jack is doing, but I wasn't as persistent as he is.

I really hope NI takes all these comments and put them in some kind of knowledgebase, and even use them in the next version of the provider documentation.

And while you do that, you should offer Jack a pile of beer for all his findings

/J

0 Kudos
Message 27 of 30
(124 Views)

Re: Persistent Item IDs or GUIDs

Mellroth wrote:

And while you do that, you should offer Jack a pile of beer for all his findings

JackDunaway wrote:

And on a hunch tried this construct as a test:

Thinking about this more, I wonder what other types of Property Attributes grant super-power abilities such as the ProjectItem "Ref" -- let's take this conversation to a new thread.

0 Kudos
Message 28 of 30
(124 Views)

Re: Persistent Item IDs or GUIDs

Mellroth - I couldn't agree more! Jack's work and findings have been very valuable and honestly taught me a lot of new things I didn't know about the provider framework

Jack - Just thinking out loud...Because I couldn't find a secret property of a project item that I could enable and say add this to dependencies if deleted, I have been trying to think of other ways to achieve this. Seems like the issue is that Dependencies can not supoprt other file types. So theoretically we could use Item_OnDelete event of Item Interface in a provider for a project item, and add the item to the Dependencies in the project on delete. But on re-load the Dependency wouldn't be there anymore, so the issue we are trying to address here is that Dependencies should support other types, right? As if it did, we would be able to achieve what you are trying above.

That's a lot of rambling from meSmiley Happy, to explain what I am saying better I have attached an example provider (built in Lv 2012). Create a project and add a VI1 and VI2 (VI1 calls VI1) to the project. Save everything. Right click VI1 and go to SecondaryProviderExampel1->MySeocndary_PopUp, VI1 will get added to Dependencies now. I am guessing that instead of a VI this could be implemented for any other project item type. But now on re-load of the project, if it wasn't a VI or a library it will not show up as a Dependency in the project.

Once again, thank you for all your super awesome work! I will follow-up about the diffrent property types on the other thread.

Regards,

Sumedha

Sumedha Ganjoo | LabVIEW R&D
0 Kudos
Message 29 of 30
(124 Views)

Re: Persistent Item IDs or GUIDs

Sumedha wrote:

Once again, thank you for all your super awesome work!

Likewise! Working in the Provider context has its high highs and low lows, and it's good to know you and David constantly working hard with the resources you've got.

I think that to solve the dependency problem, we just gotta have a new property or attribute of a property for Project Items that mark it as a "referenced" item -- either that, or the Project Bookeeper (or whatever the executive manager, under the hood, is automatically mutating "Ref" typed Project Items) just has to honor "Ref" items by automatically including them in Dependencies instead of silenty removing (one advantage of a new "referenced" attribute, is a Project Item can mark itself as referenced, even with no refees -- this is valid, but a little more exotic compared to the Bookeeper just keeping referenced items). Writing a Project Provider to act as an auxiliary Bookeeper seems like the only solution right now -- looks like this is the direction you've headed with the example -- will decide later if this solution weighs favorably against the size of the inconvenience/problem!

0 Kudos
Message 30 of 30
(124 Views)
Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.