BlogFileMaker

Put Your Best Field Forward: Customizing Default Fields in FileMaker Pro 19

By May 20, 2020 May 21st, 2020 17 Comments

When you create a new table in FileMaker Pro 19, it starts out with a set of commonly-used default fields. Perhaps these fields aren’t exactly the ones you’d like to start out with — or maybe you don’t want to have any at all. This article will introduce you to how to configure your own set of default fields.

If you’ve configured default fields in previous versions of FileMaker Pro, you may — with a tweak or two — be able to copy just the nodes from the old file to the new one. The enclosing nodes have changed, so don’t copy them. Beyond that, you may want to skim this article to get a sense of what’s different in FileMaker Pro 19.
Comparison of default field docs

Click image to enlarge

Just about everything in your FileMaker file is stored as Extensible Markup Language (XML), and the default field settings are no exception. You can find these settings in a file called FMDefaultFields.xml at the following locations:

Mac (view)

/Applications/FileMaker Pro 19/FileMaker Pro 19*/Contents/Resources/en.lproj**/FMDefaultFields.xml

* This is the actual application package. To open it, right-click on it and then choose “Show package contents”

** You will see a series of localized folders such as “en.lproj” which is English, “de.lproj” which is German, and so on. Each of these folders contains its own FMDefaultFields.xml file. Choose whichever one matches your language preference in FileMaker Pro.

Windows (view)

C:/Program Files/FileMaker/FileMaker Pro 19/Extensions/English*/FMDefaultFields.xml

* You will see a series of localized directories such as English, Spanish, and Japanese. Each of these folders contains its own FMDefaultFields.xml file. Choose whichever one matches your language preference in FileMaker Pro.

Once you have located the default file, copy it to your desktop or another location where you can edit it. Open it up in a text editor, and you will see XML with the following structure:

<?xml version="1.0" encoding="UTF-8"?>
<FMDefaultFields>
	<ObjectList>
		<Field id="1"...>
			[subnodes describing field options]
		</Field>
		<Field id="2"...>
			[subnodes describing field options]
		</Field>
		...
		<Field id="5"...>
			[subnodes describing field options]
		</Field>
	</ObjectList>
</FMDefaultFields>

The customization process simply involves making changes to the nodes. You can modify them, remove them, or add new ones with appropriate XML representations of the fields you’d like to have created automatically. Of course, the tricky part is getting the XML correct.

One way to figure that out is to create the fields in a new file, export an XML representation of that file, and analyze the portion of the XML representing the fields you created.

Get the Sample Files

Download the sample files to follow along with with my instructions.

  1. In FileMaker Pro 19, select File > Create New to start creating a new file. A FileMaker Pro dialog window appears, showing various file options.
  2. Select the Blank option and click the Create button. A file dialog appears.
  3. Name your file DefaultFieldsTemplate.fmp12 and click the Save button. The file is created. If you have enabled the preference Use Manage Database dialog to create files, the Manage Database dialog appears. If you have not, select File > Manage > Database… to open this dialog.
  4. Modify the fields in this table to meet your requirements, changing, deleting, and adding fields as you choose. The resulting table should include only those fields that you want as your defaults.

For example, I like my primary key to start with “__pk_TableName” so that’s what I call the field (substituting the actual table name later). Now that the FileMaker Migration Tool helps to coordinate serial numbers during data migrations, I find that I prefer serial numbers to UUIDs, so I make that auto-enter change too.

I’ve found that requiring these fields to have a value has gotten me into hot water, so I also remove that requirement from all of them.

Also, while I rely heavily on the standard metadata fields such as Creation Timestamp, CreatedBy, ModificationTimestamp, and ModifiedBy, I make some tweaks to them:

I prepend a “z_” to them to group them together as utility fields. And because I have a thing for parallel grammar (I believe that it reduces cognitive load), I call the timestamp fields “z_CreatedOn” and “z_ModifiedOn” to match “z_CreatedBy” and “z_ModifiedBy”. I also prefer to record the host timestamp rather than the local timestamp of the user, as this helps keep data consistent when users are in multiple time zones.

To give an example of a calculation, I’m exposing FileMaker’s internal record ID, though normally I’d set it up as an auto-enter field. Can you think of any standard utility fields which make more sense to set up as calculations than as auto-enter fields? I’d love to hear about them in the comments.

I also add a field that always contains the value 1. It’s useful in relationships and summary counts.

And finally, I include an auto-enter number field that records the number of times the record has been modified, giving me a sense of the volume of activity that each record has experienced.

  1. Once your field changes are finished, click Save to close the Manage Database window.Great! But how do you figure out the XML for the changes that you’ve made? Well, some changes – like the field names – are pretty easy to make directly to the default XML. But I recommend you compare an actual file to the default XML.
  2. Select Tools > Save a Copy as XML. A file dialog appears.
  3. Name the file FieldExport.xml and click Save.
  4. Open the FieldExport file click to view. It contains an XML representation of your DefaultFieldsTemplate database file. On Mac OS, I use BBEdit as my text editor, but there are lots of good XML editing applications available. Notepad++ works great for Windows OS users.
  5. Remove the surrounding XML that isn’t relevant to your default fields: only keep the portion in the <FieldForTables/> node click to view.
  6. I like to add a couple of lines of whitespace between the nodes. This makes it much easier for me to read the XML.

