Domingo Alvarez Duarte wrote:
> although I didn't use the "text()" instead of "label()", the
> point of the sample is to show a possible flaw on the implementation of
> Fl_Menu_Bar.
The program seems to demonstrate two things:
1) When you click a menu item, it sets the input field to the title of
the item
2) When you enter a new item name into the Fl_Input field, hitting the
'Change'
button should change the item's title *only* in that window (not the
others)
#1 won't work unless: option_selected->value(o->label());
.......is changed to: option_selected->value(o->text());
#2 won't work unless: menu_options_option1->label(option_selected->value());
.......is changed to: menu_bar->replace(1, option_selected->value());
Regarding #2, that's needed to trigger the Fl_Menu_ 'copy on write'
algorithm I mentioned earlier, which is why without that modification,
changing the item in one window affects the others.
(I'm new to this thread; I wasn't sure what the example was supposed
to demonstrate; I originally thought it was just the crashing issue)
> You are giving an explanation that makes sense by one side but by other
> side why it's implemented this way (I mean a bit crazy):
fluid's current behavior is wrong for making assumptions about user_data()
I agree, and an STR should be issued to fix it.
But one can work with its results; one just has to know more
than one should have to about how Fl_Menu's internals work with
static Fl_Menu_Item arrays.
> -If the code assumes that user_data is making a circular reference to
> "this" why not use "this" itself:
> instead of "o->parent()->user_data()" where user_data == parent() why
> not "parent()"
In this case I suppose it could, because your class derives
from Fl_Double_Window.
In cases where the class doesn't derive from an FLTK widget,
it wouldn't work.
I think that is why fluid does what it does; it tries to use
the FLTK user_data() mechanism to solve the instantiation pointer
issue, but only implements half of it (referencing it), it doesn't
implement the other half (initializing it).
> Again even when your explanation shows a way to make the "sample" work
> it's like instead of go straight from point "A" to point "B" we do trip
> around for a while before go to "B".
To go straight from "A" to "B" I think would be a pretty major rewrite
of fluid's code generator for menubars (which probably should be done ;)
and Fl_Menu_Item should maybe be redesigned as a class so that
manipulating it can trigger the parent's 'copy on write' mechanism.
1.3 might be a good time to at least change Fl_Menu_Item from a struct
to a class (assuming that would help with the above), as I never understood
why Fl_Menu_Item was a struct and not a class.
> Internal code assuming user_data pointing to a fixed place ?
> That kills the utility of having user_data !
It's bad that fluid should need to use user_data(), since the
'user' should be able to use it.
If fluid can avoid using it, it should, but in some cases I
don't think it can, so it uses user_data() by default in attempt
to ensure it works in all cases.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
