All right. All who commented seem to be just as undecided about this as I was.
Clearly neither solution is "clean". So I went with the one that does not break
the ABI: just add one more "->parent()" in the fluid code generator.
Patch and a simple fluid test program are coming up in two follow-up file
attachments. Test program crashes when compiled with 1.3.0's fluid, does not
crash when compiled with the patched one.
For the future a "clean" solution for Fl_Input_Choice (and similar future
menu-based derived widgets???) could be something like this:
class Fl_Input_Choice : public Fl_Menu_Button {
Fl_Input input_;
// ... reimplement handle(), draw(), resize(), etc.. as needed
// to lay out and process the widget w/o the use of a group.
};
>
> > On 19.08.2011 02:18, Csaba Biegl wrote:
> > > Consider a fluid class containing an Fl_Input_Choice=20
> > widget. If this widget has Fl_Menu_Item-s that have their own=20
> > callbacks then these will crash the program.
> > >
> > > Reason is that Fl_Input_Choice itself is a group containing=20
> > an FL_Input and a Fl_Menu_Button. It is the latter component=20
> > that executes its menu item callbacks on their behalf.
> > >
> > > Fluid generated callbacks find their class instance using=20
> > repeated "->parent()" calls. Because Fl_Input_Choice adds an=20
> > other group to the hierarchy, the fluid generated callback=20
> > will access the wrong object.
> >=20
> > Good catch - that sounds plausible (although I'm not very=20
> > familiar with
> > fluid code).
> >=20
> > > I can post a patch to fix this, but we need to decide where=20
> > to fix it.
> >=20
> > Thanks for the offer!
> >=20
> > > Option 1: Fix it in fluid so that for Fl_Input_Choice menu=20
> > item callbacks it adds one more "->parent()".
> >=20
> > Advantage: This fix would be "local" to fluid.
> > Drawback: special handling in fluid.
> >=20
> > > Option 2: Fix it in Fl_Input_Choice so that its own=20
> > subclassed version of Fl_Menu_Button passes up menu item=20
> > callbacks to its parent.
> >=20
> > This is what I'd prefer on a first thought. But then there is the
> > possibility that this would break user code that handled this
> > correctly (code *not* generated by fluid).
> >=20
> > Just my 2 ct; I'll leave the final decision to others...
>
> I'm not keen on special handling in fluid - though that might be most
> compatible. So changing Fl_Input_Choice seems favourite, but...
>
> If we do change the "structure" of Fl_Input_Choice that may have to be
> deferred to "1.4" as it'll be a breaker I guess?
>
>
>
>
> SELEX Galileo Ltd
> Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS=
> 14 3EL
> A company registered in England & Wales. Company no. 02426132
> ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
>
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
