LabVIEW Project Providers

cancel
Showing results for 
Search instead for 
Did you mean: 

ItemID from ProjectItem Ref?

There's an API method to reliably retrieve the ProjectItem Ref given the ItemID -- it's mxLvGetItemRef.vi:

Screen Shot 2013-01-09 at 12.01.39 PM.png

And the only way I've discovered to perform the inverse function is grabbing the intermediate NIIM like so, then using mxLvGetItem.vi:

Screen Shot 2013-01-09 at 12.06.29 PM.png

This works fine if the Project Provider is installed, yet mxLvGetItem.vi fails if the Project Provider is not installed. (Although I have not run into issues for deployed products, this has been a constant source of heartache for development)

The Project Item exists in the project -- with the yellow warning symbol notifying that a Project Provider handler is not present for that item type -- and you can reliably grab a ProjectItem ref to the project item -- but I can't figure out how to reliably determine its ItemID.

Any ideas?

(As an aside, can someone explain the NIIM identifier?)

0 Kudos
Message 1 of 14
(4,370 Views)

Ideally: I would like to hear there's a VIServer method/property that can be pulled directly from ProjectItem that returns the ItemID, or a VI tucked away somewhere. But after extensively searching both these options, and examining lots of other VI hierarchies, have not yet discovered the solution.

If the solution does not exist, perhaps this is a feature request for the next go-round 🙂

0 Kudos
Message 2 of 14
(4,304 Views)

To escalate this thread, I request that if there exists simple fix within mxLvGetItem.vi allowing it to work on items without their proper Project Provider installed, it would be extremely helpful to get that fixed version posted on this thread to incorporate into my application before the next (or next) LabVIEW release. Perhaps the name of the VI could be different in order to avoid redistribution collisions with existing mxLvGetItem.vi's on end-user's machines -- wait, or even better, a new VI name altogether that inputs ProjectItem ref and outputs ItemID, abstracting the private property.

If the fix requires changes beyond the scope of dropping in a replacement VI (or couple of VIs), that's understandable and I will continue to try to redirect my workflow to avoid this situation 🙂 Thanks!!

0 Kudos
Message 3 of 14
(4,304 Views)

Is this what you are searching for?

\resource\Framework\Providers\Common\provcom_GetObjectItemFromProjectItem.vi

/J

Message 4 of 14
(4,304 Views)

Jonas, that's exactly the VI Interface that I'm looking for! I had forgotten about this VI!

