Unchecking "Allow Undefined Strings" for System Combo Box Doesn't Work

[Sima]

Why will my system combo box still allow undefined strings even after unchecking "Allow Undefined Strings"?

The combo box works nicely because it allows the user to start typing in the string they want and the combo box will finish it off for them, but if you hit delete or change a letter turning it into an undefined string, the combo box will accept it.

Edit: I'm using LV 8.5

Message Edited by Sima on 01-14-2009 07:03 PM

Message Edited by Sima on 01-14-2009 07:04 PM

[chrisger]

Not seen with 8.5.1.

Maybe it's update time!

[chrisger]

Stop it !!

I played around a little bit more. I created a string indicator to the combo (a string indicator, not combo indicator). You'll see that the string shows the last valid value of the combo, even if the combo shows an invalid value. But in some cases where i pressed delete or clicked the mouse outside of the combo the invalid value was accepted.

Sorry, not solved in 8.5.1... 

[LabBEAN]

I tried this in 8.5.1 and 8.6 and cannot get the combo box to take anything other than the defined values, except for the case of a blank entry.

Sima probably knows this, but FYI, "Wait Until Next ms Multiple" is actually for synchronization.  For static loop waits, developers should be in the habit of using "Wait (ms)", as the loop delay is always constant.  If the internal counter is at 11111499, and you use a 500 ms synchronous wait, then you only actually wait 1 ms on the FIRST loop iteration.  Subsequent loop waits will be 500, 1000, 1500, etc. milliseconds depending on the duration of the code in the loop.

[Sima]

---

LabBEAN wrote:

I tried this in 8.5.1 and 8.6 and cannot get the combo box to take anything other than the defined values, except for the case of a blank entry.

Sima probably knows this, but FYI, "Wait Until Next ms Multiple" is actually for synchronization.  For static loop waits, developers should be in the habit of using "Wait (ms)", as the loop delay is always constant.  If the internal counter is at 11111499, and you use a 500 ms synchronous wait, then you only actually wait 1 ms on the FIRST loop iteration.  Subsequent loop waits will be 500, 1000, 1500, etc. milliseconds depending on the duration of the code in the loop.

---

  Thanks. My VI was not really to demonstrate timing and synchronization. I just needed something in the loop. I'll watch that next time

I also put a string indicator on the combo box. If you start typing then hit backspace or delete, the invalid value will take.

[LabBEAN]

I don't see the issue with Delete, but Backspace causes what I think you're seeing.  If I type "a" into your example combo box, it autocompletes the "re" in the word "are".  If I hit delete, nothing happens.  If I type other characters, nothing happens.  But, if I hit backspace, then the "re" disappears, leaving just "a".  If I click outside the combo box, the a is left, and a string indicator picks this up.  Thus, the combo box has allowed an undefined string.

Ouch.  A little help from NI, please?

Maybe this is what "festo" was seeing here:

http://forums.ni.com/ni/board/message?board.id=170&requireLogin=False&thread.id=114297

(no offense intended I figured you were just slowing your code down... but thought it was an opportunity to stop others from starting bad habits with Next Multiple.)

[LabBEAN]

Okay, so going to the first position in the combo box and hitting Delete deletes the entry.  If you click outside the combo box, then it accepts the blank.  So Delete is also a problem in that case.

It's still a problem in LabVIEW 8.6 and happens to both the system and standard combo boxes.

[Kristen_K.]

Hello Sima!

Thank you for posting to the discussion forums!  The behavior you are seeing is actually a known issue and has been documented.  The Corrective Action Request on this issue is CAR #41580. Hopefully, our R&D team will fix this issue a.s.a.p!  Have a great day!

Kristen H.

[Sima]

Thanks Kristen.

[allaba]

---

Kristen H. wrote:

Hello Sima!

Thank you for posting to the discussion forums!  The behavior you are seeing is actually a known issue and has been documented.  The Corrective Action Request on this issue is CAR #41580. Hopefully, our R&D team will fix this issue a.s.a.p!  Have a great day!

Kristen H.

---

Hi Kristen,

the incorrect behavior (that a combo box with 'allow undefined values' disabled accepts other entries than the predefined ones, e.g. a blank entry) still exists in LV 2009. 

Is there a chance that a.s.a.p. could be in 2010??

-Franz