Hi Jim, On 13.07.2011 03:01, Jim Jozwiak wrote: > The application is nut-16.13 from nut.sourceforge.net. To recreate the > problem, go to the "View Foods" tab and find a food, such as "baked russet". > The food will come up, but at this point the application freezes. gdb > usually tells me fltk is sitting on line 331 of ../FL/Fl_Menu_Item.H, but I > can't see what is wrong. My code worked at least until 1.3.0rc3, and works > on 1.1.10. Since the earlier versions of 1.3.0 have disappeared from your > site, I had to rerelease nut with explicit instructions to only use 1.1.10, > but I didn't change my code.
Usually we don't look at full applications to replicate a problem with FLTK, because it is much easier to find a potential bug in a short test program. In your case I was curious, and so I tried nut. There are good news for you: See the small one-line patch at the end of this message for your application that should fix the issue for you. At least it worked for me. Note that this might access one more menu entry, and that I didn't see any range checks in your code. Please take care of that yourself. I also didn't look at the initialization of the label() of additional menu entries. IMHO it would be best to initialize menu entry n+1 with label(0) and no flags to have a correct terminating entry, or maybe something like memset(&pulldown[n],0,sizeof(pulldown[n]) ). Side note: after tweaking the Makefile(s) a little, I was able to compile and run your code on Windows 7. I didn't bother to test on Linux, although I could have done that too... The problem with your code (together with the handling in FLTK 1.3) was that you set the terminating menu entry to invisible() implicitly in line #68 in fltk/ServingMenuButton.cc. FLTK was changed in svn r8639 to handle invisible menu entries differently, and thus FLTK ran into an endless loop. :-( This is something I'd call undefined behavior caused by an undefined combination of menu flags. FLTK 1.1 handled this differently, and so did FLTK 1.3.0-rc3. Nevertheless this ought to be fixed in FLTK 1.3 itself, and I found a way to fix it, but I recommend the code change as shown below anyway. Thanks for your report and the test case ;-) Note: fltk.bugs is not the right place to post problems with FLTK. If you are not sure whether it is a bug or not, please post your questions to fltk.general. If you believe it's a bug, please file a STR at <http://www.fltk.org/str.php>. Thank you. > If you care to pursue this by looking at Nut, perhaps you could also try Nut > -scheme plastic, which has never worked right. The plastic scheme only > appears on top-level things but does not penetrate into the hierarchy of > widgets within widgets. I tried the plastic scheme, but didn't see exactly what was correct and what seemed to be wrong, but I agree that it doesn't appear to be the plastic scheme for all widgets. I won't investigate this further now, but if you want to get this fixed too, please file an STR as said above, add a simple test case that shows what you think is wrong, and explain what you would expect to be different. This way it won't be lost in the bit bucket... Albrecht Patch (inline, may wrap): --- nut-16.13-ori/fltk/ServingMenuButton.cc 2011-02-16 20:33:31 +0100 +++ nut-16.13/fltk/ServingMenuButton.cc 2011-07-17 17:14:08 +0200 @@ -74,6 +74,7 @@ pulldown[resultcount / 3 + 1].label("Save the current serving as the default but I will enter a new serving unit"); pulldown[resultcount / 3 + 1].labelsize(FontSize); pulldown[resultcount / 3 + 1].callback(menu_cb, (void *)-1); +pulldown[resultcount / 3 + 2].flags = 0; Fl::check(); } _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
