2 Replies Latest reply on Oct 2, 2012 9:06 AM by Oliver_Reid

    3 Interesting twists on externally stored container objects?

    Oliver_Reid

      I have a layout with a field 'container' set to external Open Storage: File is remote hosted using FMSA

       

      1

      In a layout ith this field on it I have a button which executes Set Field[Table::Container;""]

       

      I insert a picture/file/pdf xxx.pdf and commit. A copy of the pdf file and jpg thumbnail are placed in the designated the Open Storage Folder by FMS.

       

      I press my button with the following results

       

      If the container field is optimized for Images (in the Data tab of the Inspector) the both the pdf an jpg are removed form the O.S. folder

       

      BUT

       

      If the container field is optimized for Interactive Content only the jpg is removed from the O.S. folder-- the pdf stays put.

       

      I assume this is because the pdf is being "viewed" in the layout in the latter case and is locked against deletion (result is same whether or not the field is active and whether or not it is visible)

       

      So it appears that if you want to script emptying a container field and you want to recover the server storage space then do not have an interactive content optimized occurrence of the field on the current layout.

       

      2 if you 'insert picture' or 'insert pdf' you get jpg thumb of it also (unless its already a jpg). If you insert using 'insert file' you do not get the jpg and cannot interact with a pdf even if in an interactive field'. So if you need the jpg and interaction, script insert pdf or insert picture but script removal using a layout that does not incude an interactive version of the field.

       

      3 If you leave a file which is no longer the target of a container field undeleted in the O.S. Folder , and insert it again, FMS adds _1 to the file name. I will do this even if you first delete the original directly using Finder on the server . (The change of name would be an issue if you plan to directly access the file.) However if you empty the container with no interactive field instance present the file name is not changed.

       

       

      So here is my question: Does my finding this stuff interesting mean I am a total dweeb?

        • 1. Re: 3 Interesting twists on externally stored container objects?
          OllyGroves

          If the container field is optimized for Interactive Content only the jpg is removed from the O.S. folder-- the pdf stays put.

           

          I've seen a couple of comments stating similar issues, possibly something to do with file being locked as in use by OS.  Imagine worth a report, question to the mothership.

           

           

           

          if you 'insert picture'  or 'insert pdf' you get jpg thumb of it also (unless already a jpg).

           

          If you insert using  'insert file' you do not get the jpg and cannot interact with a pdf even if in an interactive field'. So if you need the jpg and interaction, script insert pdf or insert picture but script removal using a layout that does not incude an interactive version of the field.

           

          I came across this the today at a client.  I'd written an 'Insert File' script step with all settings I wanted but when back today I noticed some PDFs weren't interactive.

           

          Turns out one user had been using right click Insert File on container field.  And turns out this is the old school 'Insert File' (view file as static icon) but the new 'Insert File' script step (and Drag & Drop) is new FM12 method which sets as interactive by type etc.

           

          Basically its best to use script driven 'Insert File' everywhere and avoid letting user right click field to insert (unless thats what you want).    

           

          I've got around balancing interactivity vs not allowing right click in field by

           

          - turning off field entry in inspector on container field in main layout, 

          - button to 'Add File'

          - button to 'View File' which pops viewer layout for interactive view of container (where field access allowed) - still open to right click errors in that view i think but not a big deal for now.

           

          I asked the lead dev about new 'Insert File' script step vs other Insert steps at Devcon.  He said can just use Insert File script step for inserting any files,  it does all the file type / set interactive if possible stuff for us (drag & drop same behaviour).   e.g if PDF file will give a Interactive view if set as interactive on layout.   Other Insert steps mainly for backward compatibility as I understand.

           

           

          If you leave a file which is no longer the target of a container field undeleted in the O.S. Folder , and insert it again, FMS adds _1  to the file name. I will do this even if you first delete the original directly using Finder on the server . (The change of name would be an issue if you plan to directly access the file.) However if you empty the container with no interactive field instance present the file name is not changed.

           

          This one is expected behaviour, the rule is if you wanna do anything with that file (other than copying it off somewhere) you need to manage it through the filemaker UI. Filemaker see's that external file as part of the database just as it did when it was an embedded container.

           

           

          Does my finding  this stuff  interesting mean I am a total dweeb?

           

          I may have just out dweebed you.

          1 of 1 people found this helpful
          • 2. Re: 3 Interesting twists on externally stored container objects?
            Oliver_Reid

            Thanks

             

            Your point on the new options of the Insert File script step is helpful. I had overlooked trying them -- if you select 'Display/Content of File' in Dialog Options when inserting this command into a script or attaching it to a button, you will get interactivity if a field instance on a layout is set to provide that.