Bean

Yair- Works! For our application, I just had to add a SetWindowPos (hWndInsertAfter = -1) afterward to keep the window in front (topmost)... Thanks for the help! Set Calling VI Wnd Topmost & Active.vi

Also replied here. I'm trying to do the same thing, only I want to make a VI which is run via Call By Reference from a remote application instance always on top with key focus. I can get always on top to work like you did, where I call SetWindowPos twice (once with hWndInsertAfter = -2 and again with it = -1). Then, I get two "active" windows and the wrong one (launching application) has key focus. SetFocus, SetActive, etc. seem to be no help whether I call them before or after SetWindowPos. SetForegroundWindow just makes it blink 3 times, like you had experienced... Any Ideas?

Thanks asbo...

Problem still persists ...

Just make sure you only do one event per Event Registration Refnum when bundling the Event Registration Refnums into a cluster. I originally tried to group "sets" of events this way and revealed a bug. But, the way Ton has displayed will work since he just has 1 event (in this case, user event) per Event Registration Refnum.

[Aside: Not sure why my previous image blew up after I posted it. If you click the image, you should see the correct size. This hasn't happened with previous posts.]

It worked. For reference, I deleted the first item in the array, leaving the following image. Now, when I press (Ctrl), nothing happens; however, when I press (') and (1) together, I can use LVSpeak. Thanks Norm!

Norm- If I hold down the Ctrl key (when selecting items, when scrolling through cases, when I'm thinking, etc.), LVS will drop random functions. Is there a way to remap the keyboard "activate LVS" shortcut? Thanks, Jason

It's Darin.K's shortcut (not Darren's) [what's the chance of the 2 guys producing QD shortcuts having the same "name"?] Well, his is just called "A.vi", but the nice thing about your implementation is that I get to name things according to the way that my mind works (and my my ability to enunciate). Yep. If I step into VIs until they're all open and then try the command again (without stepping), then I get the correct reference and no errors. Not sure why it's won't work for the panel, but other QD plugins also work on the diagram but not the panel (e.g past excel numeric, paste excel string, ...).

Norm- I added "scalar to array" and "array to scalar" as we've discussed earlier via the QD interface (Ctrl-A created by Darin.K). It works when I highlight a terminal and speak "scalar to array" on the diagram, but not on the front panel. I added the code to the "BD" and "FP" cases in the QEC - Replace.lvclass:Execute QEC VI. See below for a screen shot of QuickEdit Command.lvclass:Execute QEC VI, which is reporting FP.IsFrontmost = False. I've highlighted the FP control before speaking "scalar to array", so the FP of my VI should be frontmost; however, the reference that I've probed (going into the FP.IsFrontmost method) points to the QuickEdit Command.lvclass:Execute QEC VI (not my VI). Any ideas as to why this would work on the diagram but not the panel? (QD works fine either place.) Thanks... -Jason

Here's the hierarchy of actions that I'm visualizing: User Input [Ctrl-Space (QD), Hold Ctrl key (LVS), Ctrl-Alt (as I've configured RCF)] >>Framework [convert user input into worker VI inputs and call respective worker VI] >>>>Worker VI* [one worker VI per action] >>Framework [cleanup] User Input [if needed, e.g. for LVS, release Ctrl key] *Worker VIs = VIs that do the placing, deleting, organizing... (e.g Align left edges.vi, Move labels to side and justify text.vi, Go to pizzahut.com.vi, Wire nodes by corners.vi, etc.) So, the framework (QD, LVS, RCF) would be responsible for specifying the user interface (media, GUI, etc.), processing / differentiating user input to pass as inputs to the worker VIs, and cleaning up after the worker VI runs. This could require some decoupling / re-tooling from the various frameworks in order to standardize "what" the worker should and should not be responsible for (e.g. Transaction.End Undo). I don't know that it's necessary to standardize on a common framework or even subsection of the framework (e.g. Quick Edit). Certain worker VIs are going to have inputs that are unsupported by some frameworks. For instance, in QD we can change VI server class based on what a user types. So, QD allows passing an action with data. I don't know that it's imperative that LVS, RCF, etc. support action + data worker VI calls. And, that's okay because QD fills that void. So that class / type of worker VI would not be supported by all frameworks BUT could still be a sub-class of some workerVI.lvclass. Q: Can we assume that folks writing scripting worker VIs are familiar with LVOOP? If not, "we" (DN, NK, JK...) could specify worker VI templates without LVOOP (e.g. "action", "action + data", etc.). I know that was abstract, but maybe there's something in there that confirms / challenges what you were already thinking or leads to some completely new idea...

So, with a CSI (Common Scripting Interface) / USI (Universal Scripting Interface), if folks preferred (after R&D implements the following), they could just as easily use their LVSpeak, QD, RCF add-ons with Darren's Plug-in VIs for Right-Click Menu Options. There are probably already discussions going on about having a CSI elsewhere, but I just came across that Plug-in VI idea by Darren again, and wondered: Do we really need to have 4 different implementations for each scripting tool?

Thanks to your example, I've seamlessly integrated some of my favorite QD shortcuts in the "QEC - Replace" class. (Nice work auto-populating the command list). Glad to hear we're sync'ed up. I mentioned before that I'm a beginner with LVOOP, so thinking through this *small* aspect LVSpeak has been a timely challenge for me. It's good to see a real-world example demonstrating the benefits of dynamic dispatch. I could be dreaming here, but because I REALLY value efficiency (ref. interest in LVS, reason I studied ISE) and in the spirit of code reuse... [***EDIT*** « SHOULD BE A LIGHT BULB EMOTICON HERE] maybe if "we" (Norm, Darren, Jim) put our our minds together, their could be a common interface for LVS, QDS, RCF, etc. to call worker VIs. Worker VIs = VIs that do the placing, deleting, organizing... (e.g Align left edges.vi, Move labels to side and justify text.vi, Go to pizzahut.com.vi, Wire nodes by corners.vi, etc.) This way, users could access the same scripting features they enjoy using the method they chose [voice (LVS), keyboard (QD), mouse (RCF)] all the while making scripting developers more productive (ref. adage about 1 small rock and 3 fowl).

Hey Norm- Resolved. The following maybe what you meant above... Regarding the implementation, the thought that comes to mind would be to have a "QEC - Quick Drop" sub-class of the "QuickEdit Command" class. Then, inside "QuickEdit Command.lvclass:Execute QEC" VI, have a subVI that runs as a no-op unless dispatched by the "QEC - Quick Drop" sub-class. When dispatched by "QEC - Quick Drop", you could run the "Transaction.End Undo" method. In the future, this allows for expansion, where you might have a "QEC - Right Click Framework" sub-class (of the "QuickEdit Command" class) that requires invoking other methods/functions before dispatching the "QEC - Right Click Framework.lvclass:Execute QEC" VI. Essentially, when accessing other scripting APIs, you would have the ability to dispatch custom routines based on their class if you group them accordingly. (I guess I'm making the assumption that the "Transaction.End Undo" method is necessary for both FP and BD. If not, then you would need it in every BD case within the "QEC - Quick Drop.lvclass:Execute QEC" VI. And, therefore, dispatching another subVI from the "QuickEdit Command.lvclass:Execute QEC" VI, at least for Quick Drop, would be unnecessary.) At first, placing the Quick Drop commands in their respective Plugins categories [e.g. "remove and rewire" in the Replace (QEC - Replace.lvclass) category] seems organizationally appealing, but I wonder if segregating them doesn't make the code more logical. This would also allow us to quickly tell which Quick Drop shortcuts, Right Click Framework add-ons, etc. are present. Aside: How do I place down a "Transaction.End Undo" method without copying it from some other diagram? I may not have installed VI Scripting after re-rolling my PC, so that probably explains it. *thanks* -Jason

Norm- Thanks for the help. Regarding "remove and rewire", I followed your instructions and probed around but don't see any errors going into or leaving R.vi. See below for a screen shot with error probe and probe for the VI refnum input. Is that VI refnum what R.vi is expecting? -Jason

Hi Norm, You have another *fan*. I was taking notes when things didn't work in the videos, so for reference, here they are: unbundle wire (doesn't work) change to control (from constant, doesn't work) change to indicator (from constant, doesn't work) align with terminal (aligning constant doesn't work) I'm having the same experience that John had above. "remove and rewire" doesn't work, but everything else does. I'm not sure that Execute QEC VI is running. I opened it and turned on Retain Wire Values. When I speak "remove and rewire", I see the command appear in the LVSpeak applet, but nothing happens. The wires in the Execute QEC VI are all empty. (Granted I'm a beginner with LVOOP, so I'm not sure that dynamic dispatch isn't running another memory instance of the VI.) Can we tap into other QD scripting shortcuts (e.g. Darin.K's add-on for "change to array")? Can we tap into JKI RCF actions (e.g. "wire nodes by corners")? I look forward to thanking you in person for your effort and persistence at some upcoming NI week or CLA Summit! Will pass the word that "LVSpeak is stable" to the others in the office. Very nice work. -Jason