On Sunday, 10 September 2017 07:34:48 UTC+2, Greg Ercolano wrote:
I can only imagine this was done to avoid adding a new Fl_Image*
to Fl_Menu_Item so that an item could have both, as doing so
would have ABI implications, which back in the old days, was kinda a show stopper.
I agree this hypothesis seems likely to be true.
But, if there's room for a text label and an image in an Fl_Menu_Item,
doesn't the raison d'etre of Fl_Multi_Label vanish?
About the proposed example program for Fl_Multi_Label :
Line 118
item->image(*pixmap); // note: clobbers item->label()
is not useful. Without it, the same final effect is obtained.
The multi-label is finally assigned to the menu item at line 132
ml->label(item);
But the doc suggests this could also be done with
item->label(_FL_MULTI_LABEL, (char*)ml);
that is, with the Fl_Menu_Item::
label (
Fl_Labeltype a, const char *b) member function.
This other approach does not work, though, and I believe
this is a point of inconsistency of the API.
The source code of Fl_Multi_Label::label(Fl_Menu_Item* o) is
Fl::set_labeltype(_FL_MULTI_LABEL, multi_labeltype, multi_measure);
o->label(_FL_MULTI_LABEL, (const char*)this);
Thus, the difference between the 1st and the 2nd approaches listed above
is the call to Fl::set_labeltype(). Indeed using the 1st approach once
and then the 2nd approach produces correct multi-labelled menu items.
The API inconsistency could thus be solved adding an Fl_Multi_Label
constructor:
Fl_Multi_Label::Fl_Multi_Label() {
static unsigned count = 0;
if (!count++) Fl::set_labeltype(_FL_MULTI_LABEL, multi_labeltype, multi_measure);
}
