Jump to content
LogMAN

Hidden terminals on the .NET Constructor Node?

Recommended Posts

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:

Constructor has additional terminals.png

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:

Connected to hidden terminal.jpg

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? :D

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by LogMAN

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 :D). 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 LV7.1.png

Constructor Terminals LV8.6.1.png

Constructor Terminals LV2009.png

Constructor Terminals LV2011.png

Constructor Terminals LV2013.png

Constructor Terminals LV2017.png

Constructor Terminals LV2017.vi

Share this post


Link to post
Share on other sites

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!

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

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

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.

Share this post


Link to post
Share on other sites

@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:

Path output wire doesn't break initially.png

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:

Path output wire breaks after unchecking.png

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

Share this post


Link to post
Share on other sites

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

 

Capture.JPG

  • Like 1

Share this post


Link to post
Share on other sites

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:

Enum Type Constructor.png

This is the corresponding definition according to Visual Studio:

Enum Type Constructor - Object Browser.png

Very interesting behavior indeed.

  • Like 1

Share this post


Link to post
Share on other sites

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

Find Disconnected Constructor Nodes.png

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).

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.