9 Replies Latest reply on Feb 13, 2012 9:21 AM by pedantic

    Calling an external script

    pedantic

      I've been looking at the Perform Script command and I don't see how it can work for a malleable path. What I mean is, on the Mac, let's say I want to call a script in the file I call "fishes of the world." If I am working on the Mac, on Cathy's machine her path to that file might be /Users/Cathy/Desktop/Menagerie/Fishes of the World.fp7. On Thomas' machine, the path might be /Users/Thomas/Desktop/Menagerie/Fishes of the World.fp7. And on Jeremiah's machine it might be /Users/Jeremiah/Desktop/Menagerie/Fishes of the World.fp7. Yet when I create a data source for a Perform Script command, I am not given the opportunity to perform any kind of calculation to adjust the path according to the current user's path to the desktop.

       

      So how does one create a Perform Script command for an external script when the path to the file containing the script varies?

       

      TIA!

       

      John

        • 1. Re: Calling an external script
          mdumas

          Hi John,

           

          I set a variable $filepath first using... Get ( DesktopPath ) for saving out files.  I have never run a remote script before though.

          • 2. Re: Calling an external script
            pedantic

            Thanks.  The "Get(DesktopPath)" tip was worth your post all by itself.  I spent an hour earlier today writing a complex function that provided me with the same info.

            • 3. Re: Calling an external script
              powella

              Thats a good one. I don't believe it can be scripted.

               

              There are a few options though. In the Manage → External Data Sources, you could alter the file path for Fishes of the World to include all of the possible file paths. Note it will open the first one it finds in order of the list you give it.

               

              Another ability is to open files with a relative path, which is good if you know the current file will be together with the Fishes of the World file.

              • 4. Re: Calling an external script
                pedantic

                Alas, I may be well and truly,,,well never mind. 

                 

                The files are in two separate folders, though on the same level.  But alas, this is an old project and the previous caretaker password-protected the project after disabling a number of menu options, including the manage data source dialog.  Then, he failed to let anyone else know what the password is.

                 

                Nevertheless, thanks for the tips.  They are options I had not considered because I did not know about them.

                • 5. Re: Calling an external script
                  pedantic

                  Well, I found it in the documentation; powella  is correct.  Variables are not allowed in the path descriptions of data sources so it looks like I am going to have to find another  way to make this happen.  Thanks all of you who participated in the discussion.

                  • 6. Re: Calling an external script
                    beverly

                    no, they are not. use globals, and/or pass variables with the Script Parameters.

                     

                    Beverly

                    • 7. Re: Calling an external script
                      pedantic

                      Thanks, Beverly for your rersponse.  If, however, variables are not allowed in a datasource path, how would using globals or passing scripting parameters make any difference?  I don't mean to be insulting.  I'm new to Filemaker and I honestly don't know.

                      • 8. Re: Calling an external script
                        beverly

                        Sorry, I misunderstood, pedantic. You have the SAME file on various desktops. Why is this not on FMS or on one machine with peer-to-peer sharing? then there would be ONE path for all. Files would be relative to each other (regardless of folders, or included in the path). I guess I want to know why each person has their own copy of the same file...

                         

                        Beverly

                        • 9. Re: Calling an external script
                          pedantic

                          No problem and thanks for asking.

                           

                          Here's a short description of the step-by step process:

                           

                          1.)  We get a bunch of CDs from a vendor.  There is a one-to-one correspondence between the CD and the customer.  So I have a CD for John, a CD for Cathy, a CD for Fred, and so on.  Each CD has unique data that only belongs to John or Cathy or Fred, etc.

                          2.)  Before we can use the data on that CD to do our part in the manufacturing process, we have to pass that data onto our customers in a way that is easiest for them to edit.  So we create FM runtimes for each person, one for John, one for Cathy, etc.  In the past (that means in FM6) that meant we make one runtime  and then swap out the database after processing the data on each CD received from the vendor.

                          3.)  So instead of building one big databse with hundreds of customers' info in the same database, we have several separate databases (and several separate worker bees) that import data from the vendor CD, process them and then spit the processed data out to the runtime.  We copy the runtime onto a CD and mail it to the customer who massages the data and returns the information to us by email in an XML file.

                           

                          Why didn't we do it the way you suggest?  Probably because the first person to start programming this system was new to the whole database universe and didn't know he could.  Then why didn't we change it once we knew better?  Well the Navy has an apothegm that is probably how management thinks in this company:  "if it ain't broke, don't fix it."  The system worked, and worked well, so why change it?

                           

                          I also suspect that the separate-CD-per-customer might have influenced the design decisions.

                           

                          So why change it now?  The FM6 system does not work (I am told) on the most recent versions of OS X. AND the company wants to do the least amount of work needed to make it work on FM11 because there is discussion about trying something completely different, someday...whether that will happen is something to be decided at a (much later) date and is out of my hands.

                           

                          So for now I am trying to make the FM6 code work in FM11. 

                           

                          I hope that answers the question. 

                           

                          Take care.