Re: [fltk.general] Fl_Multi_Label example seems broken - Forums

On Tuesday, June 15, 2021 at 10:34:04 AM UTC-7 er...@seriss.com wrote:

I'm not quite awake yet, but I'm guessing this has to do with changes made on Mon Sep 11 18:12:58 2017 +0000
as per a thread on fltk.coredev entitled "Fl_Multi_Label: leading underbars in public API"

To read this thread which evolved over the period Sep 9 - Sep 15, you can go here:
https://www.fltk.org/newsgroups.php?gfltk.coredev
..and then in the Search: bar type:

    subject: Fl_Multi_Label:

..and that should show the interchange leading to the modification which can be seen in git:

$ git diff 2a41af 88204a

@@ -117,6 +117,10 @@ int AddItemToMenu(Fl_Menu_   *menu,                   // menu to add item to

   if ( !pixmap ) return i;
   Fl_Menu_Item *item = (Fl_Menu_Item*)&(menu->menu()[i]);
+ const char *itemtext = item->label();         // keep item's label() -- item->image() clobbers it!
+
+ // Assign image to menu item
+ item->image(*pixmap);                  // note: clobbers item->label()

   // Create a multi label, assign it an image + text
   Fl_Multi_Label *ml = new Fl_Multi_Label;
@@ -127,7 +131,7 @@ int AddItemToMenu(Fl_Menu_   *menu,                   // menu to add item to

   // Right side of label is text
   ml->typeb = FL_NORMAL_LABEL;
- ml->labelb = item->label();
+ ml->labelb = itemtext;

   // Assign multilabel to item
   ml->label(item);

..and here's the log entry for that change:

    $ git log 88204a5..2a41af1    Applied Manolo's recommendation (fltk.coredev), removing unnecessary item->image(*pixmap) call.

Yes, you found it. That is the git commit in question. Reading through the thread, you pointed me at, I found the post by Manolo here

https://www.fltk.org/newsgroups.php?s1+gfltk.coredev+v17535

where he mentions

===

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);
}

===

The nagging question is why does calling item.image *just once* allow all the images to be displayed?

Digging into the docs. item.image is actually a fluid compatibility

code which just calls Fl_Pixmap's label method.

So therefore you can replace

item->image(L_redx_pixmap);

with

Fl_Pixmap* pm = &L_redx_pixmap;

pm->label(item);

and the other menu items now display images. Therefore, it must be

something in the label method.

Just as Manolo concluded, I looked at the implementation of label method for pixmap.

void Fl_Pixmap::label(Fl_Menu_Item* m) {

Fl::set_labeltype(_FL_IMAGE_LABEL, labeltype, Fl_Image::measure);

m->label(_FL_IMAGE_LABEL, (const char*)this);

}

I agree with Manolo that Fl::set_labeltype line is allowing all the menu item

images to be displayed. It only needs to be called once.

It is defined as

"Sets the functions to call to draw and measure a specific labeltype."

So I tried to call this line

Fl::set_labeltype(_FL_IMAGE_LABEL, Fl_Image::labeltype, Fl_Image::measure);

but unfortunately labeltype and measure functions are protected, not public.

I'm not sure how to solve this issue. An easy fix would be to revert the example code to the original. But would that just be hiding the real bug. I'm just not sure.