LabVIEW Project Providers

cancel
Showing results for 
Search instead for 
Did you mean: 

[Feature Request] Better UX for Missing Project Providers

When you open a project with a custom project item without a Provider loaded to handle the item, it shows warning icon and a dead-end message:

Screen Shot 2013-01-07 at 8.30.27 PM.png

And the message:

Screen Shot 2013-01-07 at 8.28.16 PM.png

It would be super handy if we could specify one or more item properties that are recognized by the LVProj that:

  • ... customizes this message
  • ... gives the user a clickable hyperlink to the product page on where you can get the toolkit (or even invokes VIPM if it's on the LVTN!)
  • ... other ideas?

Does something like this already exist? If not, it would be great to have!!

Message 1 of 8
(4,592 Views)

I think the problem with your suggestion is this:  The error is seen when the plugin is not installed.  But in order to give a custom message, you'd have to install something.  The only way to handle this is if LabVIEW knew every plugin that was possible and we updated a list each year with new project providers.  Might be useful, but difficult to maintain. 

0 Kudos
Message 2 of 8
(4,554 Views)

David_L wrote:

I think the problem with your suggestion is this:  The error is seen when the plugin is not installed.  But in order to give a custom message, you'd have to install something.  The only way to handle this is if LabVIEW knew every plugin that was possible and we updated a list each year with new project providers.  Might be useful, but difficult to maintain. 

Let me re-explain, this time getting more into the technical implementation.

I wish that there existed canonical properties associated with an item that the LVProj would recognize in order to notify the user of the Project Provider it needs. The items self-identify themselves through a tags/properties, rather than necessitating LabVIEW ship with a manifest of known item types (as you describe).

For example, the properties could be called Item.ProviderLocalizedName and Item.ProviderDownloadURL to form a project item that looks like this:

     <Item Name="Project Item Display Name" Type="{0B7BFEE2-070C-4144-A1FF-61D292BDE31F}">

          <Property Name="Item.ProviderLocalizedName" Type="Str">Foo Plugin for LabVIEW</Property>

          <Property Name="Item.ProviderDownloadURL" Type="Str">foo.com/foo-plugin</Property>

          <Property Name="All_the_other_arbitrary_properties_of_the_provider" Type="Str">... and so on and so forth ...</Property>

     </Item>

And the message shown to the user, instead of the dead-end "please contact National Instruments" would say "The plugin needed for the selected item is <Item.ProviderLocalizedName>. Click the link below to download this plugin." or similar, or the URL could even invoke VIPM to download and install!

One specific scenario where this happens is on large teams, where one developer is using a Project Provider, and other developers sharing the same LVProj through source-code control do not have a clean entry-point for identifying and downloading project providers. Maybe this request is too contrived or academic, but it seems like a simple way for Project Provider developers to ensure that developers don't dead end while using their product.

0 Kudos
Message 3 of 8
(4,554 Views)

Well, I feel silly.  Your implementation makes a lot more sense than my first impression.  I like the idea, and would support it!  This would definitely help in closing the gap between a broken project and a (potential) toolkit sale.

0 Kudos
Message 4 of 8
(4,554 Views)

Kind-of as an aside, I distribute my project providers using VIPM, and each project has a vpic file. I wonder if I should include each project provider as a dependancy? And, if so, I'd like to see VIPM do a quick scan of my project on open to determine if I have missing dependancies (like project providers). (I'd also like it to do that on project save so make sure my vipc is up to date, but that's another story). If that functionality existed in VIPM, then this would be a non-issue (assuming you're distributing your providers using VIPM, of course. Which you should be )





Copyright © 2004-2023 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
0 Kudos
Message 5 of 8
(4,554 Views)

More info on the JKI Idea Exchange: http://ideas.jki.net/topic/142982-on-project-open-have-vipm-scan-for-package-updates-of-packages-use...





Copyright © 2004-2023 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
0 Kudos
Message 6 of 8
(4,554 Views)

I wish that there existed canonical properties associated with an item that the LVProj would recognize in order to notify the user of the Project Provider it needs. The items self-identify themselves through a tags/properties, rather than necessitating LabVIEW ship with a manifest of known item types (as you describe).

For example, the properties could be called Item.ProviderLocalizedName and Item.ProviderDownloadURL to form a project item that looks like this:

     <Item Name="Project Item Display Name" Type="{0B7BFEE2-070C-4144-A1FF-61D292BDE31F}">

          <Property Name="Item.ProviderLocalizedName" Type="Str">Foo Plugin for LabVIEW</Property>

          <Property Name="Item.ProviderDownloadURL" Type="Str">foo.com/foo-plugin</Property>

          <Property Name="All_the_other_arbitrary_properties_of_the_provider" Type="Str">... and so on and so forth ...</Property>

     </Item>

I like this idea too. Who will be responsible for writing that property (say URL to download the provider) to the item? I am guessing the primary provider for the item?

      If yes, then this property should be optional and default to the old behavior for supporting existing providers.

Sumedha Ganjoo | LabVIEW R&D
0 Kudos
Message 7 of 8
(4,554 Views)

Sumedha wrote:

Who will be responsible for writing that property (say URL to download the provider) to the item? I am guessing the primary provider for the item?

Exactly. Explicit methods in the Provider API (e.g., mxLvGetItemProviderDescriptor.vi and mxLvGetItemProviderDescriptor.vi) would abstract the Provider API user's need to know the names of these tags. I use the generic name "ProviderDescriptor" because undoubtedly we can collectively think of a few more features in addition to LocalizedName and DownloadURL to add to the conpane of these methods Project Items that do not contain these tags (e.g., legacy Providers) would return default, generic values.

0 Kudos
Message 8 of 8
(4,554 Views)