On 18.08.2011 18:35, MacArthur, Ian (SELEX GALILEO, UK) wrote: > OK - I stared at the num_screens thing for a bit and realised we were > initialising it to a non-zero value by calling > > num_screens = GetSystemMetrics(SM_CMONITORS); > > And then subsequently incrementing num_screens even further in the > screen_cb(...) function, thereby totally messing up the indexing into > the screens[] array...
Yep, that's what I had found, too. > Fltk-1.1 used to reset num_screens = 0 before starting to iterate over > the screen_cb(...) function so it got this right. Correct. > Anyway, I've pushed in a correction for this which seems to work fine in > my tests, and added a comment about how we might also recover the > work-area along with the screen area. (But not any actual work on that > as such...) Thanks! Looks good - including the additional cleanup. > It's a start and I believe fixes the initial problem, anyway. Does it fix it with my test ( -g 600x400+0+0 ) for you? In my case it still positions the window on the 2nd screen, just as I found during my tests before (this is as expected, since the only effective changes in both our patches was to reset the num_screens variable before enumerating the monitors). Now I wonder why there's still a difference between FLTK 1.1 and 1.3, but I can't check it now. Anyway, it's a step forward, and there are other issues with finding the correct monitor and position to display the window in Fl_X::fake_X_wm(). First of all I wonder why we first substract the border widths and then try with these modified values that may be outside the screen (e.g. [0,0] -> [-8,-30]), whereas we would probably better use the requested client area coordinates directly (in this example [0,0]) to find the correct monitor... Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
