4 Replies Latest reply on Oct 9, 2012 7:17 AM by fmpros

    External file management problem


      I have B&W graphics in externally stored secure container fields. I want users to click on the container (or an "Edit" button) and have the graphic open in it's native app for editing. Then close, save the file. Then click an "Update" button to update the graphic in the container field. Nothing special, I have had this working for years in an old V6 program using Windows OLE. For the edit I use Export Field Contents, automatically open.... fine. User can edit and save. But if I use Insert Picture (they're jpegs) for the Update I get an error that the file can't be found. Sorry, I export the file to the FileMaker Temp folder with the record UUID as file name and get the extension from parsing GetAsText ( contanier ). If I use Insert File it works fine... updates the container graphic without complaint. If I "re-edit" I get an error re accessing the file (it's still there on disk).


      So I moved it out of the FileMaker temp folder to my own temp thinking there may be something inherent in the FMP temp folder. Same problem. It appears that FileMaker has a lock on the file. So I attempted to delete the file after the "update" so a re-edit would create a new file on disk. But that generates an in-use error denying the delete (using a plugin file delete fx). Close FMP and reopen, the graphic file is still on disk, and I can run the delete script and it works fine because FileMaker hasn't touched it yet with export or import.


      Anyboby know how I can make this work cleanly so the user just clicks to edit and save and then clicks to update, repeatedly if necessary, without the collision with FMP?




        • 1. Re: External file management problem

          Try this: instead of using the automatically open option of the export field contents, use a separate "send event" script step to open the file.

          You defnitely should not try to export to the temp folder: that one gets deleted as soon as the script is done so you bascially have the desktop or the user's documents folder you can play with.  Or you have to add an additionl Send Event after the export to move the file top where you want it.

          • 2. Re: External file management problem

            Thanks Wim, I will try opening as a separate process from the export first thing in the AM. 


            As for the temp folder, at least on my development machine, the exported file (to the FMP temp folder) persists after the script is done.  I watch it outside of FMP while running the app.  My understanding was that the temp folder gets cleared when the local client shuts down and this seems to be the case running the program as a local single user, no server.  Haven't tried it yet on my client-server setup; will do that also and see if there is different behavior.


            I found similar results when creating my own temp folder in the FMP root directory and using that for processing.



            • 3. Re: External file management problem



              I have used the temp folder for similar setups.   When I do,  I use a unique name for each file I export/import.    I can see where the file name might be an issue when you get to the second round of edits and you export the file with the same name as one that already exists in  the temp folder.  I'm not sure how it handles overwriting the existing file.  So a possible workaround may be to append a time stamp to the UUID when you create the filename and store the current file name in a global field, or global variable or field.  So when the user goes to import the updated file,  you have the correct file name to import.  


              FileMaker should clear the temp folder when you close the program. Take a look at this KB article.

              http://help.filemaker.com/app/answers/detail/a_id/6885 and as far as Client-Server set up goes,  FileMaker will use the clients Temp folder the same way it does when you open a local FileMaker database.





              • 4. Re: External file management problem

                Thanks Bruce.  I agree.  What I'm doing is creating the filename as a global var and append a "_x" to the end right before the extension where "x" equals the "version" number.  On open/edit I check if the file is already there (the first time no so the global var is null and the version # = 1).  My update scripts just use the global var as the path so it always has the latest version in it.  If the file already exists I just increment my version number before I create the file path/name.  Pretty simple and works fine.  I'm going back to using the FMP temp folder so I don't have to worry about cluttering up the disk with a lot of files since as you state, the files are deleted on client side closing.


                Wim, I tried not automatically opening and then sending an event to open the file.  That works fine but does not resolve the problem so I went to what I'm doing above.  If I do an Insert File, no matter what I do after that, the external function "file delete" fails so FMP must still have an in-use lock on the file.  If I don't run Insert File I can delete the file easily.


                Thanks all!