From: lifeatt...@gmail.com
Sent: 27 July 2022 15:07
To: fltk.general
Subject: [fltk.general] Re: Does Fl_Image always release the lock on the fileit is reading
--
Thanks,
I didn’t think it would be a problem. I’ll need to look elsewhere if it happens again.
I am running on W10 using the libraries from fltk. FLTK 1.4.
Phil.
On 7/26/22 07:59, 'pvr...@btinternet.com' via fltk.general wrote:
I have noticed that I am not allowed to update a file after I've opened it with Fl_PNG_Image.
Are you certain it's not another process/program holding the
file open?
This sounds like Windows; I've noticed when editing images if
I have things
like image browsers/previews or sometimes even folder browsers
open, I
find I have to close them before I can update the image e.g.
from a paint
program.
So try closing all apps/windows/browsers except
your image editor
and FLTK app.
If it still acts like it's locked, and then
closing the FLTK app makes it
work again, let us know, as that would be a sure sign
something is wrong.
(Also make sure your own app isn't doing an fopen() on the
file and leaving
it un-closed during your image write)
Small Windows/WIN32 digression:
FLTK's png library internally uses fopen()/fclose(), and would appear from the
code to be doing this correctly (at least in 1.4.x), opening the file only briefly
to load it into memory.
Once fclose() is called, any "write lock" (described below) should disappear.
While FLTK does not use 'file locking', it does use fopen(), and IIRC
under Windows a file opened for read with fopen() will prevent other
processes from writing, due to the C library's implementation of the
fopen() function, which I imagine is just implemented as a call to the WIN32
CreateFile() function, which has the concept of FILE_SHARE_XXX flags.
I believe the fopen() wrapper /probably/ passes 0 for the 'file share'
parameter which blocks writing of the file while fopen'ed for read
(you get "A sharing violation occurred" from other programs)
which is something of a 'file lock'.
But that would only be a problem if the file remained open, and from what I
can tell, FLTK fopen()'s the file, reads it, then fclose()'s it again, so it should
not remain locked after the file was loaded into memory.
I'm guessing some other app has the file open, like a browser
or image
previewer, or some such.