Michael Surette wrote:
> On 12/30/2009 06:39 PM, Greg Ercolano wrote:
>> Michael Surette wrote:
>>> [..] Under Windows with minGW it runs well, but under Linux it dosen't
>>> display properly with anything over approximately 1300 entries. [..]
>>>
>>> I'm using fltk 1.3.x-r6950.
>> Can't test the code here; no boost.
>>
>> Usually the problem is integer x/y positions above/below 32767,
>> though I thought we now have longs in fltk 1.3.x.
>>
>> Possibly a limit of x window coords then? (I can't remember offhand)
>
> Here it is again less the boost requirement.
Thanks -- compiles and runs and I can replicate the problem.
(crashes on free() when I hit "Cancel".. not sure what that is,
but might be unrelated)
> Since each item is 25 pixels high, 32767 pixels would be just over 1310
> items. But as you say, this doesn't make sense where int is 32 bits.
IIRC, there was a signed 16 bit limitation on the xywh values
at one time, so the +/-32767 limit sounds familiar.
fltk (1.1.x) used to use short ints for the xywh values,
ie. the xywh values in 1.1.6's Fl_Widget were shorts:
--- snip
class FL_EXPORT Fl_Widget {
[..]
short x_,y_,w_,h_; // fltk 1.1.6
--- snip
This was changed in 1.3.x (where we could break the ABI):
--- snip
class FL_EXPORT Fl_Widget {
[..]
int x_,y_,w_,h_; // fltk 1.3.x
--- snip
..but I /think/ I recall there's still short limitations elsewhere;
I'm not familiar with that level of the code (at the X windows
interface).
It's either a bug or limitation, not sure.. I'd wait for the guys closer
to the core to weigh in.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
