Search the Community

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?

This took a decent amount of debugging and headscratching to figure out why a particular .NET call kept failing. I inadvertently discovered and wired a "vestigial" output terminal that exists on .NET Constructor Nodes in LabVIEW 2012. Interestingly, this output terminal returns the same datatype as the "real" output terminal, yet does not return a valid ref. Pretty sure this is a CAR-able bug, but just documenting behavior here just in case someone else runs into this. (Can you think of possibilities to exploit this as a feature??) Here's a 47sec YouTube video with no sound; Vestigial Terminal at 25sec: ...and for the sake of organic search: Error 1172 - "LabVIEW: A .NET exception occurred in an external assembly. For information about correcting this error, copy the following exception (in bold), and search the Microsoft Developer Network (MSDN) Web site or the Web for a possible explanation." And in case the resolution for this "error" and my "bug" was not clear: I just had to rewire the terminal to the "correct" output. Further, my choice of .NET assembly, constructor and property for the demonstration was arbitrary; this appears to affect all .NET Constructor Nodes.