Combo box upper/lower case bug?

[Mellberg]

Hello,

If I have a combo box with the property AllowUndefStrs=False, and a value which I can select from is 'ABBA', then I can't enter 'abba' since only the uppercase 'ABBA' is allowed. If I'll write 'abba' it will become 'ABBA'. This is good I think.

But, If I have the property AllowUndefStrs=True the behavior is still the same. If 'ABBA' is a pre-defined string and I really would like to enter 'abba', then I expect the control to accept my 'abba'-string - since I have defined the control to allow undefined strings. But the combo box changes my writing of 'abba' to 'ABBA'. This is in my opinion bad!

In my case I have a multi-platform-tool which lets me search on, among other things, VI-pathes. And after each search I store the 20 most-recent used values of the combo box to ease it up for the user who performs the searches, so he/she can retrieve old search values quicker. The problem is that the user sometimes writes wrong, of just want to search an path that only differs by the case of the letter, and this 'bug'/problem/feature prevents the user from entering the new value.

I've looked on the properties, trying to find a case-insensitive property - but can't find any one.

Right now, at this moment, I'm sitting on a UNIX system running LV7.1.1, but as I recall the bahavior is exactly the same on LV8.2 on Windows.

Can this 'feature' be considered as a bug, and will it then be fixed or does it exist an work-around somehow? I would like to avoid clearing the buffer of defined allowed strings, becuse that list adds value to my tool. Well, at least in most cases ;-)

Hope I made myself clear enough for you to understand me... 🙂

//Mellberg

[altenbach]

Just use a plain ring and populate it via the strings property. Then just use the ring value to index into the strings array to get the value.

(Also be aware that under windows paths are not really case sensitive, for example abc.vi and ABC.vi are the same. If you have a VI ABC.vi and then you try to save a copy as abc.vi, you'll get an overwite warning... ).

[Mellberg]

Well, correct me if I'm wrong, but using the Ring control will not make it possible to let the user write his/her own value, and that's a must in my case. I could of course replace the Combo box with a String control, but then I will not be able to show the latest used value as I can do with the Combo box.

I imagine that there is no workaround on this problem - if I still want to use the Combo box. I guess I have to live with the upper/lower case bug/feature 'til NI accepts this as a bug and solves it... 🙂


Regards,
//Mellberg

[tbob]

You could use a toggle switch to switch between upper and lower case.  Wire the switch to a case structure and use the To Upper and To Lower functions to convert to whatever case the switch is set for.  This is not a good workaround but I don't see any other choices.  Well the only other choice is to not distinguish between cases and use all upper case or all lower case.

The opposite of your problem is also true.  If your entries are defined in lower case at development time, and someone enters an uppercase at run time, it gets converted to a lower case.  So if "abba" is defined, and someone at runtime enters "A", it will show "abba" as the selection.  I thought it was because of Windows not distinguishing between cases.  But UNIX does distinguish between cases.  So I guess it is a Labview bug.  You should report it to NI as a bug, and also report it to the new requests webpage.  Search NI site for these pages.