Darren

I don't know of a way to do this. The closest thing would be to show the Tools palette with the 'Tools Palette Open' property, then use OS calls (like user32.dll on Windows) to simulate a mouse click to turn the auto tool on/off.

6 hours ago, Yair said:

Darren, any chance of getting the All Supported Properties property of the Property class (i.e. the property node) to actually return all the supported properties for the current class of the property node, including all of the nested ones?

As it is today, that property only returns the top level properties (so it would show a Label property if the node is linked to a class inheriting from Control, but not all the subproperties coming from the Label class).

If that's too hard for support reasons, maybe at least adding a new property which will actually return all of them?

This is a good idea. I suggest posting it to the Idea Exchange.

3 minutes ago, ShaunR said:

Hmm. No 64 bit versions for 2009-2015. Thanks for the info.

Right, VI Analyzer Toolkit 2016 was the first version to officially support 64-bit LabVIEW. For unofficial support in previous versions, we have this resource:
https://forums.ni.com/t5/VI-Analyzer-Enthusiasts/Using-the-VI-Analyzer-Toolkit-with-64-bit-LabVIEW/ta-p/3494395

3 hours ago, ShaunR said:

I've got it in 2019 but not in all the other versions. Is there a separate test install for each version?

Yes, it's a LabVIEW Toolkit, which means you have to install it separately for each LabVIEW you have. Here's the download page where you can get whichever version (and bitness) toolkit installer(s) you need:
https://www.ni.com/en-us/support/downloads/software-products/download.labview-vi-analyzer-toolkit.html

1 hour ago, ShaunR said:

Nice. However this is mine.

The VI Analyzer has core components installed with LabVIEW, like the UI you're seeing. The VI Analyzer Toolkit is a separate install with 90+ tests, including the Complexity Metrics tests. So you need to install the VI Analyzer Toolkit to see the tests.

On 10/17/2019 at 7:56 PM, ShaunR said:

I don't think it does Cyclomatic Complexity Correct if I'm wrong because I rarely use it.

Moderator comment: Continued discussion here.

I'll be there, presenting a regular session and a 7x7.

I've written tools before that involved scripting probes onto wires. The way I facilitated communication between the executing probe and the scripting framework was through a named queue. I could pass the name of the probe VI (which ends up being the name shown in the first column of the Probe Watch Window) to my scripting framework. Meanwhile, my scripting framework had used the "AttachProbe" method of the Wire class to create the probe. This method returns a Probe reference, which you can then use with a property node to read the "ProbeVI" property, which gives you a VI reference, and you can read the VI Name property to match up which Probe VI got attached to which wire.

Note that the "ProbeVI" property is private, so you'll have to do some digging on how to enable private properties/methods if you haven't already. 

You may want to consider using a Data Agnostic Smart Probe instead of a subVI. From that probe, you can get a reference to the calling VI. And I think there are ways to figure out which probes are on which wires, etc.

Here's my nugget post on Data Agnostic Smart Probes: https://forums.ni.com/t5/LabVIEW/Darren-s-Occasional-Nugget-02-23-2018/m-p/3759109

40 minutes ago, JKSH said:

does anyone know whether the new official VIs are just wrappers for the Hidden Gems VIs? Is it OK to keep using the Hidden Gems VIs going forward?

The official VIs are different implementations. I imagine they're faster, since their implementation is simpler (they just wrap Spreadsheet String to Array and Array to Spreadsheet String). Also the new VIs have the standard connector pane and official icons.

You shouldn't have any issue continuing to use the hidden gems if you prefer those.

Just now, Daklu said:

My apologies if I misrepresented what you said.  Can you elaborate on why you recommend against using XControls?

No problem, I just want to make sure people know the difference between "Darren the G programmer says _____" and "Darren the NI employee says _____".

In my "Don't Wait for LabVIEW R&D... Implement Your Own LabVIEW Features!" presentation, after I clarify that I'm presenting my personal opinion and not an official NI position, I contraindicate XControls because of numerous stability issues I've seen with them in large applications over the years. You can see my slides and watch a recording of the presentation here: http://bit.ly/dnattlvhooks 

Side note: I tried to look at the code, but I couldn't manage to get the snippets dragged into a LV 2019 diagram. Is there something special I have to do to download the .pngs so that they have the LV meta data necessary to make the snippet be droppable code?

Variant attributes were optimized quite a bit over the years. For string-based keys, they are very efficient, especially if you don't need to cast to/from variant for the values. 

You don't need to type cast to string when using maps. Change the keys in your Map code to be U64s instead of strings and let's see the benchmarks. Type casting is expensive. One of the benefits of using the map data type is that you no longer are forced to use strings as your keys.

On 5/29/2019 at 10:55 PM, Daklu said:

I am under the impression XControls have more or less been relegated to the rusty nails bin. I know I've seen NI employees recommend against using them in presentations. 

One of those employees is me, but I am always clear when I discuss this topic that my recommendation against XControls is my personal opinion and is not an official NI position.

5 hours ago, LogMAN said:

If I understand you correctly, there is a path like "C:\a\b\c" and you need the "\b\c" in order to use it as "D:\default\b\c", right?

I read it the opposite way, he has c:\a\b\c and just needs c:\a or c:\a\b. In those cases, you would use Strip Path.

Seems like the checkboxes aren't even necessary if you're only picking one class to inherit from. Just pick a row in the tree and click Next.

 

This works, but it uses a private property.

I've added that property to a list I'm maintaining of private properties/methods/events to move to public/scripting in a future LabVIEW release.

I don't think there's a way to do it. You'll need to make your own browse button.

3 hours ago, Neil Pate said:

 

@Darrenhave you got any of the "speedup" keys in your LabVIEW.ini set?

No.

24 minutes ago, flarn2006 said:

Taco deli? 😉

I prefer Torchy's.

2 hours ago, flarn2006 said:

However, strangely, I haven't found any methods/properties that do anything specific to build specifications. Maybe I'm looking in the wrong place though.

Yeah, I'm not aware of any. The App Builder API (vi.lib\AppBuilder\AB_API) provides most of the functionality you would need to programmatically modify build specs. I talk about it briefly in my Hidden Gems presentation: http://www.ni.com/hiddengems

2 hours ago, LogMAN said:

By significantly faster do you mean "fluently" or "stuttering, but not as much as before"?

Here's a GIF comparing the selection drag + scroll speed on the same large VI in 2018 and the latest 2019 build, both on my dev machine.

2 hours ago, LogMAN said:

Send them this VI for reference: https://forums.ni.com/t5/LabVIEW/Very-complicated-labview-block-diagram/td-p/3187507

(standard disclaimer, unreleased software, not an official benchmark, etc. etc.)

I just tested dragging selection boxes on that diagram in LabVIEW 2018 and in the latest LabVIEW 2019 build. Selection rectangles draw significantly faster in 2019. Window scrolling while dragging a selection box is also much faster.

For reference, my dev machine is Win7-64, 16 GB RAM, E5-1650 3.5GHz.

19 hours ago, flarn2006 said:

Does this mean its deprecated status will be removed?

Not in 2019. But we will look into consolidating the API in 2020 so the non-deprecated method is able to set dotted properties like the deprecated property can.