Programmatically reload Project Providers?

[wirebirdlabs]

Currently, the only way I know of to reload a Project Provider is to restart LabVIEW. Is there another way?

And just fishing around here: is there chance of getting traction for getting a VI Server property or a new method from "resource\Framework\Providers\API" that could reload a Project Provider? Perhaps, this function would accept a path to the Provider declaration under "resource\Framework\Providers\GProviders" or some other type of unique identifier, allowing them to be reloaded individually. This would be helpful for the end-user experience installing/upgrading Providers.

[vishots.com]

I vote for this! And VIPM should automatically execute this upon provider package install.

[crelf]

I'm still a little surprised it's not there already

I suggest you add it to the Idea Exchange so we can all vote for it over there.

[wirebirdlabs]

Thanks for the support, Mike -- this feature would be a big win for end-users.

I've received support requests from customers installing new versions of a tool using Project Providers, and the fix was simply restarting LabVIEW. (but to the end-user, it looks like a bug in my software)

This would also be crazy-awesome for Provider development! In the meantime, been getting lotsa mileage from David's shortcut

[crelf]

JackDunaway wrote:

lotsa mileage from David's shortcut

I love that you used an emoticon from the LAVA forums for an NI forums post

[wirebirdlabs]

Christopher Relf wrote:

I'm still a little surprised it's not there already

I suggest you add it to the Idea Exchange so we can all vote for it over there.

crelf, I'm stopping by here first before the IdEx, because it's unlikely to gain much traction there (since this is sorta an esoteric request that not many people even need to understand or care about). But I'll certainly toss out the Idea if it helps or needs more traction!

[crelf]

JackDunaway wrote:

Christopher Relf wrote:

I'm still a little surprised it's not there already

I suggest you add it to the Idea Exchange so we can all vote for it over there.

crelf, I'm stopping by here first before the IdEx, because it's unlikely to gain much traction there (since this is sorta an esoteric request that not many people even need to understand or care about). But I'll certainly toss out the Idea if it helps or needs more traction!

Not so much for the traction (there are ideas with minimal kudos that get implemented), just for the traceability.

[wirebirdlabs]

Christopher Relf wrote:

just for the traceability.

That's actually enough to convince me to place an Idea in the IdEx.

But since Project Providers are still *kinda* secret/undocumented, let's allow the conversation play out in this thread a couple days. But you're right, for traceability, it feels like it needs to be in the IdEx.

[David_L]

Hey All,  Here are my thoughts on this:

• As for the idea itself, I agree it would be very helpful.  However, due to the way that Project Providers are deeply integrated into LabVIEW, it will most likely be a very difficult feature to implement.  A good metaphor is how you must restart your computer for many driver installations or Windows Updates to take effect.  There is way too much going on in the background to easily reinitialize it all without reinitializing everything else in the environment.  Because of this complexity and very small audience of provider developers that would benefit from it, it may not be prioritized above other new features in the upcoming versions.  The best way to get this feature on the lineup is to <shameless marketing plug> convince all your friends to create LabVIEW add-ons that use project providers, and then sell them on the LabVIEW Tools Network.  </shameless marketing plug>.
• It is up to you if you want to post it on the idea exchange, but I'm not sure that it would help.  As you said, this feature has a very limited audience and an entry on the uber-public idea exchange might just confuse more people than it would be worth.  Mostly anyone who would actually vote for this idea is already involved in this forum and can take part in the discussion.  And for traceability concerns, I can confirm that the developer and project manager of this potential feature already knows about this thread .  But don't worry, big brother won't be upset if this idea goes up on the idea exchange.
• Probably the best solution/workaround to create a good user installation experience would be to call the restart LabVIEW method after all the files are installed.  Going back to the Windows Update metaphor, I think that it is a reasonable request to a customer to restart their environment after installing such an integrated add-on. 

So that's my take on this, let me know if you have any feedback or concerns.

David

[wirebirdlabs]

Thanks for the answer, David. One single point of clarification: "Because of this complexity and very small audience of provider developers that would benefit from it" It's arguably the end-users who benefit more -- so this is not just for developers on the LabVIEW Tools Network, it's for users also (which is a few orders of magnitude greater). Lotsa beneficiaries of this improvement.

"Probably the best solution/workaround to create a good user installation experience would be to call the restart LabVIEW method after all the files are installed" << Yep -- already been tinkering with a post-installation step. Another idea I'm tinkering with is lazy-loading the app logic and user interfaces -- I have found that the actual Project Provider interface rarely changes, so most the time it's not a big deal if it's not reloaded immediately (since it likely hasn't changed since the last version). On the other hand, I'm trying to engineer the app to be dynamically loaded from disk in order to circumvent (can't say that word without thinking cir-sum-vrent << Arrested Development) the issue. (Harder done that said... still brainstorming and fiddling)