On Fri, Dec 21, 2012 at 07:16:07PM -0200, Ivan Baldo wrote: > What happens is that the Tab handler runs before the value-changed > handler
This is the wrong view what happens. The adjustment value is not updated during user's editing of the entry. If the spin button is not set to "numeric" its entry can contain any text during the editing (whereas setting "numeric" ensures the entry contents always parses as a number, making impossible to enter numbers in the scientific format, for instance). The value is updated when editing finishes, for which one possibility is that the entry loses focus. So *first* the focus leaves the entry then *in consequence* the adjustment value is updated. However, this does not seem to be entirely the core of your problem. The CRITICAL errors are printed becuase in gtk_window_real_set_focus() this: if (priv->has_focus) do_focus_change (priv->focus_widget, TRUE); g_object_notify (G_OBJECT (priv->focus_widget), "is-focus"); assumes that do_focus_change() cannot make priv->focus_widget become NULL. IMO there may be sane use cases when this can occur (like yours) so I would try to report a bug. How to work around it? Instead of connecting to "value-changed" monitor all changes to the entry text: g_signal_connect(spin_button, "changed", G_CALLBACK(spin_entry_changed), spin_button2); ... static void spin_entry_changed(GtkEntry *entry, GtkWidget *target) { gtk_widget_set_sensitive(target, g_strtod(gtk_entry_get_text(entry), NULL) != 0); } This will *also* make the second entry insensitive when the content of the first does not parse as a number at all (which is likely a good thing though perhaps not). Regards, Yeti _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list