Combobox query

[gcarlton]

I'm using the Combobox for the first time, and its working a treat. The only thing that I can't seem to do is to query whether the drop down list is active or not.

I need this because I'm doing a stupid poll check on the currently selected item (this is a menu for a debug test state), and it turns out the currently selected item changes as the user is hovering over the drop down list part.

This is fine, as long as I am able to check whether the combobox has the list active, or whether the user has made their final choice. Any way to do this?
If not, I can just make a small change to the interface and submit it as a patch, if you would prefer.

[CrazyEddie]

You could do:

Code: Select all

WindowManager::getSingleton().getWindow("MyCombo__auto_droplist__").isVisible();


Where "MyCombo" is the name of the combo box is visible. Though this is a bit of a hack that relies on implementation details. A new method for Combobox would be better (just return d_droplist->isVisible(); )

Another approach would be to track the shown / hidden events for the list, but a new method is far less painful

CE.

[gcarlton]

Yep, I added that and it worked fine.

Code: Select all

   /*!
   \brief
      returns true if the drop down list is visible.

   \return
      true if the drop down list is visible, false otherwise.
   */
   bool   isDropDownListVisible(void) const;


Code: Select all

bool Combobox::isDropDownListVisible(void) const
{
   return d_droplist->isVisible();
}


Just for fun, I made it up into a patch and submitted it to the patch page too, just to see if it would work. Of course, the effort of applying the patch is far more than just making up the function yourself, but still..

[gcarlton]

I've had a play with it some more, and there are actually some issues with the current combobox implementation. Apart from the combobox's current item jumping around as you hover, closing the combobox doesn't work.

Pressing the button to open, and then to close, leaves the text saying the old item, but actually resets the current item to the top of whatever list was opened previously.

This is due to a bug (?) in Listbox getItemAtPoint(), which gets the final button click which is outside the box, but still selects the first item. The code should have this extra check at the start of the function:

Code: Select all

   if (pt.d_y < y)
   {
      return NULL;
   }


However, that just leaves the current item as null on close, which isn't much better. In fact, the current item is null as soon as the drop box opens due to the cursor being outside the listbox.

I think the best solution would be to add a pointer to the currently selected item in the combobox, and redirect the combobox queries to that. This also makes sense because you don't want the combobox to change its selection just because the user is hovering the mouse around as they are trying to make their choice.

At this point, I've stopped digging around, since its a fairly substantial change, and I don't really need a proper combobox at the moment anyway. I guess its one of the things to add to the list.

BTW,
I'm using the model of what should happen as the Dev Studio Configuration Combobox which is nice and handy (the Debug/Release/.. one). That also has the nice feature of clicking on the editbox opening the listbox up, rather than a read-only attempt to select the text.

[CrazyEddie]

Thanks for the patch I'll get this added later this week

Apart from the combobox's current item jumping around as you hover, closing the combobox doesn't work.

I don't get this behaviour, it just selects the item under the mouse here.

Pressing the button to open, and then to close, leaves the text saying the old item, but actually resets the current item to the top of whatever list was opened previously.

The list is only valid when it's displayed. This was by design. You'd be better off grabbing the editbox text and doing a findItemWithText() to get the listbox item. I suppose I could add a call to select any item matching the editbox text when the list gets hidden.

This is due to a bug (?) in Listbox getItemAtPoint(), which gets the final button click which is outside the box, but still selects the first item. The code should have this extra check at the start of the function:

Code: Select all

   if (pt.d_y < y)
   {
      return NULL;
   }


Selection for the combo drop-list has nothing to do with mouse button events, it's dealt with in mouse move handler exclusively. This handler only changes the selection when the mouse is within the list area. There may be an issue with initial list selections (and possibly selections at close, though see above about the fact that the list selection should be considered invalid when the lists is not visible).

However, that just leaves the current item as null on close, which isn't much better. In fact, the current item is null as soon as the drop box opens due to the cursor being outside the listbox.

Only after the first mouse move actually I'll see about fixing this so it does not lose the initial selection immediately.

I think the best solution would be to add a pointer to the currently selected item in the combobox, and redirect the combobox queries to that. This also makes sense because you don't want the combobox to change its selection just because the user is hovering the mouse around as they are trying to make their choice.

Two things here; first, I don't get the problem with the selection changing; if you mean that you get notifications about the change, this was by design, if you only want to know what they finally click on, use the correct event which is EventListSelectionAccepted (maybe that's only one thing and not two things?).

At this point, I've stopped digging around, since its a fairly substantial change, and I don't really need a proper combobox at the moment anyway. I guess its one of the things to add to the list.

Excepting a couple of minor issues with the initial list selection, and the fact that the selected item is lost when the list is closed, the combobox behaviour is pretty much as I designed it to be and will not be changing significantly.

...That also has the nice feature of clicking on the editbox opening the listbox up, rather than a read-only attempt to select the text.

I will add this functionality in though

CE.

[CrazyEddie]

I have made some modifications to the Combobox. The visual feedback and associated behaviour is slightly different, but should more closely match what you're used to if you're a Windows user.

