Quick Drop Enthusiasts

cancel
Showing results for 
Search instead for 
Did you mean: 

QD Plugin with a persistent UI across invocations

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:

ui launch.png

 

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

UI BD.png

 

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

0 Kudos
Message 1 of 6
(2,733 Views)

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.

Quentin "Q" Alldredge

Chief LabVIEW Architect, Testeract | Owner, Q Software Innovations, LLC (QSI)
Director, GCentral | Admin, LabVIEW Wiki | Creator, The QControl Toolkit
Certified LabVIEW Architect | LabVIEW Champion | NI Alliance Partner



0 Kudos
Message 2 of 6
(2,707 Views)

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

Definitely a good idea to monitor loneliness!

0 Kudos
Message 3 of 6
(2,695 Views)

@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.

 

VI-Front Panel-Set Close If Lonely.png

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

 

 

Quentin "Q" Alldredge

Chief LabVIEW Architect, Testeract | Owner, Q Software Innovations, LLC (QSI)
Director, GCentral | Admin, LabVIEW Wiki | Creator, The QControl Toolkit
Certified LabVIEW Architect | LabVIEW Champion | NI Alliance Partner



0 Kudos
Message 4 of 6
(2,688 Views)

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!

0 Kudos
Message 5 of 6
(2,677 Views)

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.

0 Kudos
Message 6 of 6
(2,672 Views)