[Cross-Posting to fltk.development, because this is something that ought to be discussed there. fltk.bugs is for automatic posting from the STR system only.]
On 19.08.2011 02:18, Csaba Biegl wrote: > Consider a fluid class containing an Fl_Input_Choice widget. If this widget > has Fl_Menu_Item-s that have their own callbacks then these will crash the > program. > > Reason is that Fl_Input_Choice itself is a group containing an FL_Input and a > Fl_Menu_Button. It is the latter component that executes its menu item > callbacks on their behalf. > > Fluid generated callbacks find their class instance using repeated > "->parent()" calls. Because Fl_Input_Choice adds an other group to the > hierarchy, the fluid generated callback will access the wrong object. Good catch - that sounds plausible (although I'm not very familiar with fluid code). > I can post a patch to fix this, but we need to decide where to fix it. Thanks for the offer! > Option 1: Fix it in fluid so that for Fl_Input_Choice menu item callbacks it > adds one more "->parent()". Advantage: This fix would be "local" to fluid. Drawback: special handling in fluid. > Option 2: Fix it in Fl_Input_Choice so that its own subclassed version of > Fl_Menu_Button passes up menu item callbacks to its parent. 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). Just my 2 ct; I'll leave the final decision to others... Albrecht _______________________________________________ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
