On 12/19/11 10:23, Greg Ercolano wrote: > On 12/19/11 01:40, Albrecht Schlosser wrote: >> Greg, what happens if you configure FLTK in these cases with >> --disable-xdbe?
> Yes, I can replicate the errors if I choose --disable-xdbe > running locally on my centos 5.5/64 box. > > Good, looks like that's the issue; now that we can > replicate, we can probably solve it easily. OK, spent about 1/2 hour noodling. In short: it's XDBE specific with Fl_Double_Window's only getting sized to 0 on either width or height. Details: o Changing Fl_Double_Window -> Fl_Window prevents the errors. So that seems to make it Fl_Double_Window specific. o The issue is definitely triggered when one of the tiles, probably 'child window' is resized to zero on either W or H. (I never saw negative numbers, so that's not an issue) I determined this by modifying resize() in src/Fl_Double_Window.cxx to print the W/H values. Errors only occur when W or H is zero. o I could easily prevent the problem by adding the following two lines of code to src/Fl_Double_Window.cxx's resize() method, eg: void Fl_Double_Window::resize(int X,int Y,int W,int H) { W = (W<=0)?1:W; // <-- ADDED THIS H = (H<=0)?1:H; // <-- ADDED THIS int ow = w(); ..a hack which just prevents windows from possibly being resized to zero or less on W or H. If the OP's goal is to stop the errors, that seems to do it. That's about as far as I can go. It's tricky to debug these X errors, because they don't appear to occur when our code runs, due to how X buffers commands. Is there a way to run an app in a mode where X operations occur immediately, instead of being 'buffered'? If there was, this might help debugging. Or, if someone feels confident to debug this, please feel free. Digging around in X is not something I'm good at. _______________________________________________ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk