Darren

1 hour ago, Jordan Kuehn said:

Is the LMH-LINX toolkit also included with LV2020CE?

As far as I know, yes.

16 minutes ago, Michael Aivaliotis said:

The reason why the log message states Raspberry Pi 2 B (I stated elsewhere), is because the LINX toolkit has an old hardcoded message internally that does not trigger off the actual board model. @Darren, this should be fixed becasue it's confusing.

I filed Bug 1039468 on this issue.

Here's the relevant NI Forums thread on this topic: https://forums.ni.com/t5/LabVIEW/New-LabVIEW-2019-Feature-Create-Constant-Create-Control-and/td-p/3933878

Come at me, bro.

LabVIEW 2020 Community Edition includes the LINX Toolkit. Do not install LINX from VIPM or anywhere else. I've suggested they edit the Digilent LINX Toolkit description to mention this.

What versions of LabVIEW and the LINX Toolkit are you using/installing?

There is a different API for Installer Builder. It is also not officially supported by NI, but there are a couple of examples that ship with the API to help you learn how to use it:

[LabVIEW 20xx]\vi.lib\InstallerBuilder\examples

Aww man, I loved my HP 48GX. Bought it in high school. Sold it after college because I needed the money. I still have my HP 32SII, which is the best non-graphing calculator I've ever owned.

I know @Fab still uses an HP 48, she probably knows how to convert degrees to radians.

I feel like I've exported data from DETT before, but it's been a long time since I've used it, I don't remember any details. Hopefully somebody else reading this has more info.

That manual is for the Real-Time Execution Trace Toolkit, which I believe has been deprecated. 

To my knowledge, the Desktop Execution Trace Toolkit has never included this functionality.

9 hours ago, Neil Pate said:

Especially interesting is your change to the menu ordering for clean up wire, I have been trying to remember this one for nearly a year now! (I know I can turn it off but eventually I will be using only greater than 2019 so I may as well get used to it)

I was already used to it because I used this right-click plugin from LabVIEW 2015 until the feature was added natively in LabVIEW 2019.

Also, for cleaning up wires, I find selecting one or more wires and pressing Ctrl-U to be faster than right-clicking each single wire and selecting Clean Up Wire.

I think @Aristos Queue added that in LabVIEW 2019.

1 hour ago, hooovahh said:

Any idea what the licensing restrictions are?  I couldn't find anything about that other than it is open source with no specifics.

No idea, I just saw "All of the icons are free for both personal and commercial use" on the main page, with no mention of including license info.
 

Oops, looks like I missed when this feature went in. As AristosQueue mentioned in a reply to your Idea Exchange post, you can use the Dependencies > Missing Dependency Names and Dependencies > Missing Dependency Paths properties of the GObject class in LabVIEW 2015 and later. Can you verify that these properties give you want you need, and I'll close out the Idea Exchange post as Already Implemented?

Unfortunately there is currently (as of LabVIEW 2019) no comparable functionality to the Missing VI Name/Missing VI Path from subVIs for typedefs, nor is this functionality going to be in LabVIEW 2020. I suggest posting this request on the LabVIEW Idea Exchange. It would be a useful feature for tooling like what you've described.

19 minutes ago, Porter said:

Are you talking about right click during edit time or during runtime?

Does this explain the random right click of doom that freezes LabVIEW after right clicking on an item in project explorer?

He's talking about edit-time panel and diagram menus and run-time diagram menus that are implemented as right-click plugins.

This bug fix does not affect right-clicks in the project window.

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.