Thanks for your clear explanation of the problem, I couldn't do the same myself and now I know that the problem exists and others than me are aware of it too.
En 08/11/2010 21:30:29, Greg Ercolano <[email protected]> escribió: > 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. > -- Usando el revolucionario cliente de correo de Opera: http://www.opera.com/mail/ _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
