On 09/20/12 03:27, MacArthur, Ian (SELEX GALILEO, UK) wrote:
>>>> Fl_BMP_Image jpg("C:/Users/Marick/My Pictures/image.bmp");
>> I wonder if we could make error checking more obvious for the default
>> behavior in FLTK for this type of thing.
>>
>> I can think of three possible ways to help:
>>
>> o A global Fl::option() to control how image errors are shown
>> o An error_callback() to be called when the image can't be
>> loaded
>> o Adjust the docs + examples to include error checking
>
> Could do - though I'm a big fan of just calling access() on the path
> before I try to use it - that pretty quickly filters out any mistakes...!
> (And works on all the platforms I support too, which is handy.)
Our docs for the Fl_JPEG_Image constructor says:
There is no error function in this class.
If the image has loaded correctly,
w(), h(), and d() should return values greater zero. <--
..which seems to imply the following pattern should work:
const char *filename = "/var/tmp/foo.jpg"; // the file to load
Fl_JPEG_Image jpg(filename); // load jpeg image into
ram
if ( jpg.d() == 0 ) { // optional error
checking
fl_alert("%s: %s", filename, strerror(errno)); // post dialog showing
problem
}
However, it seems we have a bug: I just did a test with 1.3.x,
jpg.d() returned 3 even if the file doesn't exist, which seems to
break contract with our docs.
Changing the test to check jpg.w() does work though.
I've made an STR (#2873) for this.
However, I think even the above can give a misleading error message
if e.g. the file exists but is corrupt in some way, causing the above
to give a random errno message, instead of indicating the file is
corrupt.
> ..access()..
Ian: as an aside: beware of access() on windows (or well, _access())
Although I think you prefer cygwin to VS, VS has had a long standing
bug with _access() write-testing of files and directories. See:
https://groups.google.com/forum/?fromgroups=#!topic/comp.os.ms-windows.programmer.win32/sGozH_cHVuY
I actually called microsoft on that one using my VS support back in
2005.
They confirmed it, found me a Win32 style workaround, and they
filed a bug internally to fix the problem. This was 7 years ago.
Just now checked VS 2010 + Win7 to see if they fixed it..
bug is still there. (LOL, Microsoft). Just updated the above thread
with that detail.
So yeah, perhaps a good reason to use cygwin.. at least gnu fixes
stuff and their posix support is surely better.
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
