11-21-2012 03:17 PM
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!
11-21-2012 11:30 PM
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
11-22-2012 12:08 AM
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.
11-29-2012 08:38 AM
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?
11-29-2012 12:15 PM
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.
11-29-2012 12:18 PM
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.
11-29-2012 03:07 PM
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.
11-29-2012 03:33 PM
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.
11-29-2012 04:07 PM
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
11-29-2012 04:18 PM
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.