What do you propose to do with this? Why wouldn't you just add Error In and Error out on the connectors like you can do now? How do you want your VI's to handle this new Error connector (ignore and pass through, don't execute if there is an error, something else?)
I am proposing to eliminate Error In and Error out controls on front panel and use VI properties as replacement. But you still can use it old way, but makes life easier on large apps because you adding the same controls to all subVI's
You still have to define what you want the VI to do when there is an error, run anyway (like a lot of Close File, Close reference, Destroy Queue functions) or skip and not run (like most other functions).
For large apps, just make a template VI that already has the Error In, Error out and Error case structure so that you don't have to keep doing it for a new VI.
No it is not about templates, try to think outside box...
Key element here is about being able to add error input/output to any LabVIEW function/VI without sacrificing existing connectors (How many times you caught yourself trying to synchronize some VI’s with other process just by adding error cluster through the VI, like adding error inputs/outputs to Delay function…).
I think error cluster is the most common data stream and can be built-in into any VI as property. (While retaining the compatibility with existing code, you can always create control and indicators on front panel).
It would be nice to have an error cluster inputs on bottom corners (thus not interfering with default connectors patterns) and VI reference (optional, or use specified) on top coners.
Now inside block diagram you can access to the error cluster either from built-in error constant (linked to VI property) or via property node. As far error handling, it can be done with options as merge errors or ignore and still keeping separation between error cluster for VI server calls( methods/properties) and use programming (new proposed function).
In my opinion, this option would help in many cases and provided links are just easy to follow examples.
(Now if you start thinking about options like dynamic calling and by reference, and being able to get access to error cluster (common controls) directly, not to mention real estate saving and memory associated with controls themselves)
To be honest, I fail to see how this would improve programming. It doesn't add anything that isn't already there. It sounds like your major complaint is that the error in/out "force" you to use terminals. And, as noted, the error wire was never intended to be used as a synchronization/execution flow tool. It's a data type. If we ask this question from the perspective of other programming languages, you're basically asking a C function to have these "magic" inputs and outputs dynamically. That just doesn't sound right to me.
While I can see you like this idea, and I strongly suggest that you fight for what you believe, at the moment, I can't really support it. Convince me otherwise.
I disagree. I don't think it has anything whatsoever to do with the VI Property dialog. It is an input or an output. A VI doesn't need to have error clusters or control references in order to work, and I think this unnecessarily complicates LabVIEW.
But, I may be wrong, and if your idea gets a lot of votes, I hope it gets implemented, regardless of my opinion.
Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.