9 Replies Latest reply on Dec 2, 2016 9:44 AM by dsimonson

    Opening a file (hidden) without allowing its startup script to run


      I am trying to write a script for my FM Go app that opens a previous version of the app using "Open File [Hidden]" and then imports the old user data into the new version. 


      My problem is that as soon as that script step runs, the next step executed is in the startup script on the older file (it executes OnFirstWindowOpen), which I don't want.


      I tried setting a global variable $$IsUpdating = 1 flag in my new version file before I attempt to open the old version, and then put a first step in the startup script in the old version to check for the flag and exit the startup script if it sees it.  Unfortunately, once the old file is open, the global variables from my new version are unavailable to the old file.


      How can I open the previous version file without running its startup script?

        • 1. Re: Opening a file (hidden) without allowing its startup script to run

          You can actually open the file this way just by executing the import records script. Unfortunately, if your file is password protected, this will cause a dialog to open asking for a password to open the other file.


          I haven't tried this in GO, but a long standing trick for Pro is to use perform script to open the other file. Just perform a script in the file that you want to open that does not cause any problems for you--it can be a very simple script that doesn't really do anything. I suspect that this will work in Go as well.

          1 of 1 people found this helpful
          • 2. Re: Opening a file (hidden) without allowing its startup script to run

            It seems that your end result is to simply import data / records from the old version to the new version. Yes ?


            What I do is have a button (Create Update) in my versions that runs a script to creates a copy of the file (with all containers embed) with a specific name, such as Update.fmpur. Then also have a button (Update Data) in my versions, that runs a script that, deletes all records from each table in the new version, then imports records from for each table from the update file (Update Data.fmpur) to the new version. The Update file serves also as a backup for just in case unintended stuff happens. The extension .fmpur can always be changed to .fmp12. I set paths such that the file must always be in the same location as the new version. Run the old version, you create the update file, close the old version, Run the new version, update from the update file.


            No need to intentionally open the old versions.

            1 of 1 people found this helpful
            • 3. Re: Opening a file (hidden) without allowing its startup script to run

              If you wish to proceed with your method, then perhaps before importing, open the old version; with a button, set a flag field to 1, close the old version. So that next time it opens , check the flag field in the startup script, if 1, not run the startup script.

              1 of 1 people found this helpful
              • 4. Re: Opening a file (hidden) without allowing its startup script to run

                The problem with just going ahead with the importing is that I have 16 tables with user data, so asking my users to input their credentials each time won't work. 


                I like what you hinted at - perform script in the other file. To test it, I added a "Perform Script" step, and when it asked for which script, for the first time I noticed the menu at the top of the chooser window that allows me to specify another file.  Wonderful!  I had never noticed that before.


                But I'm wondering how that would work. How can I specify the file beforehand?  And if my app can't find it, will it present a file chooser window so my user can find it? 


                I like Rouelf's solution, I can ask my users to tap a button on the old file, something like "Prepare for Update" or something like that, but if I could get the Perform Script to work, that would be more elegant.  I'll try your solution first, Phil, and then move to Rouelf's.  And report back! ;>)


                I love this forum.  I can't imagine how folks like me can develop without it.  Thanks.

                • 5. Re: Opening a file (hidden) without allowing its startup script to run

                  dsiminson, look up Perform Script in the Filemaker Help menu. Study / play with it, you will find it very helpful. You will be able to answer your own questions.


                  Typically, I place all files in the same location. so that the Perform Script can find the script in the desired file.



                  • 6. Re: Opening a file (hidden) without allowing its startup script to run

                    You might want to perform a script in the old file that does a show all records on each table from which you will import data in order to be sure that all records get imported.

                    • 7. Re: Opening a file (hidden) without allowing its startup script to run

                      The list of files available in the 'Perform Script...' settings window is based on the entries in the file's External Datasources.  And there's no way to update those dynamically or on the fly in a file chooser (that I'm aware of).  If all of these files happened to have the same name and are always in the same location, then you could set up an EDS based on that name/path and it should work.


                      Is this a one-time process you want to have the users work through, or might this happen multiple times?


                      If you had access to all of these 'old' files...this will require doing things one at a time...but you could set up the script that is running onFirstWindowOpen and have it check the list of open files; if it sees that name of the new file, or perhaps even just if there is more than one file open, it could just stop running the script.


                      I do like Rouelf's suggestion of setting a flag in the 'old' file...but that would still then require opening the file.  You would have to use a field instead of a g-var because of these being different files; g-vars don't carry between files.

                      1 of 1 people found this helpful
                      • 8. Re: Opening a file (hidden) without allowing its startup script to run

                        One method that has worked well for me works like this:


                        Define a single, global container field.


                        In a script, use Insert File to open a dialog for finding and inserting the file from which you want to import data "by reference" into this container field.


                        The script then extracts the file path from that container field and uses it with import records to import the data. Open URL could be used to open this file as an early step in a script that then imports from this file from multiple tables.


                        But that was all in FileMaker Pro. I don't know if something similar can be set up to work in FileMaker Go or not...

                        • 9. Re: Opening a file (hidden) without allowing its startup script to run

                          Well, I just finished trying the Perform Script technique.  I set up a script to run in the old file as Phil suggested.  No go.  It did avoid the Startup script problem, and I got it to work fine on my desktop, but when I tried it on FM Go there was very crazy behavior.  The first thing I noticed was that it asked me for my credentials 16 times (or more, lost count), obviously it was asking for them for each import records step.  It only asked me once on my desktop run.


                          Then, it did not add the accounts like I wanted it to.  All accounts got added on the desktop run, but on FM Go, _none_ got added.  So after it was all done, I tried to sign in and was denied.  When I copied the file back to my desktop to look at it, I could see that all of the data got imported, but none of the accounts (the user accounts from the old file) got added.


                          Thinking maybe one of my steps wouldn't work on iOS, I turned on the iOS script steps option, and none of them were grayed out.


                          So I think I'm going to try your container file approach next, Phil - and then go to