LabVIEW Project Providers

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. 

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.

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.

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-2024 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 4.0 License.

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-2024 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 4.0 License.

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