Learning About the Environment

FileMaker has two categories of functions whose job it is to tell you information about the environment ”the computing and application environment, that is. These are the Get functions and the Design functions. There are over 70 Get functions, and 20 Design functions, all of which are presented in detail in Appendix B. Here, our goal is to give you an overview of the types of things these functions do and some of the most common uses for them.

Get Functions

In previous versions of FileMaker, these functions were known as the Status functions. Now known as Get functions, they provide a broad array of information about a user 's computing environment and the current state of a database. None of the Get functions take parameters; each simply gives you some tidbit of information that you can use however you wish.

As an example, the Get(TotalRecordCount) function returns the total number of records in some table. One typical use for this is as the formula for a calculation field. If you have hidden the status area from users, this field could be used as part of constructing your own "Record X of Y" display. If you're using this function in a script ”or any Get function, for that matter ”be sure that you're aware that the active layout determines the context in which this function is evaluated.

Whenever you use a Get function as part of a field definition, you need to be acutely aware of the storage options that have been set for that field. For Get functions to evaluate properly, you must explicitly set the calculation to be unstored. If it not set this way, then the function evaluates only once when the record is created; it reflects the state of the environment at the time of record creation, but not at the current moment. Setting the calculation field to be unstored forces it to evaluate every time the field is displayed or used in another calculation, based on the current state of the environment.

Although you don't need to memorize all the Get functions, a handful are used frequently and should form part of your core knowledge of functions. To remember them, it's helpful to group them into subcategories based on their function.

The first subcategory includes functions that reveal information about the current user:

 Get ( AccountName ) Get ( ExtendedPrivileges ) Get ( PrivilegeSetName ) Get ( UserName ) Get ( UserCount ) 

Another subcategory includes functions that are frequently used in conditional tests within scripts to determine what actions should be taken:

 Get ( ActiveModifierKeys ) Get ( LastMessageChoice ) Get ( LastError ) Get ( ScriptParameter ) 

There are four functions for returning the current date and time:

 Get ( CurrentDate ) Get ( CurrentHostTimeStamp ) Get ( CurrentTime ) Get ( CurrentTimeStamp ) 

Many Get functions tell you where the user is within the application and what the user doing:

 Get ( FoundCount ) Get ( LayoutNumber ) Get ( LayoutName ) Get ( LayoutTableName ) Get ( PageNumber ) Get ( PortalRowNumber ) Get ( RecordNumber ) 

And finally, another group of functions reveal information about the position, size , and name of the current window:

 Get ( WindowName ) Get ( WindowTop ) Get ( WindowHeight ) Get ( WindowWidth ) 

Finally, to see the list of Get functions in the calculation dialog, you need to toggle the view to either All Functions By Type or to just the Get functions. They don't show up when the view is All Functions By Name. Be aware that there are a number of functions with "Get" in their name that aren't Get functions. These include things like GetRepetition , GetField , GetAsText , and GetSummary . These are not functionally related in any way to the Get functions that have just been discussed.

Design Functions

The Design functions are used to get information about the structure of a database file itself. With just two exceptions ( DatabaseNames and WindowNames ), none of the Design functions are session-dependent. That is, the results returned by these functions won't differ at all based on who is logged in or what they're doing. Unlike the Get functions, Design functions often take parameters.

Fully half of the Design functions simply return lists of names or IDs of the major structural components of a file. These include

 FieldIDs FieldNames LayoutIDs LayoutNames ScriptIDs ScriptNames TableIDs TableNames ValueListIDs ValueListNames 

Six other Design functions return information about a specified field:

 FieldBounds (fileName ; layoutName ; fieldName) FieldComment (fileName ; fieldName) FieldRepetitions (fileName ; layoutName ; fieldName) FieldStyle (fileName ; layoutName ; fieldName) FieldType (fileName ; fieldName) GetNextSerialValue (fileName ; fieldName) 

The DatabaseNames function returns a list of the databases that the current user has open. The list doesn't include file extensions, and it doesn't distinguish between files that are open as a host versus those that are open as a guest.

Similarly, the WindowNames function returns a list of the window names the current user has open. The list is ordered by the stacking order of the windows ; it includes both visible and hidden windows across all the open database files.

Typically, the DatabaseNames and WindowsNames functions are used to check whether a user has a certain database file or window open already. For instance, if you have a navigation window that you always want to be open, you can have a subscript check for its presence and open it if it has been closed by the user. To do this, you would use the formula PatternCount(WindowNames; "Nav Window") . This would return a if there was no window open whose name included the string "Nav Window" .

The final Design function is ValueListItems (fileName ; valueList) . This function returns a list of the items in the specified value list. As with most of the Design functions, the primary purpose of this function is to help you catalog or investigate the structure of a file. There's another common usage of ValueListItems that is handy to know. Imagine that you have a one-to-many relationship between a table called Salespeople and a table called Contacts, which contains demographic information about all of a salesperson's contacts. For whatever reason, you might want to assemble a list of all the cities where a salesperson has contacts. You can do this by defining a value list based on the relationship that shows the City field, and then creating an unstored calculation field in Contacts with the formula ValueListItems("Contacts"; "CityList") . For any given salesperson record, this field will contain the "sum" of all the cities where she has contacts.