Can't run RegisterAddon.exe

[vishots.com]

I'm trying to manually execute the RegisterAddon.exe from the command line in order to register my library for the install process. However I get the following dialog every time:

It seems like I need a new version of this? I'm running the V2 of the tool kit and Beta2 of LabVIEW.

[vishots.com]

BTW, what exactly does RegisterAddon.exe do?

[Jervin Justin]

Hi Michael,

RegisterAddon.exe "registers" a LabVIEW Add-on with LabVIEW by adding registry keys to the Windows Registry. (This is why it asks to run with admin priviledges).

This is primarily used by an installer of a "VI based API" to register an lvlib as a licensed library so that it shows up on the "3rd Party Addons" dialog on LabVIEW startup:

If this step is not performed by an installer, LabVIEW will not know about the lvlib when LabVIEW is first launched after the installation of the add-on. However, once LabVIEW is made aware of the licensed lvlib (by using one of its VIs for instance), LabVIEW will write the needed information to the registry at that point so that future LabVIEW launches will know about the add-on and show it on the list of Third Party Addons.

About the error, sorry, that was an error on our part, we did not build the executable in Beta 2 (build 84), that is why you get that message.

Attached is a newer copy that should work with Beta2. (The source is provided with the Toolkit so you can rebuild it yourself with any version: <LabVIEW 2010>\examples\addonlicensing\ProjectTemplate )

[vishots.com]

What are the dangers of not running RegisterAddon.exe? It sounds to me like it doesn't matter.

[Jervin Justin]

Its not terrible, but does create a confusing user experience. Consider the following workflow:

1. User downloads "JervinSoft SimpleMath API" which is a set of VIs licensed in an lvlib and wrapped in an installer that doesn't run RegisterAddon.exe
2. User installs "JervinSoft SimpleMath API"
3. User launches LabVIEW. LabVIEW does not know about SimpleMath API and so does not show an activation dialog and SimpleMath API does not show up in "3rd Party Addons" dialog.
4. --> User tries to use SimpleMath API and gets broken run arrow since SimpleMath API has not been activated. (well, to be fair, in most cases it will be in an evaluation state).
5. User closes LabVIEW
6. User relaunches LabVIEW
7. --> Now, LabVIEW knows about SimpleMath API and does show the activation dialog.

By running RegisterAddon.exe at the install process, LabVIEW immediately will know about SimpleMath API right at the first launch. So the user experience is more consistent.

[Jim_Kring]

Hey Jervin,

It would help, in step 4 where the user tries to use SimpleMath API, if LabVIEW would then show the activation dialog.  Is that a possibility?  And, the user would only get a broken broken run arrow if the user cancelled or failed the activation.

However, I can see how this might not be easy, given any implementation constraints on how LabVIEW checks for activated licenses.

-Jim

[Jervin Justin]

Hi Jim,

That's a good suggestion. I'm not sure what the implementation details are so I'm going to defer that portion to Sohum .

On the positive side:

• When a user installs a toolkit, the license should be in eval state by default (even without the dialog) so the arrow would not be broken
• The error message on the broken run arrow explains how to activate the add-on.

[Jim_Kring]

JervinJustin wrote:

Hi Jim,

That's a good suggestion. I'm not sure what the implementation details are so I'm going to defer that portion to Sohum .

On the positive side:

• When a user installs a toolkit, the license should be in eval state by default (even without the dialog) so the arrow would not be broken
• The error message on the broken run arrow explains how to activate the add-on.

Hi Jervin,

Sorry if I sound confused -- I'm jumping into this discussion a little late.

When you say "on the positive side", these arguments are pros for which proposal/situation (on the positive side of what)?

Thanks,

[Jervin Justin]

Sorry, that wasn't very clear...

What I meant to say is that I'm not sure if adding the dialog really improves the usability, and might come across as intrusive. Especially considering that not having the dialog still has a pretty good user experience because:

• When a user installs a toolkit, the license should be  in eval state by default (even without the dialog) so the arrow would  not be broken
• The error message on the broken run arrow explains  how to activate the add-on.

So what I was trying to say is that while I initially liked the idea, I'm not sure if it is something we need to implement from a usuability point of view.

I say it might be intrusive because consider a use case where a user has a VI that uses multiple licensed APIs. If they move the VI to another computer that doesn't have the licenses, now when they open up the VI they get an activation dialog (in addition to the initial activation dialog they get when they launch LabVIEW). I think its debatable which user experience is better. (Or maybe I just misunderstood you completely).

[Jim_Kring]

Hey Jervin,

I see what you're saying and agree that it's best to do all the activation dialog stuff at start-up.  I agree with you that having LabVIEW show the dialogs when the lvlib is loaded doesn't make for a good user workflow.

Now, there's another use-case, too, which I'd love to see supported for licensed libraries installed by VI Package Manager: I want to be able to call a VI Server method like Application:RegisterAddon(ArrayOfPathsToLVLIBs). If that VI Server method existed, VIPM could invoke it after installing packages containing licensed LVLIBs, which would then prompt the user to activate.  This would fit in perfectly with the VI Package installation workflow.

Thanks,