LabVIEW
Using "To-upper-case" on cluster with Enum (LabVIEW 8.2)
Message Edited by tbd on 01-23-2007 09:21 PM
It fails the same way under LabVIEW 8.0. Clearly something is not handled properly.
(Of course I don't quite see the general usefulness to use "to uppercase" on a simple enum. ;))
@altenbach wrote:
(Of course I don't quite see the general usefulness to use "to uppercase" on a simple enum. ;))
Indeed it doesn't compile. But the To Upper Case VI handles numbers as ASCII codes. How would converting an enum value of 97 to 65 be useful to you? Are you trying to capitalize the strings in the enum's typedef? A case structure shouldn't allow you to create a new case for an enum input if the string doesnt match exactly... Howabout just using an integer and an array of strings?If you really want to get the enum strings at runtime, OpenG has a few functions to help with such silliness.
@tbd wrote:
Oh, gee, do it (enum to upper-case) all the time when I forget and type enumerated-case-values in all upper-case.
The way I understand "to uppercase", it will just turn the enum into an unsigned integer, then remap certain values according to their ASCII representation (See figure). You can do the experiment yourself. (From the online help: If string is a numeric value or an array of numeric values, each number is evaluated as an ASCII value. The To Upper Case function translates all values in the range of 97 to 122 into values over the range of 65 to 90. All other values remain unchanged.) Actually, the help is incorrect, it touches a few more ranges for 8 bit ASCII (again, see figure)
Actually, the online help for "To Upper Case" does NOT mention support for enums at all (quote: string can be a string, a cluster of strings, an array of strings, or an array of clusters of strings.)
So, having an enum with only two values as in this case, will not remap anything anyway, you'll need an enum with 97+ values to even see a difference. It definitely does not change the case-ness of the enum strings!
WIre an enum to a case structure, then insert a "to uppercase" in-between. You'll loose all the enum strings....
Message Edited by altenbach on 01-23-2007 11:46 PM
Hey! Guys!, I wasn't serious! 
I'd assembled a bundle of (mostly) strings collected from a GUI, and wanted all the strings upper-case. I thought it would be much cleaner to put the "to-upper-case" on the cluster-wire, this also lets the bundle-by-name be changed without managing a "to-upper-case" for each input. Tried it, and... Hey -it worked! Chalk another-one up for polymorphism!
... then, strangely, I couldn't save my VI without a series of very odd error-pop-up dialogs.
I thought Altenbach was kidding, so I kidded back. ...but if you were serious, then my response to:
> (Of course I don't quite see the general usefulness to use "to uppercase" on a simple enum)
is: You seem to be assuming that the intention was to apply "to-upper-case" to the enum. It's not. The intention was to apply "to-upper-case" to the Strings in the cluster. I thought it was supposed to work that way, else they should just break the wire if any elements are not strings - like they do if converting cluster to array but cluster data-types are dissimilar.
... However, having just read the help for "to-upper-case", it looks like only clusters of strings should be legal.
Message Edited by tbd on 01-24-2007 03:21 AM
@tbd wrote:
I thought Altenbach was kidding, so I kidded back.
I wasn't sure if you were kidding or found some very creative way around an obscure non-problem, so I investigated. 😄
Anyway, you can replace the enum with a plain integer in the cluster and LabVIEW is perfectly happy and compiles just fine, so there is no reason why LabVIEW should choke on the enum. It's a bug.
Try it with a cluster containing a mix of strings and integers, it's all fine. 🙂
Message Edited by tbd on 01-25-2007 12:25 AM
