Jump to content

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

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.

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

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

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.

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

  • Similar Content

    • By bartek618
      I know how to run .Net executable by MainWindow() constructor but I have some resources defined in App.xaml and MainWindow() doesn't run without them. How to run application starting with App() constructor? Also I need to pass some parameters into MainWindow().
    • By William Hofmeister
      I need to access Aerotech A3200 data with LabView. The Digital Scope in the A3200 software has the capability to record data at 1kHz for 8 seconds in dedicated batches. We use LabView for all functions surrounding the motion control and have the Aerotech LabView package. Using the LabView vis we can only access data a single data point per call and I don't see how to set up a FIFO to Windows LabView. Someone must have looked at this problem lately. Can anyone steer me in the right direction?  Thanks!!
    • By ATE-ENGE
      Edit: I'm asking primarily if there is a reason why/when I should/shouldn't use .net functions in my LabVIEW development. The example below is just to demonstrate a case of my question.
      _________________________________________________________________________________________________________________________________________________________
       
      I recently found a custom library that calculates SHA256 hash algorithms However, in this post I see that the same thing can be done with .net 
       
      My main question is: Is there any reason to build or use a custom library for something where .net functionality already exists? Are there any disadvantages to offloading work to .net ? 
    • By Gribo
      Hello, I am trying to copy multiple cells in LibreOffice, using the UNO API. I encountered an issue in the XCellRangeData object.
      The object's method returns an array of array of any() type. it seems LV can't compile this, even though the wire appears not to be broken. If I try to parse the array of array into a single dimension and then rebuild, the code is broken. See the attached files. Is there a solution for this issue? The alternative would be to copy cells one by one, which is a much slower solution.


    • By P.Carpentier
      Hi Everyone,
      Most of the time I am able to find solutions to my issues just by reading this forum but I wasn't that lucky this time.
      So, i got an issue when i'm trying to install my build.
      I got the following message: "This distribution is built with an older version of winMIF that is not compatible with .NET 4.6.2 upgrade to 17.0"
      When googling this error message or even "winMIF" i can't find anything that match my request
      I tried to uninstall the .NET framework and then reinstall the 4.0 (and 3.5) and I got the same issue. (Exactly the same error even if it's .NET 4.0 or 3.5 ...)

      The computer used to build is a Win7Pro with Labview 16.
      The target computer is a WES7 (but I got the same issue on my dev computer ...)

      In advance thank you, 

      Piet
×
×
  • Create New...

Important Information

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