Hidden terminals on the .NET Constructor Node?

[LogMAN]

So this just happened to me and I'm quite confused by it. As it turns out, the .NET Constructor Node not only provides terminals for error in, error out and the reference, but actually two more "hidden" terminals:

Notice: I left the error terminals untouched and none of the wires are connected (try it yourself). This never occurred to me. Only now, while hunting a null reference exception I found the constructor node looked "off", like this:

The strange part is that the terminal doesn't actually carry the reference (which is why I receive the null exception). It only specifies the type. The upper left terminal is a void type input, so the wire is always broken.

Does anyone know why these extra terminals exist? They don't seem to be part of the specification as far as I can tell.

Any fancy things we can do with this?

[Darren]

I'm not sure how you got into this state, I don't see the hidden terminals in scripting. And if you delete those wires, there's no way to get back to the hidden terminals. Also, I got a DWarn when I copied your snippet into my diagram. So I'd chalk this up to some weird corner case/corruption and move on.

[LogMAN]

Thanks for looking into this Darren!

On my machine these terminals are permanently available even after a reboot and with a new VI. I just removed all VIPM packages and cleared the compiled object cache, restarted LV and still can connect those terminals. Also tested this on a different machine and got the same terminals.

14 hours ago, Darren said:

Also, I got a DWarn when I copied your snippet into my diagram

This is a very bad sign indeed, I don't see any warning whatsoever. This means it's either a bug in this particular version of LV [15.0.1f10 (32-bit)] or my installation is majorly broken somehow. Not sure what could have caused it though.

14 hours ago, Darren said:

So I'd chalk this up to some weird corner case/corruption and move on.

Unfortunately I can't do that. My application builds perfectly fine (no broken arrow, no exception, no error) while connected to the wrong output terminal. This could potentially be harmful if it somehow effects memory. I'll check if this is still an issue with the latest (f12) or one of the previous patches.

Edited August 31, 2018 by LogMAN

[JKSH]

@LogMAN What happens if you load the project in a different dev machine?

[LogMAN]

Okay, I just finished testing on various machines (virtual an non-virtual) with various LV versions and all of them support this feature! It is very unlikely that we somehow broke all machines and versions in our department for the past 15 years exactly the same way (although there is always a chance ). Find attached more snippets for all versions I checked (for 7.1 and 8.6.1 I had to take screenshots). I've also attached the VI for LV2017. So, in total I've positively tested these versions:

• 7.1
• 8.6.1
• 2009
• 2011
• 2013
• 2015
• 2017

Unfortunately I currently don't have a 2018 Installation to check.

34 minutes ago, JKSH said:

What happens if you load the project in a different dev machine?

It works just fine. We can load, edit, build and execute the project and all executables.

15 hours ago, Darren said:

Also, I got a DWarn when I copied your snippet into my diagram

Darren, which version of LV have you been using at that time? Could this possibly have been changed in LV2018?

Constructor Terminals LV2017.vi

[Neil Pate]

LogMan, I have tried your 2017 version and I get the same issue you reported.

Starting a fresh VI in 2015 and dropping down a random .net constructor I am also able to wire up to those invisible terminals. Curiouser and Couriouser!

[TomOrr0W]

I can confirm this with LV2009 (32-bit) and LV2018 f1 (32-bit).  This is from fresh vis, not copying one of the snippets in the thread.

For Darren, if you try to wire from the constructor, you cannot find the terminals.  It is only if you create another object and try to wire it to the constructor that you can connect to the terminals (or if you try to wire one of the other terminals on the constructor to the hidden ones).  Also, their vertical location is in the center of the constructor, so if you are trying to connect to the top, it will appear that they don't exist.

[Darren]

1 hour ago, Tom O said:

For Darren, if you try to wire from the constructor, you cannot find the terminals.  It is only if you create another object and try to wire it to the constructor that you can connect to the terminals (or if you try to wire one of the other terminals on the constructor to the hidden ones).  Also, their vertical location is in the center of the constructor, so if you are trying to connect to the top, it will appear that they don't exist.

Ah, there's the piece I was missing. Thanks for those details.

I have filed CAR 711518 on this issue. I agree that it is a significant usability concern that it is so easy to wire to that null reference terminal, have code that doesn't function correctly, and not have an indication as to why.

[LogMAN]

Thanks everyone! It's good to know I'm not (yet) going insane

Sorry for not mentioning how reproduce the issue in the first place. I suppose one reason this never occurs to anyone is because we all start wiring from the Constructor Node for obvious reasons, except sometimes we don't.

3 hours ago, Darren said:

I have filed CAR 711518 on this issue. I agree that it is a significant usability concern that it is so easy to wire to that null reference terminal, have code that doesn't function correctly, and not have an indication as to why.

Awesome, thanks for sharing!

I'll inform my team to keep this in mind.

[LogMAN]

@Darren Would you be interested in adding another detail to the CAR?

Just for fun I went to see if I can break other nodes and actually got strange behavior from the Call Library Function Node in a very similar way (using LV2017). You can connect the "path" terminals, even if the option "Specify path on diagram" is not checked. I understand that this is probably a design choice to prevent wires from vanishing when unchecking this option and it doesn't do any harm, but the wire should break. Unfortunately, the output wire doesn't break initially:

Notice: I just placed the node and connected the wires. The options dialog is open to show the checkbox is actually not checked.

Here is what I get after pressing the "OK" button on the dialog (you don't have to change any settings for this to work). You can see the wire is now broken, as it should be:

This is only a cosmetic problem because the function breaks as soon as you press the "OK" button. The behavior is strange nonetheless.

[_Mike_]

I can also report similar behavior. What is more - by complete random choice of constructor - I have got a I32 output rather than reference. 

 

[LogMAN]

Thanks for reporting @_Mike_

Turns out the terminal adjusts to the object type (object or enum). In your case the Constructor is for an enum type, so it actually returns an enum instead of a reference. Here is another example:

This is the corresponding definition according to Visual Studio:

Very interesting behavior indeed.

[LogMAN]

If anyone is interested in finding incorrectly connected Constructors automatically, here is a VI that will do that for you:

It's not very fast, but it does its job. The result is a list of VIs with the total number of Constructor Nodes found and the number of Constructor Nodes where the first terminal ("new reference") isn't connected. This is an indirect solution because the offending terminal officially doesn't exist (not accessible via scripting).