On 07/16/11 15:33, Ian MacArthur wrote:
>> fl_register_images();
>>
> Actually, I do think this is maybe key after all...
> I've been staring at the OP's code, and his comments describe
> the failure mode, it *really* sounds like it has that sort of
> Heisenbug character that you get from unallocated buffers [..]
Looking at the 1.3 code for fl_register_images(),
I'm not so sure it does any buffer allocation.
That call seems specific to the Fl_Shared_Image class,
and related classes (which I don't think the OP is using):
void fl_register_images() {
Fl_Shared_Image::add_handler(fl_check_images); // that's all it does
}
fl_register_images() seems more related to registering a
handler function that parses magic numbers from image file
headers to determine which image format class should handle
loading an image. (ie. so that image type can be determined
by the image's contents, and not by its filename extension)
But since the OP is using Fl_PNG_Image directly, that's probably
not needed; calling that class directly bypasses the 'shared'
image stuff (according to the docs for the class hierarchy).
The individual image classes really 'should' each be handling
their own buffer allocations. But I could see where maybe some
use their own memory allocation routines that need some weird
global init, but I'd think those classes would handle that
kind of init check in their ctors.
I agree the described behavior sounds like a stray pointer
or a 'make clean; make' due to an edited .H file.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
