GNOME Bugzilla – Bug 118585
Gtk::Combo::signal_selection_changed emmitted during destruction.
Last modified: 2004-12-22 21:47:04 UTC
I'm not sure that this is a bug, but I think Combo's signal_selection_changed should not be emitted while the combo is under destroy. This can be reproduced with the following code. In the program simply hit the 'Do it' button. <-- code.cpp --> /* To compile use the following command: g++ code.cpp `pkg-config gtkmm-2.0 --cflags --libs` */ #include <gtkmm/button.h> #include <gtkmm/combo.h> #include <gtkmm/main.h> #include <gtkmm/window.h> using namespace Glib; using namespace Gtk; using namespace SigC; using namespace std; class CrashWindow : public Gtk::Window { private: Combo _combo; SigC::Connection _selection_changed; void _do_a_crash() throw (); public: CrashWindow() throw (); ~CrashWindow() throw (); }; CrashWindow::CrashWindow() throw () : Window() { add(_combo); _selection_changed = _combo.get_list()->signal_selection_changed().connect( slot(*this, &CrashWindow::_do_a_crash) ); show_all(); list<ustring> l; l.push_back("x"); _combo.set_popdown_strings(l); } CrashWindow::~CrashWindow() throw () { /* The next line solves the crash, but signal_selection_changed should be emitted when the object is destroyed? */ // _selection_changed.disconnect(); } void CrashWindow::_do_a_crash() throw () { if (_combo.get_entry()->get_text() != "") ; } void do_a_crash() throw () { static CrashWindow* _window = 0; for (int i = 0; i < 2; i++) { if (_window) delete _window; _window = new CrashWindow; _window->show(); } } int main(int argc, char *argv[]) { Main app(argc, argv); Window window; Button button("Do it"); window.add(button); button.signal_clicked().connect(slot(do_a_crash)); window.show_all(); app.run(); } <-- end of code.cpp -->
Sorry for the lack of response. This is my top-priority bug, but I am waiting for a new hard drive. It might be another week until I can investigate.
Created attachment 19467 [details] combo_signal.cc
Here's a slightly clearer example (combo_signal.cc). Yes, it does seem strange that a signal is emitted during destruction, particularly one that requires you to look at the widgtet to see what exactly has changed. But I do think some widgets have good reasons to emit signals during destruction. I need to try this in C and then ask the GTK+ people about it.
Created attachment 19907 [details] combo_signal.cc rewritten in GTK+ & C (for test)
I rewrote the combo_signal.cc in GTK+ & C for testing that GTK+ has this bug too. The result of the test seems that GTK+ is free from this bug. I also noticed an interesting thing: In GTK+ we catch the combo change signal from the entry text changing, in GTK-- from the change of the list. I don't know that this could be an important thing in the bug.
That's interesting, but if the C test case does something different then it isn't a C version of the same test case. I would like to test for the specific problem in C. However, f we should be using the combo's entry's "changed" signal, then we can do that with gtkmm with Gtk::Combo::get_entry(). Somone might try that. The GTK+ tutorial seems to suggest that we should use the "activate" signal: http://www.gtk.org/tutorial/sec-combobox.html It's all very confused. We know that GTK+ 2.4 will have a new Combo widget but I'm sure that we can make more sense of the current GtkCombo.
The only differece (imho) was the method of notify our program that the combo's data was changed. The method was taken from the GTK+ FAQ (http://www.gtk.org/faq/#AEN723).
Created attachment 19914 [details] combo_signal.cc rewrote to test the method from combo_signal.c
I modified the combo_signal.cc to test the combo's change like the combo_signal.c. Seems working normal (the change signal - in this method isn't emitted during destruction).
Created attachment 19916 [details] combo_signal.c modified to match the original test case - use of list's selection-changed
Yes, if we use the list's selection changed in GTK+ then it is also emitted after destroy.
Well done. So, the selection-changed signal might have a GTK+ bug, but it's part of the deprecated GtkList widget, used by the soon-to-be-deprecated GtkCombo widget. So, let's not worry about that too much. It looks like the answer is just to use Gtk::Combo::get_entry()'s "changed signal". This is what we already show in the examples/book/combo example, I see now. I would like the original submitter to confirm that this works for him, then I will close this bug. Thanks for the help.
If I understand you well, at this time I should confirm that this work for me as I opened the bug report. Of course it works for me, thanks for the help.
OK, so the answer is "don't use the selection_changed" signal. gtkmm 2.4 will have a new Combo widget.