CEGUI (Crazy Eddie's GUI) Forums

I found out that getSelectedItem() always returns NULL after the combobox is dropped and the user clicked on the editbox (to close it and remain the previous selection). I think thats really annoying because the user (and the programmer ) expects that the selected item doesnt't change when clicking on the editbox to close the droplist.
Is it a bug or a feature?

Hi and welcome,

i ran a quick check and appearently you are right. It even happens when you close the list with the arrow. So IMO it's a bug, i have put it in Mantis:
http://www.cegui.org.uk/mantis/view.php?id=164

Thanks for mentioning.

Wow, so it wasn't a mistake of mine . Hope there will be a fix on svn soon.

Hi again,

a safe workaround for this issue is listening to the EventListSelectionAccepted event of your combobox(es). This event only gets called when the user clicks an item in the dropdown list.

HTH.

My approach has been to disable the editbox part and to query the current selection via getText(). However I think this widget needs some work via higher level code (a wrapper class).

Opening the combobox and scrolling through the items could change the current text within the editbox but hitting ESC (escape button on keyboard) would cancel this change and revert to the previous value.

Typing text within the editbox should activate an autocompletion mode where the best fitting value is displayed, even if it does not match the text specified by the user. For example the combobox contains two entries; "hello", "world". By default "hello" is selected. Typing any word that begins with the letter "a" to "g" will always select "hello". Typing "hf" selects "world".

Another feature could be that typing text in the editbox opens up the editbox and moves the selection bar to the appropriate item.

A lot could be programme on top of the existing code, and not all of which needs to be within the Cegui core itself; some of these features are application-specific. I wonder if it would be possible to code multiple tiny features and add some of them to a combobox to modify its behavior. This requires more thought.

Hrm, maybe I should not write anything before being fully awake. This may be editer later on, to remove the bits that make absolutely no sense...

This issue has been fixed in svn trunk rev. 1539.

While the list is open the selection is updated, but if the list is closed without the user 'confirming' any selection, the selection reverts back to the previously confirmed selection.

CE.