04-04-2014 04:17 PM
This plugin is for OCD developers. I based this on the QD_MoveToOrigin plugin by jcarmody.
This plugin works on both the front panel and the block diagram. It moves the chosen window contents to the origin with an offset of one grid square. It then resizes the window so there is a one grid square border around the entire contents.
*** Updated with dynamic reading of FP and BD grid sizes from ini file. Thanks for the tips on how to do this. ***
**** Updated to process selected diagram instead of using <shift> to select. ****
**** Updated Oct 9, 2014 - Improved window resizing for active monitor. Will now attempt to fit the monitor if content exceeds monitor dimentions. Works in both verical and horizontal dimentions independantly.
This is my first QD plugin, so please let me know if there are any changes or improvements you would like to see.
04-16-2014 08:38 AM
I don't know of any property to read the grid size values, but they are stored in the LabVIEW.ini file if they have been modified from defaults. I doubt you want to read these values from file for a QD, but just in case...
Thanks for sharing your QD plugin.
PS. And, to demonstrate the severity of my ailment...
04-16-2014 12:07 PM
Use the VIs in resource\dialog\lvconfig.llb to read LabVIEW INI entries...much easier than having to find the file on disk then use the Configuration File VIs.
04-16-2014 01:09 PM
Thanks for the suggestion. I have added this feature so it will adapt to your custom grid settings.
04-16-2014 03:58 PM
Instead of using the shift key to choose between FP and BD, why not just have one shortcut that acts on whichever window is active?
04-16-2014 04:02 PM
I agree, you can use the "QD Launch VI Panel?" output of QuickDrop Parse Plugin Variant.vi to see if Quick Drop was launched from the panel or the diagram.
04-16-2014 04:11 PM
Didn't know about that feature. Why is that VI buried under vi.lib and not next to the plugins folder?
I will update with this vi to eliminate the need for <shift>.
04-16-2014 04:13 PM
That VI is part of the plugin template, so hopefully it should be pretty discoverable. It's in vi.lib so that plugins can have a symbolic link to it, whether or not the plugin is in the <resource> or <LabVIEW Data> folder. This decision was made before the LabVIEW release where <resource> is also a symbolic path.
04-17-2014 01:51 PM
Thanks for the advice on the lvconfig.llb instead if the INI VIs.
My question is how are LV users supposed to know these VIs are there?
I've never seen them mentioned in a training class, displayed on a palette, used in an example, etc.
I amazed and sad I've not seen these for so many years.
04-17-2014 01:59 PM
Yeah, there's lots of useful stuff that ships with LabVIEW that isn't officially supported, and thus, doesn't receive much attention. I tried to highlight some of the more useful stuff in my Hidden Gems in vi.lib presentation. The lvconfig.llb VIs are the only non-vi.lib VIs to make an appearance in that presentation.