2 Replies Latest reply on Nov 14, 2011 10:53 PM by maximums

    Scripting Open File using Variable file path/name

    maximums

      Hi all

       

      Silly me I had assumed that I would be able to script a variable to open a file based on the result of the variable, ie.

       

      Set Variable [ $file , "file:/" & filename ] (where filename is the field containing the file name)

       

      but it seems the behaviour to open a file is different to the behaviour when saving/creating a file to disk because I get the following error:

       

      The file " & $file could not be opened. (Not Found)

       

      Note: The text "file:/" has been dropped from the dialog.

       

      The client requires a small file for each of their staff. This means that every time a new staff member starts with the company, a file is created from a master using their name. I had build a portal to the staff file so that each active staff member displays as a button in the portal and, in theory at this stage, they can then click a button and the file is opened. This would mean the client only needs to create the staff record (which they do already) and the file rather than the convoluted system their previous developer has created whereby many scripts to import or parse data also need to be changed to include the new user.

       

      Is anybody aware of a solution please?

       

      cheers

      Linda

        • 1. Re: Scripting Open File using Variable file path/name
          RayCologon

          Hi Linda,

           

          Unless your "filename" field contains a file path as well as a file name, you would be relying on FIleMaker to open the file from a default path (which would vary depending on whether the current file is hosted).

           

          Also, you've given us the details of your set variable step, but you haven't said how you're then trying to use the variable to open the file. The Open File[ ] script step doesn't accept variables, but requires you to select an existing External Data Source or add a new one, and then it uses that.

           

          Notwithstanding that, if the file is stored locally, one option you could consider would be to open the file by calling its path as a URL using the Open URL[ ] script command - or,  if the user files are hosted, you could calculate an fmp7 along similar lines URL to open the appropriate file. Alternatively, depending on the platform, you could use a calculated AppleScript or a VBScript to open a local file file from its path.

           

          Another (slightly circuitous) option to open local files would be to insert the appropriate file into a global container field (supplying a variable to specify the path and file name) and then use the Export Field Contents[ ] command (to place the file back into its original location) with the "Automatically open file" option enabled - thus causing the file to open.

           

          Having said all that and given you some options to consider, I have to say that there might be some better ways to accomplish the clients requirements - such as having the users all open the same file, but see their own records or their own "space" within that file - eg using privileges and/or RLA to control what each user sees.

           

          Sometimes the fact that something *can* be done a certain way (eg a separate file for each user) doesn't necessarily mean that it *should* .

           

          Regards,

          Ray

          ------------------------------------------------

          R J Cologon, Ph.D.

          FileMaker Certified Developer

          Author, FileMaker Pro 10 Bible

          NightWing Enterprises, Melbourne, Australia

          http://www.nightwingenterprises.com

          ------------------------------------------------

          1 of 1 people found this helpful
          • 2. Re: Scripting Open File using Variable file path/name
            maximums

            Hiya Ray

             

            I agree wholeheartedly with your recommendation that a file for each employee is overkill and that record isolation within a single file would be normally be more efficient. This file set is a solution written by a self taught, full time IT person who left the organization quite suddenly. There are over 30 employee files in use, many of them in use for a number of years. To change this method at this late stage would open a can of worms that doesn’t need opening. I had hope to script Open File using a dynamic file path and file name to generate the external file reference, but as outlined in my first post it is a bahaviour that works only one way...that is to save a file, not open a file.

             

            I decided that a calculated external data reference would make all scripting much more efficient whilst enabling dynamic interaction with the selected employee button displayed on the interface file. This file previously had a button per employee defined to run an individual script with individual external file references. The interface is now a portal displaying the buttonName field. Selecting the button sets a variable “$file” with the calculated external file reference below:

             

            Let ( [ numChar = Length ( Get ( FilePath ) )- Length ( Get ( buttonName ) ) ;
            path = Substitute ( Get ( FilePath ) ; "fmnet:"; "fmp7:/" ) ] ;

            Left ( path ; numChar ) ) & buttonName & " time logs.fp7"

             

            EG:  fmp7://10.0.1.3/george time logs.fp7


            thus producing a dynamic URL based on the host, the content of the buttonName field and the balance of the file name. This calculation is a field in the Staff file because it will be called on by a myriad of scripts.


            Generating the buttons is a simple relationship of 1::1 between the interface file and the staff list. The interface is a constant 1. The staff key value is also 1 and is based on any staff members who are active, ie value list of 1 formatted to display as a check box.


            The “Active” checkbox enables the users to define which employees should display in menus and the buttons described above.

             

            It’s a simple solution yet slick in it’s execution—the users love it!

             

            Thanks for your input Ray 

             

            cheers

            Linda