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 would prefer the custom error to only show if the owning diagram of the "Break Diagram" node is enabled, which offers more control on the errors generated.

This way in your VIM you could have several TSSs with each its own custom error in the last case.

So your VIM could generate 0, 1 or several diagram errors depending on the state of the TSSs (which depend on the wired inputs).

XNodes allow to generate custom diagram errors, but unfortunately as far as I know they cannot be put in a VIM because they are not inlineable... too bad ! @Hooovahh am I correct?

[IlluminatedG]

oh, phooey. Yeah XNodes break VIMs.

[IlluminatedG]

Wait, not completely true because error rings are allowed so there's some trickery there that surely could work for this kind of node that only has a string input.

[IlluminatedG]

I'll poke around and prototype an XNode this weekend for this and see what I can come up with if I can figure out what's enabled in Error Rings to allow them.

[wiebe@CARYA]

Inlining isn't a problem in a vim, you can nest them and they are inlined (use a vim in a vim).

I don't have a problem placing an error ring or inline VI in a vim...

Some XNodes might have property nodes or CFLN in the generated code, and those are not allowed in an inlined VI (incl. vim).

[raphschru]

The Error Ring is hardcoded in the compiler to be inlineable, check the explanation from @AristosQueue in the LAVAG forum: https://lavag.org/topic/20315-xnodes-prevent-inlining/?do=findComment&comment=123467

But other XNodes (especially the ones you make) are automatically not inlineable. It appears to be because the generated code inside the XNode itself cannot be garanteed to be inlineable.

This is really too bad, especially because the "malleable arithmetic" nodes that we could create don't even need a generated code... only edit-time type checking and error generation. If only there could be a way to say that an XNode does not have any block diagram, so that it would obviously be inlineable.

[Hooovahh]

Yeah I've avoided XNodes and VIMs combining.  I've also avoided XNodes and Classes combining too.  I don't think there are hard rules against them, just various usability issues that make developing them very hard, or impossible.  And it is hard to know what you can't do, until you try it.  An officially supported feature from NI would be the way to go.  More control over the error in a broken arrow dialog could be its own separate idea too.

[rtollert]

Oh! I was actually talking about this with AQ a year ago. I think there is a clear analogy here between this sort of idea and C++ concepts.

Now, how to localize it... 🤔