From: William Lachance (wlach@interlog.com)
Date: Thu Jul 11 2002 - 23:33:23 EDT
This fixes the last assert at startup, although the "cure" is imperfect.
Explanation:
Basically, for the toolbar combo items, we use a "changed" signal from the
entry that is part of the ComboBox to indicate that we should do something
(e.g.: change a style, font, etc.). Unfortunately, gtk2 seems to consider
itself resetting a combobox entry to be an "event". abi thought that we were
trying to set the style to a 0-length string (only to have it set to
something more sensible only moments later).
I think there are ways of handling signals that somehow make this work right,
but I don't have time to make the fix now (nor do I think that this is the
best solution; see below). I have worked around this problem for now by
simply ignoring "changed" signals which give a 0 length for gtkentry's text
string.
See this from the gtk+ reference manual:
"2.4. ...for presenting a set of mutually-exclusive choices, where Windows
would use a combo box?
With GTK+, a GtkOptionMenu is recommended instead of a combo box, if the user
is selecting from a fixed set of options. That is, non-editable combo boxes
are not encouraged. GtkOpti------------------------------------
CVS: Enter Log. Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS: Tag: ABI-GTK2-PORT
CVS: ev_UnixToolbar.cpp
CVS: ----------------------------------------------------------------------
Regards,
William Lachance
wlach@interlog.comonMenu is much easier to use than GtkCombo as well. Use
GtkCombo only when you need the editable text entry."
When I get back from my road trip (see some of you in Boston!), I would like
switch this stuff over to GtkOptionMenu, if there aren't any objections.
CVS: ----------------------------------
This archive was generated by hypermail 2.1.4 : Thu Jul 11 2002 - 22:40:20 EDT