1 2 Previous Next 29 Replies Latest reply on Mar 16, 2014 3:21 PM by nickorr

    Storing Application or User Settings

    rmittelman

      I am a longtime Windows developer, using VB, VB.Net, C#, etc. and am making the (sometimes) painful transition to FMP. In a Windows-based application, I would either save settings in an INI file (old days) or an XML file (newer days) or in .Net in one of the provided settings areas.

       

      Now, I'm looking for guidance on how this should be done in FMP. A given solution may be for Windows, or Mac or GO for that matter.

      In my past experience, it seemed more reasonable to have an external file that the application would read during startup.

      A simple example of an application setting would be the location of the folder where documents are created by FMP, such as when a user chooses to save a report as a PDF.

      Can somebody suggest best practice for storing application settings in FMP?

       

      Thanks...

        • 1. Re: Storing Application or User Settings
          RonSmithMD

          Make the settings a table in the database.

           

          From the iPhone of Ron Smith

          • 2. Re: Storing Application or User Settings
            mark_b

            Like Ron said, create a Settings table with fields that contain all the info you want.  Then create a Startup script that goes to that table and loads the various fields into global variables ($$) that can be referenced throughout your application in other scripts - such as send a pdf to $$pdfFolder.  With the Settings file, you can even add a UserID key field so that settings could be specific per user.  Hope this helps.

            Cheers, Mark

             

            I am familiar with the frustrations of learning Filemaker when coming from another environment.  I now love it, where at first I hated it because it was so different and my productivity went down the drain.

            • 3. Re: Storing Application or User Settings
              wimdecorte

              it kinda depends if you want the settings to survive the application being removed and then reinstalled or upgraded.  You can certainly come up with an Xplat way of storing (exporting) those outside of FM, or you can use the OS-specific features to say write to the registry on Windows or a plist on Mac.

              If the settings are confidential then encryption is needed and adds a twist.

              • 4. Re: Storing Application or User Settings
                rmittelman

                Thanks Mark.  Would the proper way be to have a layout for the settings table and set those variables by opening the layout, or just the table and use PerformSQL to get those values (and write them back as they change)?

                • 5. Re: Storing Application or User Settings
                  rmittelman

                  Thanks for all your suggestions.  As Mark says, it's not easy to change your way of thinking when you are so accustomed to doing things differently.  Like thinking in Italian instead of formulating your statement in English then translating it, this takes a while...

                   

                  This brings up a question which is a bit off-topic, but related, and hopefully some advice can be had:

                   

                  When I write applications in MS Access, the prevailing wisdom tells me to make the application in a front-end database, and store the data tables in a back-end database, which the front-end DB links to.  This provides for easily running the application locally, with each user being able to read/write the same back-end database seamlessly.

                   

                  I understand FMP is a totally different architecture, and hosting the solution in FM Server is the preferred way to do things.  The Access method, however has a huge advantage.  When my customer needs some enhancements, I can take the most current version of the database back to my office, and work on those enhancements for days or weeks, then simply install them on customer's PCs, re-link to back-end database, and all is good (for this example, assume program logic changes only, no data structure changes).

                   

                  How is this scenario properly handled in FMP?  How can I work on program enhancements, then reinstall the solution without losing any data entered by customer in the meantime?

                   

                  Thanks in advance for any suggestions.

                  • 6. Re: Storing Application or User Settings
                    mikebeargie

                    You're talking about the data separation model, which is not unique to access and can be done in FileMaker.

                     

                    There are advantages and disadvantages to it. Here are some resources on the subject:

                     

                    http://www.seedcode.com/pmwiki/pmwiki.php?n=SeedCodeComplete2.SeparationModel

                    http://www.filemakerpapers.com/papers/201106dataseparation.html

                    http://www.dwaynewright.com/filemaker-thoughts/2011/5/24/why-try-the-filemaker-separation-model.html

                    1 of 1 people found this helpful
                    • 7. Re: Storing Application or User Settings
                      erolst

                      rmittelman wrote:

                      Like thinking in Italian instead of formulating your statement in English then translating it, this takes a while...

                      But there will come the time when translation is no longer necessary (neither syntactically nor semantically), because the new wiring has settled. Take it from someone whose native tongue isn't English …

                      rmittelman wrote:

                      How is this scenario properly handled in FMP?

                      That would be the “separation model”, about which you can find tons of threads and intros (and I just see that Mike has given you some pointers).

                      rmittelman wrote:

                      […] and use PerformSQL to get those values (and write them back as they change)?

                      Global fields are accessible throughout the entire file, so you don't need ExecuteSQL (aka – as of now – “PerformSQL” …; and you couldn't write back values anyway, since PE…SQL at the moment is “read-only”, supporting the SELECT statement exclusively.)

                       

                      From any context, simply reference the global fields to read them, and use Set Field [] to write to them. You don't need to go to a layout based on the field's table, or, for that matter, even have one.

                      • 8. Re: Storing Application or User Settings
                        rmittelman

                        Thanks @erolst.  I understand what you are saying about the context of global fields, but I was asking about getting the data into them in the first place.  I see now that my question was premature.  I still have not begun to THINK like an FMP programmer (hence my language analogy).  Of course setting a variable, global or otherwise, has nothing to do with a layout.  I simply need to SetVariable from whatever table in my startup script, and SetField into whatever table from my global variable in shutdown script (or more often, when the value changes, depending upon program architecture).

                         

                        One of these days I will get it...

                        • 9. Re: Storing Application or User Settings
                          rmittelman

                          Mike, thanks so much for those links.  I have read through all of them, and they were quite helpful.  The consensus I get was that data separation is definitely called for in cases where an application is likely to develop over the months and years.  How many different files is another issue, depending upon complexity of application, and customer needs.  This is something I am quite comfortable with, being an Access developer.  But, I will need to learn the intricacies of doing this "the FileMaker way", which seems more complex than with Access (some scripts go here, some there, reports there, etc.).

                           

                          I appreciate the quick responses from everybody, and the willingness of this community to work with new developers.  With only few exceptions, I have experienced a "no question is too basic" attitude from the forum.

                          • 10. Re: Storing Application or User Settings
                            rmittelman

                            Just out of curiosity, how would you find a file or folder in FMP?  I have created a Settings table, one field of which is "Document Folder", a text field.  In this field will be kept the file location for exported files.

                             

                            In Windows, I would call up an open file dialog or a folder browser and navigate to the folder or file I wanted.  If chosen, that name would go into the text field.

                            How can I do this in FMP?  I tried googling, but can't really find any techniques.

                             

                            Thanks...

                            • 11. Re: Storing Application or User Settings
                              mikebeargie

                              If you need a file selection dialog with a text result placed to a field, then you need to use a plugin like Troi File.

                              http://www.troi.com/software/fileplugin.html

                               

                              Filemaker can only access specific paths in it's calculation engine via functions like Get(DocumentsPath), Get(SystemDrive) and Get(TemporaryPath).

                              • 12. Re: Storing Application or User Settings
                                erolst

                                Or have a look at the free BaseElements plugin: https://github.com/nickorr/BaseElements-Plugin

                                • 13. Re: Storing Application or User Settings
                                  mark_b

                                  To access folders and other functions I use the FREE BaseElements plugin. http://www.goya.com.au/baseelements/plugin

                                  These are some of the file functions available with this plugin:

                                  • BE_CopyFile
                                  • BE_CreateFolder
                                  • BE_DeleteFile
                                  • BE_FileExists
                                  • BE_ListFilesInFolder
                                  • BE_MoveFile
                                  • BE_ReadTextFromFile
                                  • BE_SelectFile
                                  • BE_SelectFolder

                                  Cheers, Mark

                                  • 14. Re: Storing Application or User Settings
                                    mikebeargie

                                    Yeah, I always forget about the free stuff.

                                    1 2 Previous Next