Make the settings a table in the database.
From the iPhone of Ron Smith
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.
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.
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.
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)?
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.
1 of 1 people found this helpful
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:
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 …
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).
[…] 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.
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...
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.
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.
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.
Filemaker can only access specific paths in it's calculation engine via functions like Get(DocumentsPath), Get(SystemDrive) and Get(TemporaryPath).
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:
Yeah, I always forget about the free stuff.