But unfortunately, the reason I abandoned it in the first place is because it calls mxLvGetItem.vi (inspect View>>Browse Relationships>>This VI's SubVIs) and therefore returns returns the same error. I'm not exactly sure what the Bind? input is for, but whether set to F or T it still errors.

Screen Shot 2013-01-09 at 3.13.01 PM.png

0 Kudos
Message 5 of 14
(4,304 Views)

From the little that I know and have found out:

JackDunaway wrote:

This works fine if the Project Provider is installed, yet mxLvGetItem.vi fails if the Project Provider is not installed. (Although I have not run into issues for deployed products, this has been a constant source of heartache for development)

The Project Item exists in the project -- with the yellow warning symbol notifying that a Project Provider handler is not present for that item type -- and you can reliably grab a ProjectItem ref to the project item -- but I can't figure out how to reliably determine its ItemID.

The project doesn't recognize the item type because of the missing provider and hence when it tries to retrieve the ItemID it fails. The provider API is designed to return the ItemIDs for known types only.

JackDunaway wrote:

(As an aside, can someone explain the NIIM identifier?)

The NIIM has 4 parts - Item URL, Item ID, Item Index and Specific Type. In the provider framework we only ever use Item ID (which uniquely identifies a project item in a session) and Specific Type (which is the Item Type defined by your primary provider)

Sumedha Ganjoo | LabVIEW R&D
Message 6 of 14
(4,304 Views)

Sumedha wrote:

The project doesn't recognize the item type because of the missing provider and hence when it tries to retrieve the ItemID it fails. The provider API is designed to return the ItemIDs for known types only.

Interesting.

Can we change this? 🙂

ProjectItem manipulation can be done in one of two domains: through the Project Provider API, and through the VIServer API. I've tended to favor the Project Provider API domain using ItemIDs, just because anecdotally using VIServer within the Provider context has been... flaky? Is that the right word? Hit and miss? It's hard to fully characterize exactly how I'm introducing bugs, but it seems many freezes and deadlocks are due to VIServer usage in the Provider context.

But this other limitation -- inability to get ItemID for a Provider who is not installed -- forces your hand to use VIServer, e.g., for reading properties of a ProjectItem. It would be helpful to be able to resolve ProjectItem references back into the ItemID domain, even if the Provider for that Item Type is not installed.

Additionally, there are some interesting methods available in the Provider API yet not the VIServer API, that make it desirable to stay in that domain.

I think the workaround here is just to judiciously shift some tasks back into the VIServer domain, and I can report back on how this refactoring goes.

0 Kudos
Message 7 of 14
(4,304 Views)

Sumedha wrote:

The NIIM has 4 parts - Item URL, Item ID, Item Index and Specific Type. In the provider framework we only ever use Item ID (which uniquely identifies a project item in a session) and Specific Type (which is the Item Type defined by your primary provider)

Thanks!

0 Kudos
Message 8 of 14
(4,304 Views)

JackDunaway wrote:

ProjectItem manipulation can be done in one of two domains: through the Project Provider API, and through the VIServer API. I've tended to favor the Project Provider API domain using ItemIDs, just because anecdotally using VIServer within the Provider context has been... flaky? Is that the right word? Hit and miss? It's hard to fully characterize exactly how I'm introducing bugs, but it seems many freezes and deadlocks are due to VIServer usage in the Provider context.

But this other limitation -- inability to get ItemID for a Provider who is not installed -- forces your hand to use VIServer, e.g., for reading properties of a ProjectItem. It would be helpful to be able to resolve ProjectItem references back into the ItemID domain, even if the Provider for that Item Type is not installed.

Unfortunately, yes that would be the rigth word:\. As you have in the past, please let us know of any VI Server API methods that cause such freezes and deadlocks in the provider context and we will try to get them fixed soon.

Instead of allowing operations on a project item that is missing a primary provider, we should let the user know that they are missing a provider and somehow get them access to the provider. If an item is not recognized by LabVIEW as a valid type reading it's properties and performing actions using VI Server or Provider API should be expected to not work (may be?)

JackDunaway wrote:

Interesting.

Can we change this? 🙂

From what I have investiagted so far this looks like a major change and might get some push-back. I will add this to my to-investigate list to furher see if this is something we can pursue. I will let you know what I find out.

Thanks for all your feedback!

Sumedha Ganjoo | LabVIEW R&D
Message 9 of 14
(4,304 Views)

Sumedha wrote:

Instead of allowing operations on a project item that is missing a primary provider, we should let the user know that they are missing a provider and somehow get them access to the provider. If an item is not recognized by LabVIEW as a valid type reading it's properties and performing actions using VI Server or Provider API should be expected to not work (may be?)

Are you suggesting that VIServer essentially has a security flaw right now since it can operate on Project Items that have an unknown type?

That would make Project Provider development even more difficult.

Currently, I'm developing in a project folder outside of the <resource> directory (i.e.., not in-place), and oftentimes I'm running and testing the Project Provider application from the Main Application Instance. While doing so, I may or may not have the Provider installed, meaning the ProjectItem may be unrecognized by LabVIEW. The ProjectItem is still be read/written/manipulated using VI Server by the application-in-development because the ProjectRef is valid (this is good!), yet I can't use any of the Provider API since the ItemID is invalid if the Provider is not installed and running in the Provider context (this is bad!).

Again, just want to highlight that this is a development inconvenience, not a forseeable issue when running a deployed Project Provider. I'm just trying to refine best practices, and delve into whether simple API changes could make development easier

0 Kudos
Message 10 of 14
(4,304 Views)