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.

We often need to let our users select an item from a list. When it comes to making UI elements to achieve this that are a bit more sophisticated than a table, listbox or tree, LabVIEW's current capabilities leave a lot to be desired. Here's an alternative using HTML and CSS. The current example provides an interface for selecting an item from a thumbnail grid, similar to Windows Explorer. Run "Thumbnail Grid .NET Browser.vi" or "Thumbnail Grid ActiveX Browser.vi" from the attached code folder. The .NET version provides a cleaner interface as it provides a bit more control over its behavior. You can select any number of images and any size of the pane (read Web Browser control). You can set any thumbnails as disabled, which will appear grayed out. I have included some images for demo from the Open Icon Library. The code calculates the best grid pattern (the one with the smallest aspect ratio) and generates html code for displaying the images as a table and then generates CSS code for styling the elements. The web browser takes care of the visual effects and LabVIEW maps mouse cursor position to the calculated grid pattern for detecting the selected thumbnail. We could get fancier and use web services to trigger a selection, but that may be an overkill for this case. This approach can be extended to displaying dynamically created tabs or list boxes with bigger symbols than the current 16px limit for list box symbols. I will create examples of these over the next few days. The only issue I've noticed with this approach is that every time we change/refresh the browser, we hear the "Start Navigation" sound that is part of the Explorer shell. It may or may not be OK to disable that in all cases. I guess we can find a clean solution as we experiment more with this code. Thumbnail Grid.zip

I have created a plugin for the Task Manager that can be used from inside an executable, thanks to Michael and his guide to Plug-in Architecture using Packed Project Libraries. If you aren't familiar with PPLs, I'd highly recommend at least a quick glance through this guide. LabVIEW Task Manager Application.zip I took Mike's example and created a plugin that launches the task manager. You can add it to your application as an Easter Egg (set it to load on some secret key combination). You don't have to distribute this plugin with your application, but if you are called to debug something on a deployed system, you can just take this plugin, drop it at the designated place (same as the exe in this example) and enter the key combination to launch it from within the application. To see this in action, launch ..\LabVIEW Task Manager Application\build\testApp.exe. If "LabVIEW Task Manager.lvlibp" exists in the same folder as the exe, your key combination will bring it up.

Because Mark was "trying to create a semi transparent floating line independent of the SFP that the operator can move anywhere on the screen." Plot images are great, but for using the plot image, you'd have to plot the data in that graph and not in just any independent window. Also, you'd still need a way to drag around the green line.

It happens only when I enable multiple instances of my exe using the "allowmultipleinstances=true" attribute in the INI file. If I allow only a single instance, all file open messages from the OS show up in the instance of the application that I have open. So now I have an event structure with the "OS Open Document" and a "Timeout" in my main event structure's Timeout case. For what it is worth, it is working fine.

You could also use the channel properties to store the index and t0 for each segment. That way you have a single channel but you can read individual segments, as needed.

If you can fit the subpanel to pane, it shouldn't be a problem. If you can not, can you put a transparent tab control (fit to pane) behind the subpanel and use the menu activation of the tab instead?

Here's a solution to fix the finicky dragging. Instead of trying to make the window a certain size and dragging it around, just drop a graph control and make everything transparent, but leave a green cursor. The image below shows the cursor overlaid over an Excel graph. The cursor makes the dragging really smooth. If the graph is set to fit to pane and the window set to maximized, I think you'll get the behavior you are looking for.

Like most other such weird issues, the application worked fine for a few days after I first built it, but (I don't know what happened and..) now it consistently displays this behavior. I'll try it out on other computers and share the experience.

Sorry about the lack of clarity in the earlier post. I tried to open only 1 file. If I had selected 50-60 files, tried to open them and the OS opened them, that would be the intended behavior that one wouldn't complain about.

You won't need to click twice to change the value if you position the ring on mouse move rather than mouse click. You can track the mouse and re-position the ring only when the cell changes. If the ring appears on a cell on "mouse over", it will give the user a hint that he can click on it to select a value from a list.