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
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
