Bean

Hey Mikael. That was another function I used but it wasn't working for me. I was setting the hWndInsertAfter parameter to 0 (Places the window at the top of the Z order). However by setting it to -1 and then back to -2. I managed to get the result I needed. :-)

Thanks!

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

using a Cluster Bundle function allows you to wire two event refs into 1.

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

I'll look into it, but it happens to be a command I already built before Darren's shortcut so I've never seen it not work.

It's Darin.K's shortcut (not Darren's) [what's the chance of the 2 guys producing QD shortcuts having the same "name"?]

I call mine pluralize, but I suppose his is more descriptive

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

I just looked at your image though, and you've caught the wrong reference. Unfortunately when debugging you have to be extra careful what is active when you invoke the command. As you have shown is the QEC execute as the active VI, which I assume to not be correct.

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

<br /><br /><br />

Once again, you're spot on.

I've spoken with both Jim and Darren and we're all in agreement (almost)

Each of our frameworks implement the same flow (get input from user -> execute a specific VI), but the specific differences make things a little more complicated (not impossible though) and just need more thought put into.

A great example is that QD has a default user field that people can type into. How does that flow work into QD or LVS?

another example is that RCF has an 'Options' ability and cascaded menus. How does that flow work into QD or LVS?

But before you start to try to answer those questions (already have some thoughts on it) realize this;

LVSpeak is not 'just' a speech recognition engine... well technically it is, but the LVS package also includes Quick Edit.

IMHO: Quick Edit is intended to be this central unifying engine that enables users to invoke a VI through whatever mean they so choose (speech, QuickDrop typing, right clicking). Because of it's plug-in and object oriented approach each of these enabling technologies can take advantage of it in the same manner that LVS has.

This does not mean that it has all capabilities ready to rock and roll to ensure no loss of functionality for the other methods, but at the heart of the issue QD shortcuts are a hack on the QD window. And RCF, although very feature rich, has the meat of the code that does the work 'very' tightly integrated within the framework.

So what is needed (and I feel QD as is, is a good step in this direction) is an engine that JoeLVUser can tap into to execute VIs to help his development, Scripting, ordering pizza, or just dropping structure.

Would you agree with this from what you've seen?

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

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

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

You are indeed correct and apparently in phase and frequency locked with the way my brain is spinning. Well done.

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.

Making one for QD will be pretty darn easy. RCF I imagine will be much more difficult because of determining if/how we can circumvent the framework and just execute the needed code. At this point, it's a time and resource issue for me. But it needs to be done at some point so we can converge our methodologies.

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

What will need to happen is that either I make a generic plug-in for all QuickDrop shortcuts that addresses this first. or make a sub-class of QEC Command that is specific for QD shortcuts, that all QD shortcut LVS implementations use.

Thoughts?

Did you try the fix?

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

Jason, I'm really excited that you've taken to LVSpeak the way I hoped many would.

To address the questions you have, I've noticed the way remove and re-wire behaves, but hadn't taken the time to fully debug myself (not often used by myself). But the way you would debug is to invoke the command "Show Quick Edit" or right click the notification tray and use that same right click option. once open you should be able to put a breakpoint right before the dynamic dispatch call 'Execute QEC Command'. Once the program breaks at that point, 'step into' the QEC command and it should dispatch you to the BD of remove and rewire. You have to take this convoluted route because Quick Edit operates in the NI.LV.Editor context and the only way to debug in these contexts is to hack into a VI in non-traditional ways. Ideally, I should put some debugging code in there that properly reports any errors of a variety of styles.

WRT other editor assistants like QD shortcuts and JKI RCF plugins, you most definitely can tap into their IP. For QD Shortcuts, the process is as simple as making a new plugin that calls the QD shortcut VI like for remove and rewire and assigning it a speech command. Ideally, I would create a plugin that just scans that directory and assigns names based on one of their properties

For RCF, the process is a bit more involved, because there is not 1 predefined VI that the action code exists in. So you need to open the plugins, find the needed code in their framwork, and then plop that into the appropriate case for the Execute QEC command.

I'm not sure if all of that made sense to you, but please ping me back w/ other concerns or findings while you debug.

-Norm

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

Norm,

I don't want you to spend a lot of time on this; I just wanted to to know if this problem ever came up. I'm having trouble getting the "remove and rewire" to work. As far as I know this is the only command that calls the quick drop shortcut. I'm trying to reproduce the same example that you showed in the video (replacing the property node) but it doesn't work. LV Speak recognises the command buy the property node doesn't get removed. Also I noticed that the Execute QEC.vi for the Replace command was the only VI in the plugins package that was flagged as needing recompiled (you know, has the * in the title indicating a change needed saved). I'm not sure if that points to the problem or not. Anyway if you had any ideas I could try that would be helpful.

Thanks,

John

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