Add ON/OFF and YES/NO to Boolean text outputs from "Build Text" Express VI

[Jeff_Long]

The "build text" express VI could be more useful if it included the conversion of Booleans to ON/OFF and YES/NO, and maybe even OPEN/CLOSE in addition to the existing TRUE/FALSE and 1/0 options. 

I like the way the Express VI makes my block diagram simple and very readable due the the %parameter name% aliasing format, but having more options would help my VIs to be even better.

For instance, if I'm using a string to transfer a valve state to a valve actuation case in a queued message handler, it would be better to send it as "ValveControl:OPEN" instead of "ValveControl:TRUE" or "ValveControl:1".  The former is very clear and the latter two are ambiguous.

[JackDunaway]

A similar Idea was previously suggested.

Also, you may be starting to encounter a more fundamental dilemma... Express VIs are only capable of black-boxing a finite feature set, but once you become more comfortable with the LabVIEW primitives the Express VIs lose their appeal. For some, I understand it's not economically viable or necessary to need more than the Express VIs, but if you continually encounter limitations, it's a good time to start considering the flexibility of the primitives.

As for your application, an enum with your ValveControl states might be useful. Couple that with a "Format into String" and it may provide the custom state text you're looking for. (This also expands the ability to display text for more than two states.)

[Jeff_Long]

I am a 14+ year veteran LabVIEW programmer and CLD.

I appreciate that Express VIs are generally for beginners as they typically condense most common use cases into easy-to-use, wizard-backed VIs, but can frequently limit programming options in exchange for mainstream convenience.

I consider the case of the "Build Text" Express VI to be an exception to that norm.  I find that the use of it can make for a cleaner and easier to understand "at-a-glance" block diagram when formatting a medium to large number of variables of different data types and formatting requirements. 

I stand by my suggestion.  I think that creating a variety of Enums for primitives such as ON/OFF and YES/NO is a waste of my time.  I would agree with you for more application specific options like "DirectIntakeGas:MANFOLD/WASTE_GATE", but not for the very commonly used primitives suggested.

[JackDunaway]

---

@Jeff Long wrote:

I am a 14+ year veteran LabVIEW programmer and CLD.

---

Good, we can have a more frank conversation! This VI hides self-documenation from the caller BD. If NI released this Idea with a slough of hard-coded options (On/Off, Yes/No, Open/Closed...), some people would be satisfied, but that opens maintenance nightmare with requests for more options or multilingual support. If they release an Express VI that can have user-specified config files, this violates the "easy" nature of Express VIs, and requires users to keep up with the config file (building applications, porting code, sharing code...). This particular Express VI is a wrapper around the function "Format Into String" that should be among the first functions a budding LabVIEW GUI developer should master. Finally, this Express VI actually takes longer to configure than building a homebrew Format String that is more flexible, so it's a dubious argument that this Express VI should even exist except in the most basic of applications. Just throwing in opinions for the other side whenever R&D reviews this Idea.

[Darren]

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.