Type Specialization Structure Error Message

[IlluminatedG]

VIMs are awesome but when wire inputs are broken they aren't awesome. They'd be awesomer if there was a way to specify that when specific frames of type specialization structures are active, there is a way to get specific strings added to the error info for the caller. Having a way to add custom strings to VIMs would overcome the general "An unsupported data type is wired to this subVI node." error string we're currently given. This can also help differentiate between LabVIEW breaking during type prop for odd (bug) reasons and properly invalid inputs... Do I need to just delete a wire and re-wire the input or do I need to hope the developer provided good VI documentation?

With some additional frames in Type Specialization Structures and maybe something like a subdiagram label but instead it could be a error reporting field at the bottom of a frame, it would be much easier to provide meaningful information back to a developer such as "GUID input only accepts GUID.ctl or a String". Then if the caller breaks with the unsupported data type error for the VIM, error details from the currently active TSSs can be concatenated to the Details string displayed in the Error list dialog. Alternatively, each error message found in TSSs could be separately listed in the Error list.

My 10 second idea:

 Resulting in the Error list perhaps showing it as either an error or concatenated into the Details:

[raphschru]

I also think that the potential of malleable VIs is way underrated and that we are missing some basic "malleable arithmetic" functions.

For your use case it could be:

A function called "Break Diagram" that unconditionally breaks any diagram it is into.
Also a constant string could be wired to have a custom edit-time error.

Maybe an XNode would allow to do that...

[wiebe@CARYA]

>A function called "Break Diagram" that unconditionally breaks any diagram it is into.
Also a constant string could be wired to have a custom edit-time error.

@raphschru:

Your post made me understand this idea, so thanks.

Your solution has a problem... You suggest to use a function (that is called with a string value) in a VI that can't be compiled and thus not executable. It would be possible to (if the VI doesn't compile) searches the BD for that function and it's wired constant with scripting. But that will get hard if something else is wired, not a constant but string function(s). The VI doesn't execute, so how would LV know the string value going into the function?

[wiebe@CARYA]

I'm still a bit confused about the idea in general.

Both OPs as @raphschru's example show the error in the case that does compile (Accepted), and in that situation the error is not used.

If there are 10 cases, and none compiles, which error should be displayed? They all fail, so which case's error is used?

I do agree it would be neat if we could control the VIM's error message.

[raphschru]

---

@wiebe@CARYA wrote:

You suggest to use a function (...) in a VI that can't be compiled and thus not executable

---

...which is the purpose of using a "Break Diagram" function: telling the developer that something is wrong in his code.

---

@wiebe@CARYA wrote:

But that will get hard if something else is wired, not a constant but string function(s). The VI doesn't execute, so how would LV know the string value going into the function?

---

The same way that constant format string is detected for "Format Into String" or "Scan From String" functions, by looking at the constant directly wired to the terminal. In case no constant is directly wired, you would have the default behaviour (no custom error).

---

@wiebe@CARYA wrote:

Both OPs as @raphschru's example show the error in the case that does compile (Accepted), and in that situation the error is not used.

If there are 10 cases, and none compiles, which error should be displayed? They all fail, so which case's error is used?

---

When none of the cases of a Type Specialization Structure compile, the last one is always "Accepted", so we would have the custom error specified in this last case.

Too bad we cannot attach any file in the idea exchange, so here are some screenshots on how I would use this "Break Diagram" function. In this example I implemented a VIM that normalizes a GUID into its U32 format. Notice the trick I used in case 3 to force the wire breaking:

VIM, input is a U32, case [0] is "Accepted":

VIM, input is a string, case [1] is "Accepted":

VIM, input is a double, case [2] has a broken diagram but is "Accepted" because there are no other cases left:

Test VI:

[raphschru]

Another possible design, similar to the Error Ring XNode, eliminating the "constant-must-be-wired" complication and allowing to provide more details about the error:

Diagram of the VIM:

Configuration dialog for the "Break Diagram" function:

Also, the caller of the VIM would not have the 2 generic errors:

...but rather the single custom error instead:

[wiebe@CARYA]

I see merit in the XNode solution...

The way format into string handles this is rare, and I don't see that happening again. Although I wouldn't mind the concept of constant expressions, that might make that easier, but won't happen anytime soon.

Still room for questions. For instance:

What if there are multiple type specialization structures?

What if there are nested type specialization structures?

What if there is no type specialization structure?

Don't we want a detailed error for any vim, not just those with type specialization structure(s)?

These make me think an error message for the vim needs to be block diagram scope, not type specialization structures scope? Or like a VI description, in VI Properties, that is shown on error.

[Hooovahh]

These are all great ideas.  In the past I've always referred the VIMs documentation to try to figure out why it was broken, and what kinds of inputs are supported.  A broken run arrow with detailed help would be more useful.  I'm not sure how many people are going to put the effort into using the feature, but that's on the developer.

[raphschru]

The way I imagine this "Break Diagram" function is that it would be completely unrelated to the use of Type Specialization Structures or even Malleable VIs.

It just breaks its owning diagram with a custom error, and if it happens to be in a top-level diagram or inside an enabled subdiagram of any type of structure, the diagram error is detected by the compiler and breaks the owning VI (and thus its entire call hierarchy).

The custom error would show up in the error list associated to the owner VI that is broken by the "Break Diagram" node.

In case the error occurs because a caller has wired bad types to a Malleable subVI (causing an internal Type Specialization Structure to enable a "Break Diagram" node), the error would naturally bubble up to the caller VI instead of the Malleable VI, because everything inside a VIM instance is considered part of the calling VI.

[wiebe@CARYA]

>the diagram error is detected by the compiler and breaks the owning VI (and thus its entire call hierarchy).

That's where I disagree.

I would say: if the VI breaks for whatever reason, get the error from the 'error string' (in an XNode, VI Property or whatever, anywhere on the diagram or in the VI) and display it.

That might seem like a subtle difference, but it will be much easier to make. There just isn't a proper way to let a function break the diagram at compile time and still get an input string that is wired to it and do something with it. I agree that the Format into String does that, but I just don't see it happening. I wander if the result will be better.

I'll kudo the idea, the actual implementation can be figured out, there are options.

[IlluminatedG]

I'm definitely in favor of a node that can be put where the problem is. If it's active then that's the error that displays. And it can be done with XNodes right now without LabVIEW editor/runtime changes.

For me that's the winner over *only* a top-level entity that provides an error if there are any other errors. I'm looking for specificity here. If I've got this one input type and that then places specific requirements on other inputs, that'd be pretty hard to specify and capture from the outside. Something like "When Input is an integer, the divisor must also be an integer" but if you wired a floating point up as Input, it would allow any numeric type.

Just a catch-all message isn't any different than a line in VI docs that says "if broken, here's your error message". I want to be able to specify as best as possible what the issue is given the types currently wired in otherwise there's no further assistance to the users above already available techniques (assuming they have context help open)