I have also made a few minor changes 'under the hood', and any 'selected' item in the hidden list should more closely match the last item selected by the user; however, there is still the case where the list is dismissed without making a selection, and in these cases there will be no item selected. This is, as far as I am concerned, the correct behaviour (as stated earlier, you can always look up the item from the text in the editbox).

I think many of these 'issues' are more a difference of opinion about what a Combobox is about. For myself, it's about what ends up in the editbox rather than what ends up selected in the list (which would seem to be your preferred behaviour). If the selection from the list is important though, don't forget to listen on the EventListSelectionAccepted event rather than the EventListSelectionChanged event.

CE.

[gcarlton]

Ok, I'll get latest and check it out this morning!

It does seem we have a different opinion - for me its really about choosing one of a set of options, and closing up the box should ideally be "no change" rather than go to a null selection. For another example, take all the comboboxes in this forum webpage. You don't open them up and close them and have it jump to a "null" choice. Or even stranger, have the text display one thing but have the actual item as something else.

I think the best way is if I extend the listbox to have a "latched" mode where the current item can never go back to NULL. This may be handy for listboxes in general, and the combobox can simply set its dropdownlist to that mode if the user desires it.

That simple change would allow both modes of operation, so we're both happy.

[gcarlton]

I've submitted another patch, whether you wish to apply it is up to you.

To clarify my motivations, I want a combobox that I can push a set of Items into, and let the user choose one. I want the editbox text to always be in sync with combobox->getSelectedItem(), and have a mode where the choice can never be set to null.

The changes I made were:
1.) Listbox/Combobox have isLatchSelectEnabled & setLatchSelectEnabled. When set, the listbox latches the selected item and not let it go to NULL.

2.) In this mode, the combobox doesn't autoselect items as the cursor moves, the selection is only changed when the user clicks on an item.

3.) Also, the listbox::OnMouseButtonDown checks isHit() to avoid selecting items off the edge of the box - it was still happening even with the (point.d_y<y) change we talked about earlier.

4.) The dropdown box no longer closes when clicking on the scrollbar. Fixed with a change in dropdownlist::onMouseButtonUp.

By default (with "latch" off) it works as it does now. Also, I think 3 & 4 would be useful even if you disagree with my prefered combobox operation, since they seem legit bug fixes.

Cheers,
Geoff

[CrazyEddie]

I've submitted another patch, whether you wish to apply it is up to you.

Indeed. Though thanks for the patch

To clarify my motivations, I want a combobox that I can push a set of Items into, and let the user choose one. I want the editbox text to always be in sync with combobox->getSelectedItem(), and have a mode where the choice can never be set to null.

That's fair enough, though there are obviously cases when the listbox does not even contain an item for what is in the editbox, so synchronising them in this circumstance could prove a little difficult (Don't take that too seriously, I am just being facetious).

The changes I made were:
1.) Listbox/Combobox have isLatchSelectEnabled & setLatchSelectEnabled. When set, the listbox latches the selected item and not let it go to NULL.

I'll make a decision about this at some stage, though don't hold your breath. Obviously, the patch will be available for anybody who needs this behaviour in the mean time.

2.) In this mode, the combobox doesn't autoselect items as the cursor moves, the selection is only changed when the user clicks on an item.

Why anybody would want this I do not really know. Virtually every combobox I've ever seen highlights the items as you move the cursor over them. As I said yesterday, if you're only interested in the item that finally gets clicked upon, use the correct event that is provided for this purpose (if this event does not work, report it as a bug ).

3.) Also, the listbox::OnMouseButtonDown checks isHit() to avoid selecting items off the edge of the box - it was still happening even with the (point.d_y<y) change we talked about earlier.

This ability to select outside of the item rendering area (as opposed the the entire listbox area) is really a minor bug, and I'll make sure this is fixed today.

4.) The dropdown box no longer closes when clicking on the scrollbar. Fixed with a change in dropdownlist::onMouseButtonUp.

I tested this, and it looks like another bug. This will also be fixed today.

By default (with "latch" off) it works as it does now. Also, I think 3 & 4 would be useful even if you disagree with my prefered combobox operation, since they seem legit bug fixes.

Yep, the symptoms of 3 & 4 could definately be considered as bugs really, so these will (as mentioned above) be fixed.

CE.

[gcarlton]

Ok, thanks for your patience as well.

BTW, I agree about point 2. It was just easier to get it running that way, since otherwise the dropboxlist forgets its item as soon as you move - problematic if you wish open/close keep the old item, as I do. A proper solution would no doubt involve keeping a copy of the current item around somewhere else, but I can't quite justify spending endless days tweaking a single gui widget.

[CrazyEddie]

A proper solution would no doubt involve keeping a copy of the current item around somewhere else

Hmmm. Funnily enough, I actually thought about doing that Maybe over the weekend...

but I can't quite justify spending endless days tweaking a single gui widget.

No, me neither really; which is why I'm sort of on the 'negative' about changing too many things at the moment.

CE.

[zanir]

Issue with cleaning a selection if drop down list is showed and item is not selected is still not fixed. So I have to use code:

Code: Select all

CEGUI::ListboxItem* pItem = pCombo->findItemWithText(pCombo->getText(), NULL);


instead:

Code: Select all

CEGUI::ListboxItem* pItem = pCombo->getSelectedItem();