GNOME Bugzilla – Bug 156017
GtkComboBoxEntry doesn't return a 'match' on it's child entry's text
Last modified: 2018-05-02 14:04:34 UTC
GtkComboBoxEntry only returns an iter if the *ComboBox* functionality is used. If the user ignores the ComboBox functionality and instead simply enters text into the child entry box, a 'match' is not registered even if the entered text matches an item in the model *exactly*, and when your try to get an iter, nothing is returned. Or in an expert's words: in gtk+/gtk/gtkcomboboxentry.c (http://cvs.gnome.org/viewcvs/gtk%2B/gtk/gtkcomboboxentry.c? rev=1.19&view=auto), the private function gtk_combo_box_entry_contents_changed, which is the handler for the "changed" signal on the entry (whenever you type something), calls gtk_combo_box_set_active (combo_box, -1). that is, if you type something in, the code assumes you have selected none of the above. there is no attempt to match the entry's contents against the text column of the list store.
2005-04-01 Matthias Clasen <mclasen@redhat.com> Make gtk_combo_box_get_active_text do the right thing for GtkComboBoxEntry (#171373, Robert Staudinger) * gtk/gtkcombobox.h: Add a get_active_text vfunc. * gtk/gtkcombobox.c (gtk_combo_box_real_get_active_text): And implement it here. * gtk/gtkcomboboxentry.c (gtk_combo_box_entry_get_active_text): Implement get_active_text by always returning the content of the entry.
I'm still seeing this bug in gtk+-2.6.10. Typing some text that matches an item in a combo's list does *NOT* mark the corresponding iter as active, no matter what I do after typing the text ( hitting Enter, hitting Tab, etc ). The only way I can get the correct combo's model's iter set 'active' is to use the mouse to select the item from the list.
.
I see that you wanted something different than what the commit in comment #1 was about. Sorry to take so long to notice.
Created attachment 111131 [details] [review] Fix data loss in GtkComboBoxEntry The attached patch fixes the behaviour described, correctly setting the combo's active iter when a user types a string that matches one in the model. ONE OUTSTANDING ISSUE is that I now get a string of warnings: GLib-GObject-WARNING **: gvalue.c:89: cannot initialize GValue with type `gchararray', the value has already been initialized as `gchararray' when a user types into the combo's entry. Obviously this needs to be addressed, but I'm not able to fix it myself ( I'm learning C as of today ). Anyway, it's a small patch. Can someone please review? Cheers.
Created attachment 111199 [details] [review] Fix data loss in GtkComboBoxEntry New patch that fixes previous warnings and adds some comments in the code.
Patch looks fine to me. FYI, what Daniel wants is for the following to work: combo_entry = gtk.combo_box_entry_new_text() combo_entry.append_text('item1') assert not combo_entry.get_active_iter() text_entry = combo_entry.get_child() text_entry.set_text('item1') iter = combo_entry.get_active_iter() store = combo_entry.get_model() assert store.get_value(iter, 0) == 'item1' Indentation needs to be fixed though. GTK+ always use 2-space indents. There is no space between function name and opening brace on some lines. Then someone also needs to check the patch for performance. With very many items in the combo box entry, the added O(n**2) search for each keypress might hurt.
Bug still valid, see http://bugzilla.gnome.org/show_bug.cgi?id=587256#c18
Javier, how is that other bug related to this one?
Created attachment 171775 [details] [review] Make get_active_iter a vfunc GtkComboBoxEntry implements I think the better solution here is to let GtkComboBoxEntry override get_active_iter. So there's no constant looping whenever the user is typing. This patch adds a vfunc and implements it to check the active text (not the entry, since it could be overridden) and checks if it matches a row, otherwise it looks for the active item by index.
*** Bug 676012 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/238.