QD Plugin with a persistent UI across invocations

[DerrickB]

Here's an implementation I've come up with that is able to launch an asynchronous UI for a quick drop plugin that can be interacted with again via an event as long as the UI remains running. The trick here was learning that the NI.LV.Editor context is pretty aggressive with its data cleanup and the feedback node wasn't retaining its value for the event between calls to the QD plugin. The solution I found was to put a static reference to the plugin VI in the UI's BD and that managed to let the QD plugin VI's feedback node work as expected.

The QD Plugin VI that launches the persistent floating UI:

And the persistent UI's BD: (With some of the testing indicators removed now that it's working)

Anyone ever tried creating a persistent UI via QD plugin that used a different method?

[TheQ]

This is not quite the same thing you describe.  The Format Toolbar (https://www.vipm.io/package/qsi_format_toolbar/ ) gets launched by Quick-Drop and then stays open while the Quick-Drop dialog is dismissed.  It is meant to stay open while any VIs are open.  It closes itself if "lonely", meaning it's the only thing open, which allows the Getting Started Window to show again.

[DerrickB]

@TheQ What happens if you run the QD shortcut again that launches it?

Definitely a good idea to monitor loneliness!

[TheQ]

---

@DerrickB wrote:

What happens if you run the QD shortcut again that launches it?

---

That's a good question.  I had to go look at the code.  Turns out I don't do anything and I probably should.  It can't launch more than one at a time but it does wait until that one is closed and then immediately launches the next one.  I guess I should do some kind of check if the Format Toolbar VI is loaded/in memory of that context before allowing the next one to launch.

---

Definitely a good idea to monitor loneliness!

---

There is a private method for watching "loneliness".  It does it automatically for you.

https://labviewwiki.org/wiki/VI_class/Front_Panel.Set_Close_If_Lonely_method

Source for the Format Toolbar is open source at:

https://gitlab.com/QSI_Shared_Code/FormatToolbar

[DerrickB]

Yeah that's what this solves. There's no easy "efficient" way to keep track of stuff in this context so I had to trick the editor context to keep the launcher plugin VI from getting cleaned up. I thought I was losing my mind so I had popups of the values going into and out of the feedback node and it would always return 0 after getting an acceptable value! So it was always just running the code to create another instance of the UI and at one point I had to continually close like 15 instances that would pop up after I closed the previous one 🙂

Norm suggested using global variables to store values but I figured I'd try this and it worked so I could stick with feedback nodes and stuff that stays contained within my VIs. If this hadn't worked I would have been testing using globals to store the event reference next. No clue if this solution will lead to long term editor memory issues or not but some quick tests didn't cause any concern.

And thanks, I'll definitely have to check out that method!

[DerrickB]

And just for some context of my use case: This is going to be an advanced search feature (think looking for reads/writes within a specified type definition in bundle/unbundle nodes and more) and I wanted the QD shortcut to launch it again with the context of a new VI hierarchy as the default search scope. It will also take whatever's in the QD autocomplete (like a project type definition) to generate the starting search criteria. So I needed a way to get the new QD invocation info into the existing UI.