On 26.10.2011 05:15, Jim Jozwiak wrote: > Unfortunately, although your patch kept the app from hanging, it caused > problems when the previous pulldown menu from the previous food had more menu > items than the current pulldown menu from the current food--then there was > garbage in the extra slots.
Yep, I didn't try to fix all your code... This is probably something that you should fix anyway: if you create menus dynamically, then you should clear out the menu item after the last one you use. This is true for all sub-menus as well, so that you might need two or more zeroed menu items at the end. If you did this always, then I'm sure you won't see garbage in your menus. > Nevertheless, I am very grateful that you took the time and effort to install > my program, look at the problem and then fix fltk. I appreciate the > difficulty of decoding a novice's attempt to use fltk. > > This is why I am trying to create an simple example of the next bug I found. > If I make all the packs and windows in NUT resizable, recompile, execute, and > then show a tooltip (especially on NUT's "Options" tab), most of the widgets > on the screen stop responding to clicks, and if a menu button still works, > the pulldown menu's coordinates are shifted toward where the tooltip was. > NUT has so many zillion packs and wizards within each other that I have not > found exactly what is causing the problem so as to be able to create a simple > test case. If you or anyone has a suggestion where to look, I would > appreciate it. The NUT code I am using as a base is at > http://www.lafn.org/~av832/newnut-17.2.tar.gz . My current theory is that > when all widgets are resizable, the redraw after the tooltip (not specific to > a single widget or necessarily a single group because a tooltip plops down > however big it needs to be) somehow leaves fltk's view of screen coordinates > corrupted. Unfortunately I don't have the time to test and debug your application code (once more). Your problem is likely to have something to do with wrong data or overwriting variables in an uncontrolled manner, or something else in your application code. That's probably very difficult to debug :-( Let me add one more note: please don't post your questions (or bug reports) to fltk.bugs, this is reserved for our bug tracking system (fltk.org/str.php). The rule is to ask questions in fltk.general, and if you're sure you found a bug (or one of the dev's asks you to do so), then you should post to the above mentioned link. Thanks. In your case, this is clearly something you should ask (again) in fltk.general, (for the above reasons and) because there are usually more readers that can help you. But as I said before: it is almost impossible to find such bugs (even if they *are* fltk bugs) in a big application like yours. If you can't reproduce it in a simple example program, then it is (probably) not a FLTK bug, or at least we won't be able to fix it without a simple test case. Albrecht _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
