Do You Need Any Additional Info Passed In To Your QDKS Plugin VI?

[Darren]

The following information is passed in to any Quick Drop Keyboard Shortcut plugin when it runs:

• QD Launch VI Ref - The VI that was active when Quick Drop was launched and your keyboard shortcut was pressed
• QD Combo Box Ref - A reference to the combo box in the Quick Drop window.  Useful for getting either what has been typed, or what has been typed+autocompleted, when your keyboard shortcut was pressed
• Shift Pressed? - A Boolean indicating whether the user pressed Ctrl-[char] or Ctrl-Shift-[char] to launch your keyboard shortcut plugin

There is also a variant input to the plugin, but in LabVIEW 2009, it is not used.  I can pass in anything we want with this variant.  So far, for LabVIEW 2010, the only thing I've thought of that would be useful to pass in to the plugin is whether or not the QD Launch VI's front panel or block diagram was visible when Quick Drop was launched.  This is probably something I should have been passing in from the beginning.

What other information would you like to see Quick Drop pass down to these plugins in LabVIEW 2010?

[Darren]

Nothing else?  Ok, unless I hear from someone on this thread, plan on an active window Boolean (FP or BD) being the only thing passed in to the QDKS variant input in 2010.

-D

[Darin.K]

How about the coordinates of the mouse (converted to pane coordinates would be nice), I can do this in Windows, put a platform independent method would be nice.

[Darren]

My Ctrl-Q shortcut uses the mouse position, but that can be determined from within the plugin itself (on Windows and Linux, anyway).  I'm interested in finding out if anybody needs information that can only be passed in from the Quick Drop framework.  The reason that the QD Launch VI's FP/BD status can only be sent by Quick Drop is that, once Quick Drop launches, it is the frontmost window, and there's no way to tell after the fact if it was the FP or BD of the VI from which QD was launched.  But QD knows, since it retrieves this information before showing its panel.  Thus, this is something that I would need to pass in to the plugin VI from QD if you wanted to know that information.  I'm looking for other info (other than the launch VI ref, QD combo box ref, and Shift pressed) that you might want to know within your plugin, that you have no other way of knowing without QD telling you.

-D

[Darin.K]

A similar technique is part of my shortcut template.  My motiviation was partly platform independence, but mostly to tweak an issue I have with some of my shortcuts.  In a few of my shortcuts I place a floating menu at the mouse location depending on the object under the mouse.  It works pretty well if I stop, Ctrl-space, pause for my shortcut, then select from my menu.  The problem is the lag (perhaps partly due to my machine) between the Ctrl-space and my shortcut gaining control.  I find that I often have moved off of the object in anticipation of my menu or as a result of the QD window popping up.  Having the mouse coordinates at the time of impact would fix this issue.

I have never had trouble determining FP/BD but I welcome the convenience of getting this info, likewise, I don't have trouble determining the mouse coordinates but I would welcome the convenience and the improvement in performance (for my applications).

[Darren]

That's a good point about the mouse coordinates when QD is launched...I'll consider passing that info in from the QD framework, although I make no guarantees for 2010.

But how are you determining the FP/BD frontmost status of the QD launch VI?  I normally use the IsFrontmost? property of the VI, but since QD becomes frontmost when it launches, this property returns FALSE for the launch VI.  How do you do it?

-D

[Darin.K]

I started out using Windows API functions to find the z-order of the windows, but my new trick is to search the combo box strings for 'knob', if it is in the list I assume FP invocation, otherwise BD.  Simple yet effective so far.  I am sure there is some way to screw it up so a robust indicator would still be welcome.

I would have thought that QD was a floating window and ignored by the FP.IsFrontmost property.

[Darren]

Heh, ok...searching for "Knob" isn't exactly localization-friendly, and Windows API calls won't work on Mac/Linux.  So yeah, I'll be passing the value in to the plugin VI in 2010, which is definitely the most robust solution.

Quick Drop is not a floating window...I remember there was a really good reason why I didn't make it floating...but I don't remember what it was.   Trust me, though, it was a really good reason.

-D

[Darin.K]

Allow me to venture a guess, you probably use FP.IsFrontmost to detect if the user clicked outside QD and that would not be possible if it was floating.  That would qualify as a good reason.

[Darren]

I only use IsFrontmost once in Quick Drop...I use it to check the FP/BD status of the VI from which Quick Drop was launched, and I do it before Quick Drop is even visible.

-D