Ravi Beniwal

Hi Eric, There is no problem with multiple runtime engine versions. They coexist and work well. Ravi

That was a great presentation and certainly a great tool. Thanks!

Thank you all for putting in all this effort in finding a solution to this issue. My computer will certainly see fewer "gestures" now! Justin, thanks for the detailed instructions

This might work. Multidimensional image data array.vi

Hi SJ_Buddy, I haven't done anything in 2013 yet. I will try to upgrade it over the next few days.

Hi Darin, Can you please post an example of using the VI Activation event? I can't seem to find it. Is it one of those hidden features that one may be just lucky enough to stumble upon?

If you just need to select one of the palette options based on external triggers, you can use the Palette:Active Tool property. In addition to, or in lieu of this, if you also want to zoom in to a specific range, you can use the scale range properties.

Is that how LabVIEW closes the palettes? It is not practical to put the burden on every VI that has an open window for announcing the "active window" state to any random floating window. We could get a list of all VIs with open FPs and let the floating window register for a mouse down event or periodically cycle through the open windows to see if any of them changed their active state. But it will take a while to get all VIs in memory, open references to each one of them and see if their FP is open. We will have to do this every time the floating is opened. Is their a trick to quickly get a list of all VIs with open FPs or will that have to be a feature suggestion?

How do you determine that it is time for this floating window to close because the user clicked on the host or any other window, just like the LV palettes? For a floating window, we can't check for "is foremost" to see if some user action made this window NOT Foremost.

Sure. One way to do this is by using user events. So the VI with the on screen keyboard creates a user event that any other VI can register for. The keyboard VI will get the user input by looking for value change on the keyboard buttons. If the user uses the physical keyboard, you could use the key down event to read the key stroke (and briefly depress the corresponding key on your virtual keyboard). In either case, since you know which key the user intended to press, you can fire the user event with the details. Any other VI can register for and get this user event.

Can you divulge a bit more about your architecture? How are the messages consumed? Are you planning to "read" the command from the message class and then run some code in a case structure or do you want to use some form of dynamic dispatching within your DUT class hierarchy?

Here are the VIs saved for 2009. Please note that this is just a quick example to show the functionality, which is why the KeyLogger is launching VI1 (and is only displaying the keystrokes and not logging them). For your real KeyLogger, you will need to use some methods to find out which VIs are in memory and open references to them (may be register for events if the FP is open). You could use "Application:All VIs in Memory" property every now and then to see if new VIs have been launched. KeyLogger.vi VI1.vi

Hi Nicola, just to make sure I understand this correctly, you want two VIs with the following functions: VI1: Is (part of) the UI. VI2: Is a keylogger. It gets some reference to VI1 and then log any keystrokes that VI1 receives. Please see the attached files. Run KeyLogger.VI, which will launch VI1.vi and register for its keystrokes. KeyLogger.vi VI1.vi

Ah, I totally missed that. It is a neat trick!

Hi hooovahh, thanks for adding the test cases. I did test resize event handling and then noticed the same issues that you did. Since we are generating a new html document and loading it in the browser every time the size changes, it was really slow and the clicks were annoying. For handling panel resize event, while still doing most of this stuff in LabVIEW, I would rather refresh in a separate loop and use lossy enqueue to a single element queue to pass on the panel resize message so that we don't refresh for every single resize event LabVIEW fires. Ideally, we should resize the thumbnails using JavaScript onresize event and calculate the thumbnail sizes within JavaScript, not in LabVIEW. Yair has lots of munitions on that. May be we can put together a quick example.