Domingo Alvarez Duarte wrote:
> If FLTK makes a copy on assignement how it manages to update references to
> the old entry ?
When you (or fluid) calls Fl_Menu::menu() to pass in an array,
the internal private copy 'alloc' flag is cleared. This tells fltk
the array is 'user provided' and it should assume FLTK cannot manage it.
When e.g. add() is called, the 'alloc' flag is checked:
if 0: the flag is set and a copy of the array is made so it can
be manipulated
if 1: FLTK knows the array can be manipulated
For implementation details, see the 'alloc' flag in Fl_Menu_.{H,cxx}
> I made a simple program with fluid to show the problem, to start with it
> crashs when a menu is selected !
>
> What's wrong on it ?
Two things:
1) Make a constructor for the BaseWindow class that sets:
user_data((void*)this);
2) In the two callbacks, change:
option_selected->value(o->label());
..to this:
option_selected->value(o->text());
Regarding #1, fluid is automatically generating callback code for you,
and it seems to be resolving these callbacks by assuming the
BaseWindow's window
has its user_data() set to 'this'.
Here's the code where it was crashing:
((BaseWindow*)(o->parent()->user_data()))->cb_menu_options_option2_i(o,v);
(I found this by adding printf()'s to fluid's generated code to view
the value of o->parent()->user_data())
Here fluid is assuming that the parent widget to the menubar has its
user_data() set to 'this', but apparently fluid does not automatically
generate code that does this.
So "o->parent()->user_data()" is coming back NULL, and it crashes.
I believe at that point in the code, 'o' is the menu_bar, and
o->parent() is the parenting window.
So to make that code work, you'd have to set the user_data() for the
window in this case to 'this'. You can either define a constructor for
the class and add:
user_data((void*)this);
..or you can click on the properties of the BaseWindow, and set
the "User Data:" field to 'this'.
With either of those modifications, the program works OK.
Arguably fluid should do one of these for you. It'd have to recognize:
a) a widget is being defined inside a class,
b) a callback is being implemented by the user 'automatically'
by fluid (with the above code
..and make the above changes (or warn the user to make them).
This probably gets tricky for fluid to do, though, eg. when copies of
the
class or menubar are made with ^C/^V in fluid, etc.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
