5 Replies Latest reply on May 1, 2013 11:59 AM by Stephen Huston

    Runtime solution trying to give me grey hairs




      I've made a runtime solution that has a menu to create date stamped backup copies of the database file on the Desktop.


      If I double click one of these copies, it acts as though it were just a shortcut and opens the original database file (which is clear to see, because the database filename appears in the window title bar and any changes made are saved in the original database).


      However, if I already have a database window open and do the above, it does open the copy (i.e. the two window title bars reflect their filenames and making changes in one database doesn't affect the other).


      Can anyone explain the above to me? (don't necessarily need to fix the above - it might even be desired behaviour, as long as it's consistent and not otherwise problematic - I just want to make sure I understand it properly)


      Kind regards,


        • 1. Re: Runtime solution trying to give me grey hairs

          a runtime will always open it´s primary file in front, so double clicking a copy will open the runtime program, but also the primary file instead of the double clicked copy.

          • 2. Re: Runtime solution trying to give me grey hairs

            Hi intex,


            I understand that this is happening. I'm looking more for the reason why it's implemented this way (seems user hostile to double click a file and have a different one actually open) and whether this behaviour is consistent/documented on both Mac/Windows (i.e. if the copy is double clicked when the database is already open, then the copy will be opened).


            Kind regards,


            • 3. Re: Runtime solution trying to give me grey hairs

              it was this way since I can think. It is this way - at least I believe so - because the Runtimes very much are based on the principle of one main / primary file and perhaps a lot of helper files. In this concept the primary file has the main menu layout and therefor has to be opened, if the application should function correctly for the user.


              Of course this doesn´t fit so much anymore with the one file / many tables concept of FM 7 and younger and the idea of a document orientated approach. It isn´t possible for example to have three or four copy databases and double click one of them to have it opened. This would only work with a full version of FileMaker, because there is no primary file.

              • 4. Re: Runtime solution trying to give me grey hairs

                I have not tried to play with this approach but I believe the problem may be because a run time solution has been bound to only the original file.  If you want to open the new copy then you will have to bind this to the original solution - which I think will be a total waste of time.  If the computer the solution is running on has filemaker installed then there really isn't a need for a standalone runtime solution.  Maybe this is why it is opening the saved copies when the original is already open?? Does it already have filemaker installed??  it would be interesting to know if backup copies are being opened on a computer that does not have filemaker installed.


                I might sugest that if you want back up copies you may be better off exporting the data.  This way, if there is ever a problem with the original file, you could import the lastest saved export.  it may be a bit round about but it may also be the best way for you.

                • 5. Re: Runtime solution trying to give me grey hairs
                  Stephen Huston

                  Intex's explanation is essentially correct. I found that runtimes launched by doubl-clicking a non-primary file often open the file clicked, however, if the primary file was not already open, they also open it and bring it to the front-most window, obscuring the file which the user clicked. If you have access to the Window menu, you can usually find the intended file open in a background window.


                  This is simply another limitation (known intended behavior) of the runtime file structure with its primary file defined in the runtime application.

                  1 of 1 people found this helpful