After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 564160 - gtk_combo_box_entry_set_text_column too restrictive
gtk_combo_box_entry_set_text_column too restrictive
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkComboBox
2.14.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 590005 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-12-11 18:03 UTC by rassahah
Modified: 2009-09-22 11:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Remove dubious assertion (507 bytes, patch)
2009-04-03 17:04 UTC, Christian Dywan
none Details | Review
test case (1.99 KB, patch)
2009-09-22 11:45 UTC, Daniel Svensson
none Details | Review

Description rassahah 2008-12-11 18:03:13 UTC
Please describe the problem:
an unnescessary check in gtk_combo_box_entry_set_text_column prohibits repeated settings of the text-column.

Steps to reproduce:
1. create any GtkComboBoxEntry
2. gtk_combo_box_entry_set_text_column (combo, 0);
3. gtk_combo_box_entry_set_text_column (combo, 0);


Actual results:
an error return in gtk_combo_box_entry_set_text_column's implementation:
  g_return_if_fail (entry_box->priv->text_column == -1);
forbids the second setting of the text-column.

Expected results:
calling the gtk_combo_box_entry_set_text_column the second time should set the
text_column variable to the new value.

Does this happen every time?
happens every time (except the first time of course).

Other information:
the initial value of -1 in text_column does not seem to have any deeper sense except to return an error if called multiple times. So simply removing the g_return_if_fail should work fine. Since one can set the model with `gtk_combo_box_set_model', one should be able to set the text-column, too.
Comment 1 Matthias Clasen 2008-12-15 03:46:23 UTC
I don't see any good reason for that assertion in the code.
Kris, do you remember why that is there ?
If not, we should just remove it.
Comment 2 Christian Dywan 2009-04-03 17:04:00 UTC
Created attachment 132019 [details] [review]
Remove dubious assertion

This patch removes the dubious assertion.
Comment 3 Daniel Svensson 2009-09-22 11:45:28 UTC
Created attachment 143686 [details] [review]
test case

This bug was duplicated in #590005 which also had a test-case which verifies the correctness. (Untested code is broken code?)
Comment 4 Daniel Svensson 2009-09-22 11:46:27 UTC
*** Bug 590005 has been marked as a duplicate of this bug. ***