Many of the systems that we build and maintain are made up of multiple FileMaker files grouped into separate modules (a module being a single file or a group of files).
We typically have a "front door file” that is the one that we point our launcher file to.
Usually not every user needs to load every module ever time they log in.
For any given user, there are 3 types of modules. Modules that they:
open each time they go into the system
sometime open
never open
We want each module file that a user opens to open in a way that we specify (layout, window size, etc.). Default window size and other setting can change over time, for example, we might resize screens to fit bigger monitors and/or change the startup layout. These changes are “set before hosting” and we want to override the set before hosting defaults using an OnFirstWindowOpen script.
In the [1st] case, we can the correct set of Files by branching by account/group in the OnFirstWindowOpen (OFWO) Script trigger (located in system’s "front door file”).
The [3rd] "never open" case is obviously easy to handle.
The challenge is the [2nd] case were we sometime open files. While there are files that we do not always want open, they sometimes those files get "pulled open” (or example, if there is a portal on a layout). Then, if and when the user needs those Files open, the OnFirstWindowOpen (OFWO) Script trigger does NOT run (because the First Window has already Opened).
An example of the [2nd] case is a system with Files…
MainMenu
Contact
Invoice
Project
Event
We might explicitly open the first 4 files (running the OFWO scripts) and notice that the 5th file is pulled open because there is a count of related events show on a Contact layout. When we navigate to the event table the OFWO script in Event will not have run and will NOT run.
One way to work around this is to…
have a $$var like $$<name_space>_OFWO_HAS_RUN for each file that is initiated by the OnFirstWindowOpen (OFWO) Script trigger.
use an OnWindowOpen script trigger to check $$OFWO_HAS_RUN, and if empty, run the OnFirstWindowOpen (OFWO) Script.
This is a hosted solution? Then I would use a global field for the flag, so you don't fill data viewer with a lot of such $$ variables.
Also you may want to just call a script in the destination file always you go to the file, so it can do the check within the file. (central place to check the flag)
There are many ways of developing modules, so many ways of achieving this.
We use MVC… and separate each into its own file. Let's assume you do something similar like separating data and interface, your example would open the data file but not the interface file. Assuming only the interface files need the initialization routines you are talking about, there should be no problem. Extend that a little more when dealing with more than two files for each module and I think you get the idea.
I think @MonkeybreadSoftware's suggestion of using global fields is excellent. We create a session table in each file and then create standard scripts to manage file sessions for this purpose.
There are a whole lot of other ways but I will not get into them.
The problem with global fields, is that you cannot assume that they are empty when you start your solution.
If the global field still contains a value after being run and closed locally, then every time you first open the hosted file the global Field will already contain a value - messing up your start logic completely!
Moreover, resetting the global field in an OnLastWindowClose Script can cause closing problems in multi file solutions with many relationships to other files (due to long or infinite close loops)
THUS the best implementation choice in my opinion is a global $$ variable. This may clog up the Data Viewer, but it is guaranteed to be empty when the file first opens. (Caveat: be careful when allowing users to log out and re-log-on without closing files - you need to make sure you reset all such global variables)
I have just implemented a Debug button on our internal developers layout which simply toggles $$debug between „“ and 1 (a ‚truelean‘). This is leveraging the same benefit - that you can be sure never to accidentally leave debugging on for the next session !
In order to get global fields in a defined state, the second script at startup (after verification of file & plugin resources) sets all globals to defined values, in all files of the solution.
@Torsten — are you saying you have multiple startup scripts? If so, could you explain the rationale? One reason would be that a subscript may be called independently at other times. Are there other reasons?
Sorry, I wasn't entirely clear about that. There is 1 startup script that launches when the user opens the user-facing file (has UI and business logic) of the solution. This script first checks the availability of other files, calls a sub-script that checks on Plugins and updates them if required. If all went well until now , it calls a sub-script that sets globals in all concerned tables of files belonging to the solution to defined values. The last sub-script does session-specific settings, like UI language, menue set etc.