At this point, the nodes of FieldExport.xml should be pretty similar to FMDefaultFields.xml, but you can’t copy from one file to the other without making some changes.

  1. Figure out what needs to be changed and change it click to view. This can be a process of trial and error, but here are some guidelines:

DefaultStyle=”” attribute
Remove the DefaultStyle attribute from the Field node (DefaultStyle = “”). I haven’t been able to figure out what this is for…maybe some nifty future feature?

<UUID/> subnode
Remove this subnode completely. It uniquely identifies the field within the file, so it doesn’t make sense to expect it to be duplicated from one instance of the field to the next.subnode

<TableOccurrenceReference/> subnode
Remove this subnode completely. This is important. It essentially tells FileMaker Pro that you are trying to reference a specific table occurrence with a specific UUID – and that’s not going to exist in any file except the one you got it from. Even in that file, I’ve found that it seems to cause the calculation to have a context of “unknown.”

id=”x” attribute
Your set of default fields should have serial IDs starting from 1. If you are adding a new field to the list of default fields – or removing existing ones — make sure that there are no gaps in the IDs.

<TagList/> subnode
I have a lot to say about this one. If you look at the original set of default fields, the primary key field has this:

     <TagList primary="True">#_FMI_0 </TagList>

where the “primary” attribute flags this field as the primary key.

The other four default fields have this:

     <TagList>#_FMI_0 </TagList>

The “#_FMI_0 ” tag indicates that these are utility fields, which aren’t added to the default layout automatically when a new table is created.

When I perform the Save a Copy as XML command on my fresh new file – where I’ve made no changes to the default fields of the default table – the primary key field shows up with a new tag included:

     <TagList primary="True">#^FMI* #_FMI_0 </TagList>

I’m going to guess that the tag “#^FMI* ” is a new way of indicating a primary key (with the “primary” attribute included for backward compatibility). But that’s just a guess… I don’t know why it’s included on an actual instance of the field but not in the default fields file. It’s a little troubling to me that they are tagged differently. It certainly would be great to see a dictionary of the most common tags.

I’ve tried including the extra tag and not including it, and I don’t see a problem either way when a new table is created. Superstitiously, I’m going to recommend that you stick to including only utility fields in your default fields file and that you tag all of them only with “#_FMI_0 ” – adding it when it’s not there. But if you can shed more light on this, please leave a comment – I’d like to learn more!

  1. Copy the FMDefaultFields.xml file from its default location described at the beginning of this article to the following custom location:
    1. macOS (view):
      /Users/Shared/FileMaker/Shared/FMDefaultFields.xml
    2. Windows (view):
      C:/ProgramData/FileMaker/Shared/FMDefaultFields.xml
  2. Open the file in the custom location.
  3. Copy all the <Field/> nodes from your FieldExport.xml and paste them over all the <Field/> nodes in the copy of your FMDefaultFields.xml file. Your selection should start with the first <Field…> tag and end with the last <Field/> tag.
  4. Save your customized FMDefaultFields.xml file. That’s it – you do not have to restart FileMaker Pro 19.
  5. Switch to your DefaultFieldsTemplate.fmp12 file in FileMaker Pro 19 and try creating a new table.
  6. Are your custom default fields created automatically with the settings you specified? If not, review your FMDefaultFields.xml file for syntax errors. And if you discover something that I’ve missed, please let me know in a comment.

One unexpected behavior that I’ve noticed is that calculations (both regular and auto-enter) that reference other fields first appear to be commented out. But if I commit the table and then re-open the Manage Databases… window, the issue is magically resolved. Since I’m looking at a preview copy, this may be a bug that will be resolved by launch.

File Differences in FileMaker 19

In summary, although the filename has changed along with a few of the enclosing nodes, there isn’t a huge difference in the overall structure of the new FMDefaultFields.xml file. Likewise, although FileMaker Pro 19 adds some new nodes and attributes to how it represents fields, these differences are easy to accommodate as well.

So put your best field forward when starting a new file — and have some fun doing it!

Moving Forward in FileMaker 19

See more of our insights and resources on FileMaker 19 here. If you have any questions on how to leverage these new features in your solution, our FileMaker consultants are happy to help.

Mark Baum

Mark Baum

Mark is a Senior Application Developer based in Soliant's California office. Prior to joining Soliant, he was the Technical Marketing Evangelist at FileMaker, Inc., where he helped to produce beginner tutorials, FileMaker DevCon, and FileMaker Certification. Mark has 20 years of experience as a FileMaker developer in the areas of cloud integration (Jive, Marketo, and SalesForce), hospital systems, B2B telemarketing, and trade publishing.

