Ignacio Nodal <[EMAIL PROTECTED]> writes: > When I select a different CURRENT_GLOBJECT I want to update the selected > active GtkRadioMenuItem, but without emitting the "activate" signal, so > the menuitems callback isn't call.
and: > How can I activate the widget returned by GtkMenuItemWidget() without > emitting the activate signal? > > may I use something like: > > gtk_menu_item_activate(GTK_MENU_ITEM(act_widget)); > gtk_signal_emit_stop_by_name(GTKOBJECT(act_widget), "activate"); o I have had the same question for over a year now. I've tried searching the list archives, but never found the right keyword to use. o The problem isn't limited to menus. It happens any time you use the same widget for both input (the user is supplying information to the program) and output (the program is displaying information to the user). o In the "input" case, I obviously want the signal to be emitted. For "output", I don't because the program already knows it's changing the widget's value. o At minimum, the unwanted signal causes unnecessary/redundant computation to take place. At worst, it can cause an infinite loop. Last year I wrote, but never posted, a simple example program to illustrate this. It's my own "hello world" test program for GUI toolkits: A fahrenheit-to-celcius temperature converter. It has two spinputtons, one for F and one for C. The user changes either one, and the other displays the correct matching temperature. For example, when the user inputs a C temperature, a signal is emitted, the program calculates F and displays it in the other spinbutton ... which then emits a signal causing a conversion back to F, and an update of the F spinputton. (In this case, because the conversion is invertible, the F value is the same as what the user inputted, so the F spinbutton doesn't emit a signal. No infinite loop, just redundant calculation.) o My workaround -- for real-world programs, not toy F-to-C converters -- is to set a flag when changing a widget. Then, in the signal handler: if (flag) { flag = FALSE ; return ; } else // really handle the signal o In C and Gtk this gets ugly very fast (global variables). I use C++ and Gtk--, so I wrap (for example) Gtk::Adjustment in my own class which handles the flag internally. It's still pretty ugly. o Someone (Havoc??) must know the right solution to this problem. -- MARK [EMAIL PROTECTED] _______________________________________________ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list