Re: Update of GtkRadioMenuItems wihtout emitting any signal

["Mark R. Rubin" <markrubn pacbell net>]

Ignacio Nodal <inodal teleline es> 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
markrubn pacbell net