Recovering Files For some reason, many FileMaker developers think you can recover a file and continue using it. Well, you can if you want to live your life dangerously. Recover is a great tool when used properly. The proper use of the Recover feature is to recover a file and then import the recovered data into a backup of the file which is not damaged. In other words, the Recover feature is for recovering your data not your schema. Even with the new recovery features in FileMaker 10, always remember that FileMaker assumes you are recovering a file because you have no other choice. Therefore, the Recover feature will remove any suspect scripts, fields, layouts and other features it believes could be causing the problem. While the Recover feature could completely fix your file, it's also possible it may not remove all corruption even though the file appears to be functioning properly.
For more information on recovery, see the white paper titled "Demystifying FIleMaker Pro File Recovery" by Steven Blackwell, available in the Resources area of the Database Pros web site.
Dull Boy FileMaker files were stored in clear text prior to FileMaker 7 so, if you opened a FileMaker file in a text editor, you could see the phrase "All work and no play makes Jack a dull boy" in the header repeated over and over. No, it's not a virus! My understanding is the developers just needed to take up some space in the header and that's what they came up with. Today, modern FileMaker files are stored in Unicode so I'm not sure if the phrase is still there.
So, what's wrong with the default window name given by FileMaker? Imagine a user of your solution has multiple windows spawned on a small screen and goes to the Window menu to select the desired window. Without good window management, all he sees is "CONTACTS", "CONTACTS - 2", "CONTACTS - 3" and so on. With good window management, you can make it easy for users to quickly find the window they want without cycling through all of them.
In the last couple of years, I've adopted a technique for naming windows that's fairly dynamic. Rather than hard coding the window name from each script as needed, I prefer to use a combination of a single script, script trigger and a calculation field. I still name some windows via a specific script, such as a window containing a report since it doesn't change from record to record, but standard form and list view layouts are handled automatically by a script trigger.
The Calculation Field Start by creating a calculation field that results in the text you want in the window title. The calculation result should change based on the record currently showing. I also like to include the table name. For example, a formula for a contact manager might be as follows:
"CONTACTS: " & name_first & name_last
Name the calculation field "window_title" to correspond with the terminology in FileMaker. Each table should have their own unique "window_title" field. For example, an invoicing solution might use:
"INVOICES: " & invoice_num
I usually copy and paste the field from table to table and make the corresponding text and field changes. It only takes a minute.
The Script The script is only one line, using the Set Window Title step.
Set Window Title [Current Window; New Title: GetField(Get(LayoutTableName) & "::window_title")]
The calculation formula is entered in the Rename Window section of the Set Window Title dialog.
The GetField function requires a single parameter, specifying a table and field name in order to return the contents of that field. The table name needs to be supplied since script context requires it.
The Trigger The OnRecordLoad trigger is ideal for this solution as it renames the window every time the record changes.
If you want the window name to update on new records as you fill out the fields, you'll also need to attach the script to every field referenced in the calculation using OnObjectExit. Otherwise, new record window titles will remain blank till they are navigated to again.
The only issue I have encountered is a conflict between OnRecordLoad and scripted finds. OnRecordLoad fires when transitioning from find to browse mode. This occurs after the Perform Find step, triggering the window naming script. This interrupts the find script, causing any errors that result from the find to be erased by the triggered script. The workaround is to test for not records found with Get(FoundCount) instead of Get(LastError).
My Approach I like to design my first layout with this trigger already attached. Then, all I have to do is add the calculation field to any new table, duplicate the layout and make the necessary changes interface for the current table. This is a simple but effective technique for making sure all windows are named uniquely and cuts down on user frustration, mostly for power users who like to have multiple windows open at the same time.