Darren

That won't work if the probe VI doesn't update its FP until called again.

I tried it, and the probe UI will update when the Fire and Forget VI runs, even if the probe itself is idle. I saw my probe happily incrementing while its owning VI was idle.

The biggest snag will be figuring out how to stop the Fire and Forget VI. It continues running even after the probe UI is closed.

This is the approach that I've seen taken for this issue...you have to do all the work you would normally do in the NI.LV.Dialog app instance in the app instance that owns the VI from which you launched the Tools utility:

Here's a Quick Drop shortcut that will do a recursive typedef disconnection:

https://decibel.ni.com/content/docs/DOC-37041

I am not aware of a way to script a dotted property. It's been one of my top requests for scripting for years now, because of how frequently I use the Ctrl-Shift-B shortcut in Quick Drop to rename a property/invoke node...I can't set "Label.Text", and it drives me crazy!

Note to self: lob softballs at AQ's inbox early in the day, so he'll be happy when I ask him tougher questions later. 

Got it.

Feel free to send some sample code to the AEs so they can file the necessary CARs.

Yeah, I can't think of anything else to try. There very well may be a bug with setting key focus on an array element in a floating VI window.

I am not seeing a way to get the key focus to always go to the first element (as opposed to going to the last one that was clicked).

I'm also not aware of any documentation on these particular array idiosyncrasies.

You need the panel activation if you're running the VI from somewhere other than the panel. For example, if you're on the diagram and you press Ctrl-R, the key focus doesn't take.

First you need to activate the panel. Once you do that, you can set key focus of the array element and it will work.

Unfortunately, the Class Browser (both incarnations...the one you describe, and the one you see when you press Ctrl-Shift-B) is not implemented in G.

The GetType.llb VIs were added in LabVIEW 7.0, and they were used to parse the legacy I16 Array type descriptors. 

The VariantDataType VIs were added in LabVIEW 8.0, when we switched to using Variants to define data types instead of I16 Arrays. At this time, the internals of the old GetType.llb VIs were updated to use Variants as well.

So there's no need to use the VIs in GetType.llb. They are deprecated. And it's a little late in the game, but we are planning on marking them as deprecated in a future LabVIEW version.

This Quick Drop shortcut shows how to do it on Windows (you use the "/select" parameter), but I'd like to know if there's a way to do it on Mac/Linux:

https://decibel.ni.com/content/docs/DOC-22461

My favorite will always be Arilou...it's been my ship of choice ever since Star Control 1.

Those buggers cannot be all facing the same direction, that ship was way too slippery to control.

I didn't realize until a few years ago that pressing the thrust key on Slylandro made him immediately switch directions 180 degrees. Turns out to be a great tactical move for attacks with quick escapes.

To whet your appetite, have many Slylandros!

*Energize* indeed!

Let me know once you've got Slylandro working...the World's Fastest LabVIEW Programmer needs to be able to fly the World's Fastest LabVIEW Star Control 2 Ship.

I will have to build an example when I have some time.  The app where this is happening is way to big to post.

Ok, when you get around to it, you can either PM me the example, or post it to forums.ni.com for an AE to take care of.

Now if I could just get mouse leave events to consistently fire before mouse enter events for adjacent controls, I would be a happy camper...

Assuming both of these controls have the same owner, if you're seeing Mouse Enter before Mouse Leave, that sounds like a bug. Can you post a VI that demonstrates the issue?

The mouse move to 'disarm' the sort between a mouse down and mouse up did the trick.

Yeah, that is a simpler way to do it, I didn't think of that. The only thing to consider is that if the user is a little sloppy with his mouse (i.e. moves it a pixel or two between mouse down and mouse up), the sort won't trigger. Probably not a big deal, but something to keep in mind.

No problem...it also gave me a chance to plug the fact that the column headers in the Project Find dialog are clickable for sorting in LabVIEW 2013 and later!

I had this exact issue when I added column sorting to the Project Find dialog in LabVIEW 2013. It's cheesy, but the way I handled it was to store off the column widths of the columns on both sides of the mouse down whenever the Mouse Down event occurred:

And then on Mouse Up, if I found that the column widths were different, I conclude that it's a column resize, and I don't do the sort:

Any plans for a new platform independent VI to do the action this VI used to do?

No plans at this time. I think your best bet is to have a VI that calls Open URL in Default Browser.vi on non-Windows, and makes a call to System Exec.vi (like in hooovahh's VI) on Windows.

Is it possible to copy the VI from a previous version, rename it to "Open File in Default Program" and then use it in 2014?

I don't think so, because I think the internal LV callback is what changed, I don't think the VI changed at all.

From what I can tell, we changed the VI to really open all files and URLs in the default browser in 2014. The change was made to support file-based URLs with "#" tags in them...prior to 2014, this part of the URL would be ignored, which was filed as CAR 420007. Fixing this CAR meant making the VI actually do what its name implies, always opening a file or URL in the default browser.

I don't think that is a G-based dialog.