FLTK logo

Re: [fltk.general] Does Fl_Image always release the lock on the file it is reading

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.general  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: Does Fl_Image always release the lock on the file it is reading Greg Ercolano Jul 27, 2022  
 

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.



--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/e4971ef8-a47c-4ae1-0317-24be3d77ffc5%40seriss.com.
Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.