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 [EMAIL PROTECTED] 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: ----------------------------------