17 Comments

  • Avatar john r says:

    Thanks Mark some helpful stuff in there…

    Wondering why you didn’t use Get ( RecordModificationCount ) as the autoenter calc on the modification count field??

    • Mark Baum Mark Baum says:

      Hi John, good to hear from you! Honestly, the function didn’t occur to me. I’m going to change the text of the article now, but let this comment stand as a grateful testament to your watchful eye 🙂

  • Avatar johnr says:

    Mark
    also pretty sure the tag line needs to be #_FMI_0 with a space after the zero

    • Mark Baum Mark Baum says:

      You’re right about this too. Even a single tag is followed by a space. I’ve made the edit now. Thank you!

  • Avatar Dan Shockley says:

    We always add the following to our default fields:

    zFoundCount – an explicitly-UNstored number calc whose formula is: Get ( FoundCount )
    — This is extremely useful for checking related-record counts without loading those related records, and much more.
    zSumAuto1 – a summary field of the “always has a 1 in it” field you mentioned above (which we name zAuto1). Also useful.

    We also often add:

    gCalcText – a global text field
    cCalcResult_asText – an unstored calc whose formula is: Evaluate ( gCalcText )
    — This pair of fields lets us create calculations on the fly in gCalcText during a script, and we can then sort records on cCalcResult_asText. As needed, we also make: cCalcResult_asTimestamp, cCalcResult_asDate, and/or cCalcResult_asNum. This technique is very useful when you use some kind of utility relationship (maybe Selector-Connector) and need to evaluate something from the context of the related record. You can put the calculation into that related table’s gCalcText and then read the CalcResult of the related record(s), perhaps even a List of that field from related records.

  • Avatar Beverly says:

    Hi, Mark!
    I noticed when testing the “TagList” (back in 17), that the `#_FMI_0 ` means the field is NOT auto-magically shown on the layout created for a new table. But using the value: `#_FMI_1 ` would then make sure the field was always placed on the layout.
    I think I tested other values and believe it’s a BOOLEAN, so 0 = not show and anything else = show.
    Now if we could just get a default label and perhaps default allow entry…
    Beverly

    • Mark Baum Mark Baum says:

      Thank you for sharing that information, Bev! So you’re saying the final number doesn’t anticipate a series of numerical codes, but instead is just a boolean. That makes sense since they didn’t make it ‘#_FMI_000 ‘ to ‘#_FMI_FFF ‘ (or something similar) to reserve plenty of possibilities.

      Who knows, maybe they are planning ‘#_[TAG]_[bool] ‘ which would actually give more options if the tag letters don’t need to have semantic meaning.

  • Avatar Peter Doern says:

    I’m having trouble adding Summary fields, specifically a Count of the primary key and ListOf primary key. They simply don’t show up; has anyone cracked this nut?
    e.g.

    #_FMI_0

    Peter

    • Avatar Peter Doern says:

      whoops, the comment engine munged my xml — ignore the example.

      • Mark Baum Mark Baum says:

        Hi Peter, good to hear from you! If you put your code between “pre” tags, it should stay intact…

      • Mark Baum Mark Baum says:

        Peter, have you succeeded in creating any default fields that reference other fields? For example, I’m thinking of a calculation that incorporates another default field in its expression. I’m wondering whether it’s even possible given the fact that such calculations (and all summary fields) include field references.

        • Avatar Peter Doern says:

          Hi Mark, I’ve been goofing around with fudging UUIDs but field references don’t seem to “take”. The best I can do with calculated fields is to embed functions within CDATA tags; field references appear to be a no-go (that I can see).

          • Mark Baum Mark Baum says:

            That makes sense to me in that we can’t predict the UUIDs for the fields being created. The alternative might be for the application to interpret the name of the field, or for some separate relative ID to be introduced, and both of those sound pretty sketchy as approaches under the hood.

            It sounds like you’re treating expressions as literal text and then going back to edit them once the calculated field is created for a given table. Is that what you’re doing, or have I misunderstood you?

  • Thanks for the article, Mark! And yes I did not find any other way but creating calculations with the correct expressions in place but knowing they will be turned to comments once loaded into an actual table.
    I thought that is not so bad, a price for a simple way to get standardised table definitions according to our standards; BUT…
    did you find also that many of the nicely defined info and tags go away when you make a copy of the table and insert it again? Even in the same file?
    The standard layout will show every field, identifiers for primary keys and alternate keys are lost :/
    Still using the functionality,
    Volker

    • Mark Baum Mark Baum says:

      Hi Volker, thank you for your comment. I’m going to try what you’re reporting here and see if it happens to me too. Cheers — Mark

Leave a Reply

Need to adjust your business processes quickly? We're helping clients use technology to keep their teams productive and running smoothly in these times of uncertainty. Our team can guide yours if you need help in these areas.

Talk to a Consultant