Quick Drop plugin - retain data across calls

[Marshall Eubanks]

I'm trying to figure out the best way to retain data across Quick Drop plugin calls (or between Quick Drop plugin functions). So, I have essentially a global variable which I can prompt the user for the first time, or set/change from a separate command. This would allow be a convenient middle ground between hard-coding the data (thus requiring changing the actual plugin code), or prompting the user every single time. 

This doesn't seem to work with global variables, or named queues. 

What's the simplest way to accomplish this? I'm sure I can go outside LabVIEW and save to disk, or the Windows registry or something like that, but I'm looking for a way to accomplish this within LabVIEW.

[Jim Kring]

My recommendation would be to save the data to disk in the LabVIEW Data folder:

<Documents>\LabVIEW Data\2019(32-bit)

There really isn't a good way to retain data across Quick Drop calls unless you do something to keep a running process in memory behind the scenes, which is a big can of worms...

Yair's solution looks great -- I wasn't aware of that nice feature!

Edited July 20, 2020 by Jim Kring

[Yair]

The Application class has a couple of private methods which can do this (called Global Data.Set and Get) which operate on a name and a variant value (I believe this goes back at least to 2009). I think this should persist across QD calls. Note that you should pick a name which will be different from other things which might exist in the system.

[dadreamer]

24 minutes ago, Yair said:

Global Data.Set and Get

By chance I came across those private nodes too and played with them a little. They allow to retain the data per LabVIEW process. That means, you may get access to data in any VI in any project. Feels like Tags, that are not stored inside VI DS. Neat feature, indeed.

[Darren]

Yup, Quick Drop itself (along with several other G-based LabVIEW features) uses Global Data Get/Set. Standard disclaimers apply (private methods are not documented or supported by NI), but these should get you what you need. I agree with Yair that you need to make sure to namespace your data appropriately so it doesn't potentially collide with other Global Data.