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

Persistent Item IDs or GUIDs

I'm looking around for a means of identifying a Project Item that is both persistent between IDE sessions and globally unique.

Some methods of identifying Project Items are globally unique, but none of these are persistent, including: ItemID (the U64 for the Provider API), NIIM ItemID, and ProjectItem VI Server reference.

My hunch is that this feature may not be available, because App Builder stores references to Project Items as XPath-esque identifiers. This is not a good solution for my case, since it's not robust against project tree mutations (e.g., renaming Project Items, or moving them to another Virtual Folder) -- assuming we're not actively monitoring and handling these mutations.

Can you suggest a method of uniquely identifying Project Items that persists between sessions with the current APIs (i.e., without writing my own identifying tags to the Project Items)? It would be awesome to hear I'm just blindly overlooking this feature!

0 Kudos
Message 1 of 30
(535 Views)
29 REPLIES

Re: Persistent Item IDs or GUIDs

I don't think there is any general way to uniquely identify a specific project item (without writing your own identifier tag to it).

We are lazy and save TargetName, BuildType and BuildName as the identifier. In the future however, I believe we will update to write our own property(ies) to the build items, unless NI adds unique identifiers first.

/J

0 Kudos
Message 2 of 30
(360 Views)

Re: Persistent Item IDs or GUIDs

Mellroth wrote:

In the future however, I believe we will update to write our own property(ies) to the build items, unless NI adds unique identifiers first.

I'm considering this also. Though, for my app, this could apply to any arbitrary project item, not limited to just Build Specs -- and it feels kinda "dirty" for a third-party Project Provider to start slinging GUIDS all over the project. If these GUID additions were contained to just the Build Specs (which already have many properties), or especially Project Items created by the Provider, it wouldn't feel so "dirty"

One of the biggest considerations here is leaving as contained a footprint as possible on the LVProj -- just to mitigate and contain risk of touching the end-user's LVProj.

0 Kudos
Message 3 of 30
(360 Views)

Re: Persistent Item IDs or GUIDs

Perhaps I'm misunderstanding the use-case, but I believe the intended API for this is simply the project item properties.  These can be set and get with mxLvSetXxxxProperty.vi and mxLvGetXxxxProperty.vi in <LabVIEW>\resource\Framework\Providers\API.  As long as the "persist property" input is set to true, this property will be saved to the lvlib file for the specific item.

Does this help do what you need?

0 Kudos
Message 4 of 30
(360 Views)

Re: Persistent Item IDs or GUIDs

David_L wrote:

Perhaps I'm misunderstanding the use-case, but I believe the intended API for this is simply the project item properties.  These can be set and get with mxLvSetXxxxProperty.vi and mxLvGetXxxxProperty.vi in <LabVIEW>\resource\Framework\Providers\API.  As long as the "persist property" input is set to true, this property will be saved to the lvlib file for the specific item.

The problem here is not persisting properties themselves between sessions -- the problems is persisting the pointer/reference to the project items between sessions. The API takes ItemID as the top-left input, and ItemID (and NIIM and ProjectItem) changes at run-time from session to session -- it's necessary to have a persistent item GUID to enable project items to establish relationships with one another.

0 Kudos
Message 5 of 30
(360 Views)

Re: Persistent Item IDs or GUIDs

JackDunaway wrote:

Mellroth wrote:

In the future however, I believe we will update to write our own property(ies) to the build items, unless NI adds unique identifiers first.

I'm considering this also.

On second thought, this cannot work -- in order to dereference the GUID would involve loading and searching every single Project Item, which doesn't scale beyond several dozen, perhaps a couple hundred project items.

0 Kudos
Message 6 of 30
(360 Views)

Re: Persistent Item IDs or GUIDs

Can you use a combination of Project Path and Item Path/ Name? I might not have understood the problem completely and this might be too simplistic for your use-case.

Sumedha Ganjoo | LabVIEW R&D
0 Kudos
Message 7 of 30
(360 Views)

Re: Persistent Item IDs or GUIDs

Sumedha wrote:

Can you use a combination of Project Path and Item Path/ Name? I might not have understood the problem completely and this might be too simplistic for your use-case.

This is a brittle solution; once the item is moved to a new virtual folder, or renamed, the reference is broken.

0 Kudos
Message 8 of 30
(360 Views)

Re: Persistent Item IDs or GUIDs

Ah I see your point.

I was thinking about VIs and other items that have a path on disk. To me if a VI name or path is changed it should be considered as a new item and not the same item as before. But that doesn't stand true for other items like build specs

Sumedha Ganjoo | LabVIEW R&D
0 Kudos
Message 9 of 30
(360 Views)

Re: Persistent Item IDs or GUIDs

Sumedha wrote:

Ah I see your point.

I was thinking about VIs and other items that have a path on disk. To me if a VI name or path is changed it should be considered as a new item and not the same item as before. But that doesn't stand true for other items like build specs

If the item is renamed through LabVIEW, it should arguably still be the same item (at least, for my intents and purposes, it would be helpful to maintain the linkage to renamed items -- perhaps there are other scenarios where you would treat this as a new item), but even in this situation the linkage is broken.

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