Leaderboard

Please don't do this. The fact that LabVIEW allows "Use Default If Unwired" on conditional disable structures continues to cause all sorts of problems, problems of such complexity that various people are pushing to mutate that feature away in future versions. A block diagram constant of a reference type is ALWAYS "not a refnum". Just use that. If you're interested in the kinds of problems, here's just one for a sample: You have a disabled diagram structure with three frames, as shown below: You save the VI and close it. Later, you load this VI back into memory, but this time, someone has edited the subVI to have a different output type. When LV checks the types of terminals of this diagram, this time it decides that the output type needs to be the new type, which causes your diagram to break. That's a problem since the whole point of diag disable is supposed to isolate your code from the possibly broken code inside the structure. Similarly, if the subVI is missing, LabVIEW will use the third case to determine the tunnel's type, and the output would turn to double instead of string. This is one of the easy cases. They get much more bizzare and it is all the fault of "Use Default If Unwired".

Yes, I believe the variant bordernodes treat errors in the same way (for the same reason as DVRs). No, I don't think it makes any difference on LabVIEW's side which error-out terminal you wire. All things being equal, I'd recommend using the one inside the structure if you are doing something inside the structure, and the one outside the IPE structure if you are just merging the error (or presumably the warning) from outside. Each bordernode (whether data value reference or other) on the IPE structure acts independently (with the exception of order of execution which is ordered to prevent deadlocks). Thus, each pair of bordernodes generates a single, unique error which may or may not be handled. If you wire one pair of bordernodes, but not the error terminals for the other pair, you could trigger auto error handling. Each read/write pair can generate its own errors depending on the state of THAT reference. Since any number of bordernodes could be present, as well as any number of calculations could be done inside the IPE structure, we do not "fail" out on the IPE. If a data value reference has an error accessing the reference (a fail other than just a wait until the lock is available), a default value is placed on the de-referenced wire. All other calculations in the IPE are performed as usual and we simply discard the value wired to the write/unlock bordernode for the DVR with an error. If you are doing a calculation that takes time or referencing a data value reference that is likely to fail, I highly recommend putting a case structure inside the IPE and act according to whether the border nodes have an error. Actually, this is part of why we don't have an error-in terminal on the bordernodes, because even if they individually fail, the structure continues. Forcing one of them to "take a fall" because of an external error didn't seem to be the appropriate behavior.

Hi MikaelH, I managed to use labXML to access the XMI file and, with François tip, class API to include the controls in class private data. It was necessary to do as you said (see my post in Code repository). Thanks for you offer and help but I need to "write" the the code to my graduation work.