Quick Drop Enthusiasts

cancel
Showing results for 
Search instead for 
Did you mean: 

Any cookbook converting RCF plugin to QD plugin

Dear users,

is there any cookbook or manual or description, how to convert any RCF (right-click framework) plugin to a QD (Quick Drop) plugin, please? I would like to move away from RCF. Althoug it does the job, it has several caveats, I am not happy with: it does not start automatically in LV13.02f, loading takes long time, it has a cumbersome execution of any plugin. I sensed that multiple developers of RCF plugins moved to Quick Drop and converted their own plugins to it. But some plugins are still available only for RCF. I would like to reuse their code and convert them for Quick Drop.

Cheers,

Message 1 of 7
(8,302 Views)

The problem with converting is that the JKI RCF handles saving configuration information.  The handful of conversions I've made worked without the configuration piece, but the first one I looked at (from your other post - Eric_BOB's Colorize Diagram) relied on that.  I haven't seen/written anything to duplicate the RCF configuration functionality.

Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

0 Kudos
Message 2 of 7
(4,250 Views)

This is a good question and I expect that others have converted RCF plugins to QD.  I was thinking of adding a configuration VI that stores tags containing the config settings, using Darin.K's Get/SetValues vis.  This requires a mechanism to present options for adjustment, but there's no mechanism to use.

Example_VI.png

What have you done to handle user-configurable options in QD?

Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

0 Kudos
Message 3 of 7
(4,250 Views)

Another way to store configuration information would be in the LabVIEW INI file. The VIs in resource\dialog\lvconfig.llb allow to you read/write arbitrary tags in the LabVIEW INI file. I've been meaning to write a nugget about this.

0 Kudos
Message 4 of 7
(4,250 Views)

I would personally like it if QD had a basic framework for plugins to have a UI and to save and load whatever config they have, like I mentioned in the idea here. This could be something like what the RCF had (a table where each param had a name and value which you would edit in the table), so then it's also handled completely automatically, but there's something I never liked about that. I like something like this, but as is, that's mainly useful for UI values, not for loadable params.

Incidentally, both that demo and the CCT save the values to the LabVIEW Data folder which has an advantage (or a disadvantage, depending on your outlook) in that it's user specific and shared between LV versions.


___________________
Try to take over the world!
0 Kudos
Message 5 of 7
(4,250 Views)

Thank yoy for your replies!

I did nothing extraordinary. I ignored the INI files and hoped to live with any default configuration the VI offered. I'd accept a solution where I had to change the default configuration manually, inside the QD VI. But some VIs are not recognized as QD VIs at all.

jcarmody wrote:

What have you done to handle user-configurable options in QD?

0 Kudos
Message 6 of 7
(4,250 Views)

I'm trying this:

QD_MoveToOrigin_BD.png

Typing: Ctrl+Space, "config", Ctrl+<shortcut> brings up a config dialog:

QD_MoveToOrigin_config.png

Not typing "config" results in the default values being used, which are stored in the config VI's tags.  I'd have to make a custom dialog VI for each plugin, but that isn't horrible.

Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

0 Kudos
Message 7 of 7
(4,250 Views)