Quick Drop Plugin: Align & Compress BD/FP Objects

[jcarmody]

I've written a QD Plugin for aligning selected objects.  Invoke it by <Ctrl><Space> <Ctrl><a> or, to vertically compress the selected objects, <Ctrl><Shift><a>

You can change the shortcut by renaming the Top Level VI in Align.llb

2010.12.03 - (1) changed size of dialog (so it's not cut off) and removed redundant instruction (2) handled panel close event to prevent hanging QD framework (3) changed distribution to match alignment (align left/right/horizontal centers = vertical compress, align top/bottom/vertical centers = horizontal compress).

2011.08.25 - changed the appearance of the interface.  ctrl-space to activate QD then ctrl-a to align or ctrl-shift-a to align and stack.  It's not completely thought out as a general solution for everyone, but it could be...

2014.01.28 - changed the Front Panel allignment to not align on the increment/decrement buttons (based on this idea in the Idea Exchange)

[Darren]

Having plugin VIs reside within LLBs isn't officially supported.  The preferred file arrangement is to have your shortcut as a top-level VI in the plugins folder, and any support VIs in an LLB or folder next to the VI.

[Darren]

Also, the key dialog is cut off on my machine:

[Darren]

And one more thing...

When you click the red 'X' on the key dialog, it hangs Quick Drop...

[jcarmody]

Thanks Darren.  I've updated the file.

[jcarmody]

I've updated the plugin.

[Hooovahh]

Thanks for the update, but I think you might want to mention that it now is for 2013 or newer where the previous versions worked as far back as 2009.

Still very cool.  Also you know what I think might work well is combining this QD with this one:

https://decibel.ni.com/content/docs/DOC-13623#comment-17020

Where if you are on the front panel, and no items are selected, run plugin I linked to, and if items are selected run the one here.

[JW-JnJ]

Nice I like it. Definitely easier for multiple selections.

I always feel weird commenting on code of someone better than me. Should the "Pnl","SelList[]" references be closed after using them?

[Hooovahh]

JW-JnJ wrote:

I always feel weird commenting on code of someone better than me. Should the "Pnl","SelList[]" references be closed after using them?                 

Some references do nothing if you try to close them.  The close doesn't reall close, what it does is request LabVIEW to close a reference.  But if LabVIEW is forced to keep that reference open then it stays open.  This would be one of those cases. 

If I open a VI reference, then get a reference to the panel, and close that panel, nothing will happen because the VI that owns that panel is still in memory, and I'm probably acting on that VI.  The reference returned is likly the "This" reference which doesn't change between calls.  This is one indication that it doesn't need to be closed. 

If an operation returns a new unique reference then it should be closed.  Knowing when you should and shouldn't close a reference isn't always clear, but generally if you opened the reference, you should close it.  Some times I run code continuously and see if memory increases, or if the references returned are the same refnum.

[Darren]

JW-JnJ wrote:

                       

Should the "Pnl","SelList[]" references be closed after using them?

                   

You never need to close a reference to anything that inherits from the GObject class. The Close Reference call is a no-op, and LabVIEW will clean up all those references once the VI that owns those GObjects goes idle or leaves memory.