LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Mike_King

Support parameterized error strings in external project error-code files

The error ring control is awesome having its parameterized input strings which supprots things like %s, %d, and %f to customize your error string.  This is not supported by the error ring when you are defining the string in an external project erorr code file however, and that is a problem since you then can't localize for multi language from external files.

 

This idea is to add parametrized inputs to the error ring for ALL errors, custom or loaded from project resource files.

 

see screenshot below.

error ring.jpg

8 Comments
AristosQueue (NI)
NI Employee (retired)

Speaking as the author of the Error Ring, all I can say is yes, I'd like that too. It won't be in the 2014 release, but I continue to work on it.

QFang
Active Participant

I somehow missed that it can be parametrized (is that a word?) at all! Mind blown!  -though not immidiately useful in a company wide adaptation unless you succeed with your work AristosQueue!  -Good luck!

 

QFang
-------------
CLD LabVIEW 7.1 to 2016
AristosQueue (NI)
NI Employee (retired)

So... I've worked on this a bit and hit a problem.

 

The error code text files aren't "live" source files. LabVIEW doesn't link against them. That means that if an error code text file changes, the block diagram doesn't get notified and so doesn't get a chance to rebuild. And I really didn't want the error ring to have to return an error code saying "I couldn't build your real error."

 

After trying many many variations over several months, I decided that this just wasn't the way to go. I am going to provide a way to have a custom definition with added terminals, but it won't be by embedding % codes in error definitions. The upside of the variation that I am playing with now is that you define your connections via a VI conpane, meaning you can write it to accept any type, not just the types that can be recorded by % codes.

 

For this reason, I'm going to close out this specific idea as "technically infeasible", but I want to assure you that the spirit of the idea -- being able to have a well-defined error that has attached data-type-specific terminals to embed information -- is alive and well.

 

 

Darren
Proven Zealot
Status changed to: Declined
BertMcMahan
Active Participant

Hate to dig up an old thread, but I actually came across this idea just recently. Did the method AQ mentioned ever make it into LabVIEW?

AristosQueue (NI)
NI Employee (retired)

@BertMcMahan : No, it never made it into LabVIEW, but not for lack of trying on my part. I was fighting too much historical code across non-LabVIEW products.

aputman
Trusted Enthusiast

I hate to dig up an old thread as well but this used to work in 2012.  Errors were loaded from a txt file and % codes could be used to customize the error message.

Now when I try to update to 2017, I cannot do this any longer.  Smiley Frustrated

 

2019-08-01_10-33-45.png

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
AristosQueue (NI)
NI Employee (retired)

aputman: Yes. And it caused bugs when those strings changed.