fmp17 adv app icon

FileMaker 17: Multiple Email Attachments

Since first introduced, the “Send Mail” script step has been a useful tool for sending emails through FileMaker. However, one of the main frustrations and complaints for both users and developers has been the inability to send multiple attachments in the same email. With the release of FileMaker 17, developers will no longer have to use a workaround, such as appending multiple pdf’s to create one large attachment, sending multiple emails with individual attachments or the use of a plugin such as 360Works Email. Developers can now select multiple attachments and include them within the same email, using either a variable with a list of file paths or by specifying a list of file paths directly in the “Send Mail” Options dialog. This simple example shows how easy it now is to create an email with multiple attachments. All we need is a global variable ‘$AttachmentList’, set after each pdf is saved and separated with a return character. This variable file path is then used within the “Send Mail” options dialog to specify the list of attachments.

Script steps to create and attach multiple documents.

 

The specify attachments option allows users to select multiple file paths.

 

Email that is generated via the client showing both attachments.

While this simple example demonstrates how to create and attach documents using layouts within your application, another useful situation would be to use a plugin such as Troi File to specify all files within a folder and include them as individual attachments if you need to include external documents within your email. You could also combine both approaches if you wished to include additional documents with the files saved from FileMaker.

Adding multiple file paths for multiple attachments.

As a developer I am delighted FileMaker has finally addressed this issue in FileMaker 17 and this simple but important tweak has turned FileMaker into a far more powerful and capable communication platform.   David Roche is a FileMaker Certified Developer at Skeleton Key in St. Louis, MO.

About Skeleton Key

Skeleton Key helps turn complex, complicated, and outdated systems into true information platforms. Our team of consultants and developers do this by developing custom-fit software tools and reporting dashboards that help businesses find, use, and understand their data, freeing them to focus on and grow their core business. In addition to custom databases and applications, we also provide training and coaching for getting the most out of your existing systems and understanding your unruly data. Skeleton Key is an open-book management company and active player of the Great Game of Business.

fmp17 adv app icon

FileMaker 17: Show Custom Dialog

FileMaker Pro Advanced 17 includes some useful improvements to the Show Custom Dialog script step. The Show Custom Dialog script step now allows input to be saved to local or global variables rather than only having the ability to save to a field. Let’s take a look at what changed and why you should even care.

What Changed?

                           

    FileMaker Pro 16                                                                        FileMaker Pro Advanced 17

As you can see from the screenshots above, nothing changed on the General tab of the Options dialog. You still have the ability to add a title, a message and buttons for the dialog. You can also specify a value to any of these options as well. The changes can be seen on the Input Fields tab, as shown below.

                  

      FileMaker Pro 16                                                                      FileMaker Pro Advanced 17

Once you decide to specify an input field, you will be given the new option to save user input from a custom dialog window to a variable. Other noticeable changes include a new search function to easily find fields. There’s also been a cosmetic change to make the Repetition box wider. The option to use variables makes it easier and more convenient to work with user input. In earlier versions, the only option was to store the input values into fields, which often required extra work to retrieve the values and manage the fields. This would also require you to create fields to store user input if you didn’t have them already. With variables, you no longer need to worry about any of these issues.

Why should you care?

While having more options is always nice, the question is how does it really improve the application?

  • Fewer Script Steps

Although it might not seem like it, this will ultimately save the developer time scripting. Below are some screenshots on a report script that I created to discuss this very topic.

                   

Input in Fields                                                                         Input in Variables

As you can see from the screenshot above on the left, I would have to save the input into fields, extract the data from these fields, place them into local variables and then clear those fields so that data residing in them couldn’t be exposed later on in the application. Before version17, there was no other option so this was the only way that you could use the Show Custom Dialog script step. In FileMaker 17, I wouldn’t need to worry about writing any of these steps. The custom dialog script step now provides the option to save user input into local or global variables and then they can be used throughout the life of the script. As you can see from the right screenshot, I have saved myself from writing 4 lines of script steps. I no longer need to extract the data from fields and clear them (lines 8-9 and 17-18 on the left screenshot). You might be thinking that saving 4 lines of code doesn’t really matter but in the long run it really does. Just imagine that your database uses the show custom dialog script step quite a lot for your reports or other resources related to input in your database. If you are using the same method that is seen in my script, then you are saving yourself from writing 4 lines of code each time.

  • No More Schema Changes!

Before, you would need to add fields to one of your tables or use existing ones to save user input from the custom dialog window. With this new addition, you no longer need to. You don’t have to worry later on when migrating changes whether or not you need to migrate a certain field since this new addition to the script step doesn’t force you to link it back to a field. Now your databases doesn’t have to be cluttered with fields that you might only need to use once during your session of the application.

  • Consistency

FileMaker Pro 16 had already begun expanding the idea of targeting variables to many of their script steps. The Insert From URL, Insert Calculated Result and Insert Current Time were only some of the script steps that allowed variables to be targeted. With the ability to target variables from the custom dialog window in FileMaker Pro Advanced 17, FileMaker is one more step closer in allowing all if its features to become more consistent, dynamic and separated from the schema altogether. By creating consistency, we are provided a fundamental model that allows us to use script steps in the same manner. We no longer have to use a script step and wonder why it doesn’t have the same resources as another of its similar ability. For example, the Insert From URL was able to target variables in FileMaker Pro 16. However, as previously mentioned, the Show Custom Dialog script step did not. Both script steps have similar abilities of receiving input however, they did not have the same interaction of where they could store the input they received. This was bothersome as you couldn’t enact similar actions of all script steps. The Show Custom Dialog script step has the ability to specify a value for most of its option on its programmable interface. When specifying a value, you are allowed to use a field value or even a variable value. So if we had the option to use variables for most of the output, it should be reasonable to allow variables to receive input as well. This provides total consistency in the programmable system that FileMaker contains.

Conclusion

With this new addition to the show custom dialog script, it will bring some changes to the programmable interface and as well to some aspects of the database and for the programmer. This might not be the most exciting feature that you might have been waiting for, however it is certainly a nice addition. This feature provides more control to our programming environment and improves the way we write code. My last question to you is, how will this improve the way you write code? Post your thoughts and feedback in the comments.   Jessie Cisneros is a FileMaker 16 Certified Developer at Skeleton Key in St. Louis, MO.

About Skeleton Key

Skeleton Key helps turn complex, complicated, and outdated systems into true information platforms. Our team of consultants and developers do this by developing custom-fit software tools and reporting dashboards that help businesses find, use, and understand their data, freeing them to focus on and grow their core business. In addition to custom databases and applications, we also provide training and coaching for getting the most out of your existing systems and understanding your unruly data. Skeleton Key is an open-book management company and active player of the Great Game of Business.

fmp17 adv app icon

FileMaker 17: Selecting Objects in a Group

Grouping objects together when designing layouts is a very helpful tool and one of my favorites to use. I am very excited for the new ability to select an individual object while it is still in a group in FileMaker 17.

 

Grouping and Ungrouping Objects in Previous Versions

  If you are not familiar with grouping and ungrouping objects in previous versions here is a recap: By selecting all objects you would like to group and clicking the group button in the inspector, you can group multiple objects together even if they are different types of objects. This allows you to work with them as one single object, manipulating its stacking order or alignment, for example. It comes in handy often as I have perfectly aligned a group of fields and need to move them around to continue working on other parts of my layout without disturbing their current alignment relative to each other.

The portal inside a group is being selected in the layout objects window, notice I can adjust its appearance but I cannot adjust its position or size in the inspector.

Previously, you could not make an adjustment to a single object after it was in a group without selecting it from the Layout Objects window. The layout objects window allows you to select an object that is currently grouped and make changes to its appearance in the inspector, but you do not have the ability to adjust its size or position. You would first need to ungroup it, make your adjustment and regroup.  This could get tedious if you had many changes to make. Additionally, I find it helpful to specifically name my groups in the layout objects window so I can distinguish which group I am working with. However, the custom object name for a group is erased when the objects are ungrouped. Additionally, if you have formatted your group as a button, you will have to recreate your button and add back your script if you ungroup it.

What’s new for Grouping Objects in FileMaker 17?

In FileMaker 17, we now have the ability to select one or more objects inside of a group and make changes without affecting the other objects in a group or having to ungroup them. This added functionality makes grouping a more diverse tool to use, assists with speed of development and makes tasks like layering and hiding more enjoyable. You can now group objects together and move them around even if you know you still have to make adjustments to the individual objects inside.

Conclusion

Since ease and speed of development are often such high motivators for gravitating towards certain workflows and tools, I am pleased by the new flexibility of grouping objects together in development. For those of you who have shied away from grouping objects in development for lack of convenience, it may be time to consider putting it back in your toolbox.   Monica Blum is a FileMaker 16 Certified Developer at Skeleton Key in St. Louis, MO.

About Skeleton Key

Skeleton Key helps turn complex, complicated, and outdated systems into true information platforms. Our team of consultants and developers do this by developing custom-fit software tools and reporting dashboards that help businesses find, use, and understand their data, freeing them to focus on and grow their core business. In addition to custom databases and applications, we also provide training and coaching for getting the most out of your existing systems and understanding your unruly data. Skeleton Key is an open-book management company and active player of the Great Game of Business.

md featured image

FileMaker 17: Portals for Master-Detail Layouts

One of FileMaker 17’s most exciting new features is the ability to configure portals to display records from the current table. This allows us to easily create master-detail layouts.

What Is Master-Detail?

Master-detail is a very common and powerful UI design pattern. The basic idea is that a single screen or interface displays both a master list of items as well as the details for the currently selected item. While it is most common to see the master list at left and the selected detail at right, the two sections can also be arranged vertically or even stacked. Master-detail interfaces are used for all sorts of applications and functions: email and calendaring applications, media players, file browsers—the list goes on.

Image: Master-detail interfaces are everywhere

Master-detail interfaces are everywhere—Microsoft Outlook, Mac Notes, and Netflix are just a few

Past Trouble with Master-Detail in FileMaker

While master-detail is a well-established and familiar design pattern, it has historically been hard to construct in FileMaker. To start with, we can only configure a layout for list view or detail view, but not both. And while we’ve been able to use portals to display a list of records in a detail view layout, portals could only display records from a related table occurrence. For example, say we want to build a screen that displays a list of contacts on the left side and the detail for a selected contact on the right side. We would typically approach this by creating a detail view layout based on our Contacts table and then adding a portal on the left to display our master list of Contact records. However, since portals could only display records from a related table, we had to create a separate table occurrence as well as a relationship to it, and then base the portal on that TO. This could be done using a self-join, a virtual list, or some other technique; but in all cases, additional development was required to handle navigation to the selected record in the portal as well as to keep the portal in sync with the found set and sort order of the current table. Lots of folks in the FileMaker developer community have gone to considerable effort to create elegant solutions for the master-detail design pattern, though with that came lots of extra code to maintain.

Native Master-Detail in FileMaker 17

All that trouble has been eliminated for us in FileMaker 17. We now have the ability to have portals display records from the current table:

FileMaker 17 portal setup dialog

New portal setup dialog in FileMaker 17

Note that when Current Table is selected in the portal setup dialog, the options for Sort and Filter are grayed out. That’s because this new type of portal comes with its own special behavior. The portal sort order automatically matches the sort order of the current found set, and the records displayed in the portal also automatically match the list of records in the current found set. Essentially, the current found set is the portal filter. An additional new behavior we get with this portal configuration is that simply clicking on a portal row will make that the current record, with no button setup or scripting required. So, we get a simplified relationship graph, sorting, filtering/searching, and navigation, all for free. Pretty powerful stuff!
Animated GIF: Native finding, sorting, and navigation behavior with master-detail portals in FileMaker 17

Native finding, sorting, and navigation behavior with master-detail portals in FileMaker 17

Designing for Master-Detail

Since it’s now so much easier to build master-detail interfaces in FileMaker  17, we can spend less of our development time on the nuts and bolts of the basic design pattern and more of it on additional features to deliver more value to our users. In the below example, I added selectors for sorting and filtering directly above the portal to mimic the kind of options commonly found in an email client. The pop-up menu fields have OnObjectModify script triggers that perform customized sort and find scripts. Because the portal automatically reflects the current found set and sort order, there’s nothing else to it!

Animated GIF: Extending the master-detail UI with custom filtering and sorting

Extending the master-detail UI with custom searching and sorting

There is a new function in FileMaker 17 that we can use in conjunction with master-detail portals: Get (ActiveRecordNumber), which returns the number of the active record, regardless of the calculation context. This differs from Get (RecordNumber), which returns the record number within the context of the calculation; this may or may not be the active record. This is illustrated below. I’ve added a button to the portal row which sends an email to the selected record. I only want the button to appear on the selected portal row, so I have a hide condition set on the button for Get (RecordNumber) ≠ Get (ActiveRecordNumber). This works because Get (RecordNumber) returns each record’s sequential record number in the found set (e.g. row 1 = 1, row 2 = 2, etc.), but Get (ActiveRecordNumber) returns the number of the active record, regardless of the row the calculation is being evaluated on (e.g. if the active record number is 5, row 1 = 5, row 2 = 5, etc.). Note that Get (ActiveRecordNumber) can be used similarly with a list view layout.
Animated GIF: Using Get(ActiveRecordNumber) to conditionally display a button in the master list portal

Using Get(ActiveRecordNumber) to conditionally display a button in the master list portal

Designing for Mobile

Master-detail interfaces are just as common on mobile devices as they are for desktop and web-based applications. The smaller amount of screen real estate just means that the relative arrangement of the master list and detail sections might be a little different. On an iPhone, for example, they might be stacked such that you only see one section at a time, with the other section revealed on demand. Here is a different version of the above example that’s been redesigned for FileMaker Go on the iPhone. Instead of having the master and detail sections side by side, I have them in different slide control panels. The master portal is in the first panel; I then have a transparent button in the portal row that simply switches to the second panel which displays the detail section. Because tapping on the portal row natively makes that the current record, no additional code for the navigation action is necessary. Once in the detail view, the user can swipe left to return to the master list.

Animated GIF: Stacked master-detail interfaces work well for mobile

Stacked master-detail interfaces work well for mobile

Performance Considerations

I thought it would be interesting to see how master-detail portals perform with large tables or over a slow network connection. Would there be a noticeable delay in the portal refreshing to reflect a new found set or sort order? How about scrolling the portal or selecting a record? To test this, I set up a file with tables containing 1k, 10k, and 100k records, hosted it on FileMaker Server, and opened it over a WAN connection. I found that while the basic searching and sorting actions performed as expected—slower with larger record sets—I didn’t notice any additional slowness for the portal to refresh. However, I did start experiencing a slight lag in response with scrolling and selecting in the portal with a sorted found set of 10k records. This behavior became much more pronounced at 100k sorted records. Interestingly, there was no lag in either case with an unsorted found set, so sorting appears to be the culprit. It’s worth noting here that if you have a table with 10k or more records, the master-detail design pattern may not be a good idea in the first place (more on that below). But for tables containing up to several thousand records, performance is a non-issue.

When It’s Not a Good Fit

As we saw above, when we configure portals to display records from the current table, we don’t get the options to sort or filter the portal records. In addition, allow deletion of portal records is required, allow vertical scrolling is required, and the initial row number is locked at 1. These “locked” settings make sense as they naturally reflect what we would expect for a master-detail design pattern. That said, if you have a situation where you want to have a master list that doesn’t reflect the current found set—for example, you want to limit the total number of records displayed in the portal, or you want to have additional filtering applied—you would need to use other, pre-v17 techniques for configuring your portal and handling the associated functionality. More generally, the master-detail design pattern becomes less of a good fit for tables containing more than a thousand records (and some would argue much less than that). While it can be fun to do as a developer for testing purposes, a user is never going to want to scroll through thousands of records in a portal. If that’s your situation, you’ll better serve your users by exploring other design patterns.

Conclusion

We’re excited about the new master-detail portal feature and feel like it opens up new possibilities for FileMaker interface design. It will be fun seeing how the FileMaker developer community begins using this feature in the months ahead.

Resources

Wikipedia: Master-Detail Interface Microsoft: Master/details pattern Todd Geist’s Master-Detail FileMaker Module for pre-v17   Stu Dietz is a FileMaker 16 Certified Developer at Skeleton Key in St. Louis, MO.

About Skeleton Key

Skeleton Key helps turn complex, complicated, and outdated systems into true information platforms. Our team of consultants and developers do this by developing custom-fit software tools and reporting dashboards that help businesses find, use, and understand their data, freeing them to focus on and grow their core business. In addition to custom databases and applications, we also provide training and coaching for getting the most out of your existing systems and understanding your unruly data. Skeleton Key is an open-book management company and active player of the Great Game of Business.

myapps filemaker17

FileMaker 17: Accessing your Apps

With each new release of FileMaker, as developers, we tend to look at the big changes that may affect how we develop, what new features just became easier, and what can we do with this version over the last.  But in this, we might miss some of the smaller, more subtle changes that could affect the end-user’s ability to simply log onto our apps.  Within FileMaker 17, there is a subtle yet significant change in how users access an app and starter solutions upon program launch and from the File menu.

Accessing your app from FileMaker Pro 17

In FileMaker Pro Advanced 17 the former “Launch Center” has been completely redone and is now known as My Apps.

My Apps - FileMaker 17

My Apps – FileMaker Pro Advanced 17 centralized App launch area

In FileMaker Pro 16 we had the Launch Center which was broken up into the favorites and recent sections plus buttons for Browse and New.

FileMaker Launch Center

Old Launch Center – FM16 and lower

In FileMaker Pro Advanced 17, the My Apps window will open anytime FileMaker Pro Advanced is launched.  The My Apps “tab”,  is also accessible from the updated File menu shown in the section below, and is equivalent to the “favorites” section of the old Launch Center but is much easier, and I believe more intuitive for your end-user.  If the user has certain apps they access frequently, then it is best to have them add the applications to the My Apps screen and now those apps will be displayed in the above window and from the My Apps menu shown below. Please keep in mind that simply opening an app, either local or remote, will NOT add it to the My Apps screen.  All recently opened apps will show in the Recent tab which is a nice list view showing the app name and its location in descending order starting with the most recently opened app.

Adding a New App

To add a new app simply click on Add app.  When you do so a small pop-over will appear with two options

Add App

FileMaker Add App Process

  1. From Browse – this will allow the user to browse their local system for a local file.
  2. From Hosts – will open a new window allowing the user to select from a hosted file on a remote server.

Please note a subtle change in terminology.  FileMaker 17 no longer has the concept of Open Remote, it is simply called Hosts.  The former Remote dialog screen has been modified to look like the following:

FM17 Host Management Image

FileMaker Pro Advanced 17 Host Management

In this new Hosts screen, the user can add a new host once supplied with a URL or IP address.   They have the ability, once connected, to toggle between icon and list view.  They can more quickly search through a list of files on the server using the new filter by type feature in the search field.  What is not evident is that a user must right-click on the hostname in order to edit it or remove it from their favorites. *Removing a host from the Favorites removes that host from anything saved in your local FileMaker Pro copy. One other hidden gem is the icon in the top right corner.  Clicking that opens the Network FilePath dialog box.

Network Filepath image

Network FilePath

Using the New File Menu

As you can see above, there have been many changes to what is now known as the My Apps window.  Some key terminology has changed as well – Hosts = “Open Remote” and My Apps = “Favorites”.  The changes have been extended into the File menu which has had its own reorganization.

File Menu FileMaker 17

File menu FileMaker 17

FileMaker 16 File menu

FileMaker 16 File menu

Key Observations:

  • The Open command is simply 1 line and opens a standard file explorer that has a button to go to Hosts.
  • My Apps allows you to add a currently opened app to the My Apps menu – “favorites”.
  • Hosts “was Open Remote” opens the new Hosts window.
  • The Recent menu allows you to clear all of your most recently opened files.  This also clears the list of recently opened files in the My Apps window.

Creating a New App in FileMaker 17

The final important change in all of these getting started changes is that of the Create New menu which replaces the Getting Started and New Solution menu items from FileMaker 16.  From the My Apps window, there is a Create button, also found in the File menu.  Both take you to the following window:

Create new Options Window

FileMaker 17 Create New Options Window

This Create window allows the user to create an app “Blank” with one table and a default set of fields (also new in FileMaker 17).  A user can convert an Excel document or other related files into a FileMaker 17 database. Finally, new to 17, there is the Learn Center that has some basic tutorials for creating apps and for working with their starter and sample apps. In the window, you can clearly see a new set of files made available by FileMaker as a true starting point for use by any user/organization.  Note the change in iconography for the Starter solutions.  These solutions, based on a new template called Universal Touch are designed to be a true starting point for a new app.  The Universal Touch design can be modified to match an organizations color scheme, branding, or whatever is needed to make the starter solution their own.  The Starter apps are different from the Sample apps which remain from FileMaker 16. The Sample apps are designed with their own themes and layouts and are more intended for inspiration rather than solution starting.

Summary

As a developer, it is easy to get excited about the new Master-Detail layouts, FileMaker 17 Server changes, multiple e-mail attachments and the many other development improvements that can make our lives easier and apps more exciting.  But with these changes to how we simply launch the apps we create, we can not lose sight of our users who may need a little more assistance re-orientating themselves to new terminology, options and window changes for actually accessing the apps they use on a daily basis.   Todd Stark is a FileMaker 16 Certified Developer at Skeleton Key in St. Louis, MO.

About Skeleton Key

Skeleton Key helps turn complex, complicated, and outdated systems into true information platforms. Our team of consultants and developers do this by developing custom-fit software tools and reporting dashboards that help businesses find, use, and understand their data, freeing them to focus on and grow their core business. In addition to custom databases and applications, we also provide training and coaching for getting the most out of your existing systems and understanding your unruly data. Skeleton Key is an open-book management company and active player of the Great Game of Business.

fmp17 adv app icon

FileMaker 17: Default Fields

Recent FileMaker releases have seen new features that allow the developer a little more control over their custom app on the back end. I’m talking primarily about FileMaker Data API that was introduced with FileMaker 16. Which made interaction with a FileMaker solution possible from a host of outside platforms. FileMaker 17 continues to pull back the curtain, if ever so slightly, to give developers a peak under the hood of the platform, and make possible a pretty handy time saving feature. New in FileMaker 17 is support for custom default fields. Basically what this means is that it’s possible to have a set of predefined fields be automatically created for any new table that gets created in a solution. During development, as new tables are added to a solution, there are inevitably certain recurring fields that need to be created in each new table. Fields like ‘ID’ or some variation of a ‘Primary Key’. Most likely you use some list of creation and/or modification meta data fields to capture time stamps and user info. The ability to copy/paste fields between tables is extremely useful in this and was a welcome addition when it was introduced. However, it will now be possible for developers to control the automatic creation of such fields for any new table from a central location.

Some ‘default’ default fields

Below is a sample version of an XML file that can be used to control the default fields that will be created for any new table in any file that is edited using the client machine where the XML file is installed. [xml] <?xml version="1.0" encoding="utf-8"?> <FMDefaultItems version="1" source="17.0.1" membercount="1"> <DefaultFields membercount="5"> <Field id="1" name="PrimaryKey" fieldtype="Normal" datatype="Text" comment="Unique identifier of each record in this table"> <AutoEnter type="Calculated" prohibitModification="True" overwriteExisting="True" alwaysEvaluate="False"> <Calculated> <Calculation> <Text><![CDATA[Get( UUID )]]></Text> </Calculation> </Calculated> </AutoEnter> <Validation type="Always" allowOverride="False" notEmpty="True" unique="True" existing="False"></Validation> <Storage autoIndex="True" index="None" global="False" maxRepetitions="1"> <LanguageReference name="Unicode" id="2"></LanguageReference> </Storage> <TagList primary="True">#_FMI_0 </TagList> </Field> <Field id="2" name="CreationTimestamp" fieldtype="Normal" datatype="Timestamp" comment="Date and time each record was created"> <AutoEnter type="CreationTimestamp" prohibitModification="True"></AutoEnter> <Validation type="Always" allowOverride="False" notEmpty="True" unique="False" existing="False"> <Strict>FourDigitYear</Strict> </Validation> <Storage autoIndex="True" index="None" global="False" maxRepetitions="1"></Storage> <TagList>#_FMI_0 </TagList> </Field> <Field id="3" name="CreatedBy" fieldtype="Normal" datatype="Text" comment="Account name of the user who created each record"> <AutoEnter type="CreationAccountName" prohibitModification="True"></AutoEnter> <Validation type="Always" allowOverride="False" notEmpty="True" unique="False" existing="False"></Validation> <Storage autoIndex="True" index="None" global="False" maxRepetitions="1"></Storage> <TagList>#_FMI_0 </TagList> </Field> <Field id="4" name="ModificationTimestamp" fieldtype="Normal" datatype="Timestamp" comment="Date and time each record was last modified"> <AutoEnter type="ModificationTimestamp" prohibitModification="True"></AutoEnter> <Validation type="Always" allowOverride="False" notEmpty="True" unique="False" existing="False"> <Strict>FourDigitYear</Strict> </Validation> <Storage autoIndex="True" index="None" global="False" maxRepetitions="1"></Storage> <TagList>#_FMI_0 </TagList> </Field> <Field id="5" name="ModifiedBy" fieldtype="Normal" datatype="Text" comment="Account name of the user who last modified each record"> <AutoEnter type="ModificationAccountName" prohibitModification="True"></AutoEnter> <Validation type="Always" allowOverride="False" notEmpty="True" unique="False" existing="False"></Validation> <Storage autoIndex="True" index="None" global="False" maxRepetitions="1"></Storage> <TagList>#_FMI_0 </TagList> </Field> </DefaultFields> </FMDefaultItems> [/xml] Save the file as DefaultFields.xml and place it in the following locations: MacOS: /Users/Shared/FileMaker/Shared/ Windows: <drive>:ProgramDataFileMakerShared The sample contains values for 5 basic starting fields that will be useful is just about any context. The XML file can be edited to modify these fields or include additional ones. Alternatively a blank version of the file can be placed in the same location to stop any default fields from being created.

Some other fields you may find useful

Copy/Paste these examples into your DefaultFields.xml file to try them out. (Be sure to modify both the ‘membercount’ and the individual ‘Field id’ attributes in your own file in order for them to work correctly)

  1. Host Timestamps – It’s sometimes necessary to capture creation/modification meta not only from the client but from the host machine as well. This can be useful when hosting apps for clients that are on mobile devices or in different time zones. [xml] <Field id="6" name="HostCreationTimestamp" fieldtype="Normal" datatype="Text" comment="The timestamp from the host machine at the time of record creation"> <AutoEnter type="Calculated" prohibitModification="True" overwriteExisting="False" alwaysEvaluate="True"> <Calculated> <Calculation> <Text><![CDATA[Let ( ~trigger = GetField ( "" ) ; Get ( CurrentHostTimestamp ) )]]></Text> </Calculation> </Calculated> </AutoEnter> <Validation type="Always" allowOverride="False" notEmpty="True" unique="False" existing="False"/> <Storage autoIndex="True" index="None" global="False" maxRepetitions="1"> <LanguageReference name="Unicode" id="2"/> </Storage> <TagList>#_FMI_0 </TagList> </Field> [/xml]
  2. Constant Value – Some relationship models make use of relationships based on constant values such a constant value of “1” in every record of the related table. [xml] <Field id="7" name="Constant_1" fieldtype="Normal" datatype="Text" comment="A constant value of 1 in all records"> <AutoEnter type="Calculated" prohibitModification="True" overwriteExisting="False" alwaysEvaluate="True"> <Calculated> <Calculation> <Text><![CDATA[1]]></Text> </Calculation> </Calculated> </AutoEnter> <Validation type="Always" allowOverride="False" notEmpty="True" unique="False" existing="False"/> <Storage autoIndex="True" index="None" global="False" maxRepetitions="1"> <LanguageReference name="Unicode" id="2"/> </Storage> <TagList>#_FMI_0 </TagList> </Field> [/xml]
  3. Always Null – In the same vein as the constant value field, maybe you need a field that is ALWAYS empty. [xml] <Field id="8" name="AlwaysEmpty" fieldtype="Normal" datatype="Text" comment="This field is always empty"> <AutoEnter type="Calculated" prohibitModification="True" overwriteExisting="True" alwaysEvaluate="True"> <Calculated> <Calculation> <Text><![CDATA[""]]></Text> </Calculation> </Calculated> </AutoEnter> <Validation type="Always" allowOverride="False" notEmpty="False" unique="False" existing="False"/> <Storage autoIndex="True" index="None" global="False" maxRepetitions="1"> <LanguageReference name="Unicode" id="2"/> </Storage> <TagList>#_FMI_0 </TagList> </Field> [/xml]
  4. Get (RecordModificationCount) – It’s easy enough to simply call the function to get details of the current record. However, maybe you want to create a virtual list that displays the records that have seen the most activity. This field would have to be unindexed, but it would make for a simple way to see those numbers. This could also be useful in audit logging. [xml] <Field id="9" name="ModificationCount" fieldtype="Calculated" datatype="Number" comment="Running count of modifications"> <Calculation> <Text><![CDATA[Get(RecordModificationCount)]]></Text> </Calculation> <Storage storeCalculationResults="False" indexLanguage="English" global="False" maxRepetition="1"> <LanguageReference name="Unicode" id="2"/> </Storage> <TagList>#_FMI_0 </TagList> </Field> [/xml]
  5. Company Logo – It’s a little out of the box thinking, but maybe you want to store a simple company logo which has been Base64 encoded in a global text field. Of course, you wouldn’t need the field in ‘every’ table since it’s global, but we’re just brainstorming here.

While the default fields feature is supported in FileMaker 17 it is not getting much of a footprint especially when it comes to documentation. The format and naming convention of all the attributes in the XML file are not yet fully documented (though I imagine the community will have their heads around it fairly soon). To get some good direction on how some of the other attributes need to be used you can refer to an XML version of a DDR produced using FileMaker Pro Advanced. The formats are not 100% identical, but many of the attribute formats are the same. Jeremy Upton is a FileMaker 16 Certified Developer at Skeleton Key in St. Louis, MO.

About Skeleton Key

Skeleton Key helps turn complex, complicated, and outdated systems into true information platforms. Our team of consultants and developers do this by developing custom-fit software tools and reporting dashboards that help businesses find, use, and understand their data, freeing them to focus on and grow their core business. In addition to custom databases and applications, we also provide training and coaching for getting the most out of your existing systems and understanding your unruly data. Skeleton Key is an open-book management company and active player of the Great Game of Business.

fm17 perform script on server

FileMaker 17: Perform Script by Name

Perform Script By name Swiss Army Knife. Developers have been able to “go to”, “set” values and even reference files “By name.” The FileMaker 17 Perform Script By name option is just one of many improvements developers can use to create reusable and dynamic code. The new feature may not change the way we code on a daily basis, but know that it is part of the FileMaker Swiss Army Knife toolbox and how to “flick” it open.

History of “Hard-coded” scripts

Animated GIF of renamed FileMaker script.

FileMaker handles script renaming

Developers have associated their buttons, script-triggers and sub-scripts by hard-coding them to a script for as long asFileMaker Pro Advanced scripts have existed. FileMaker handles the linking of such scripts under-the-hood by ID when hard-coding scripts. This linked behavior is what makes FileMaker applications capable of working even after the name of a script has been changed. The animation demonstrates FileMaker Pro’s ability to keep things intact even after script renaming.

Perform Script by Name History

The concept of performing FileMaker scripts “By name” is not entirely new. Here are a few methods with which this has been done in prior versions.

Instructions and syntax example from FileMaker Pro 12 Help.

FileMaker Pro Help from version 12

FMP URL Protocol

A properly constructed URL can be used to run scripts by name. The URL can run a specific script in a FileMaker Pro Advanced file in just about any situation one can open a URL (i.e. within email message, browser’s address bar or webpage, a FileMaker Pro or Go WebViewer).

CWP documentation & syntax

Custom Web Publishing (API for PHP/XML)

FileMaker’s Custom Web Publishing (CWP) has performed scripts by name since its inception. Developers construct their code in a similar fashion to the FMP URL Protocol example above.

FileMaker 17 Perform Script By list

Comparison between version 17 and earlier of "Perform Script From list".

Perform Script FM17 vs earlier

By default, FileMaker 17 “Perform Script” script step behaves the same way as it did in earlier versions, but looks a little different. When the “Perform Script” script step is added to a script, it defaults to the familiar method of selecting scripts which it now refers to as “From list”. FileMaker 17 displays “Specified: From list” (or “Specified: By name”) and always shows the script parameter placeholder, even when empty.

FileMaker 17 Perform Script By name

Perform Script “By name” Examples

The updated script step adds the option referred to as “By name”. A developer specifies the source of the script name by using the FileMaker calculation window. Some written text, a field, a local variable, a global variable or Get ( ScriptParameter ) can contain the name of the script. One could even use JSONGetElement to extract the name of a script to run from a JSON Object. A special syntax ( <FileName>::<ScriptName> ) is required to perform a script “By name” when the script belongs to an external file. The following image shows some examples of these uses.

Perform Script on Server (PSoS) update

Everything mentioned about the “Perform Script” script step is also applicable to the “Perform Script on Server” script step (PSoS). A PSoS script can be specified “By name” or “From list.”

Error 104 Script is missing

Error 104 Script is missing debugger screen shot

Error “104 Script is missing” returned.

Error 104 is not new to version 17 and can occur for several reasons. A script could have been deleted or the value used to perform script “By name” could have a spelling or syntax error. The value could refer to a non-existent script or was simply renamed. Careful planning and error handling are required when using any one of the script steps that “go to” or “set values” by name. Using FileMaker Pro Advanced 17’s perform script “By name” script step is no different. Error 104 will occur when FileMaker Pro Advanced is unable to find a script by the specified name. So be thoughtful when naming and renaming scripts.

Perform script by name animation with failure.

Animation of script renaming failure

The animation in this section’s example uses a button which calls a script by name. Notice how the button successfully calls the script named “Original Name”. After the script is renamed to “Still remember me?”, the button fails. This example contrasts the earlier animation where a button was hard-coded to a script that had been renamed but was automatically “fixed” by FileMaker Pro Advanced.

Use Cases

Here are a few suggestions for using Perform Script By name that have been discussed at Skeleton Key.

  • Self-referential Perform Script on Server script steps (PSoS). Some background here at Skeleton Key. We include a little code to conditionally check the environment and platform when we write scripts that could be run via Perform Script on Server. It might save us a little time and gain accuracy by using Get ( ScriptName ) as the PSoS script name to run.

    PSoS Self-referential

  • Loop through a list of script names. Instead of hard-coding several Perform Script steps, it would be possible to work through a list of script names which might be provided in a script parameter, possibly formatted as a JSON object.
  • Layout design before scripts. With FileMaker 16 and earlier, when copying layout objects and scripts from one project to another, FileMaker developers paste scripts first, then layout elements. The order is necessary for layout buttons to stay connected to the scripts they run. If your layout buttons use Perform Script By name with FileMaker Pro Advanced 17, layout elements could come before scripts since the name of the script a button is associated to evaluates at the time the button is clicked or script-triggered. This will not likely change our approach to programming in the immediate future for all projects.

For additional ideas and use cases, there is a fairly thorough “product idea” discussion on the  FileMaker Community website.

Next Steps

The use of Perform Script “By name” is not an all or nothing situation. That is the beauty of FileMaker Pro Advanced…it gives developers options. Take some time to define your application’s needs and your approach to development. Do you need to call scripts dynamically? Are you willing to give up FileMaker Pro Advanced’s ability to keep track of your script names if/when you rename them? Good luck experimenting and happy FileMaking! Jay Sayers is a FileMaker 16 Certified Developer at Skeleton Key in St. Louis, Mo. This article was also published on Medium.com About Skeleton Key Skeleton Key helps turn complex, complicated, and outdated systems into true information platforms. Our team of consultants and developers do this by developing custom-fit software tools and reporting dashboards that help businesses find, use, and understand their data, freeing them to focus on and grow their core business. In addition to custom databases and applications, we also provide training and coaching for getting the most out of your existing systems and understanding your unruly data. Skeleton Key is an open-book management company and active player of the Great Game of Business.

fmp17 adv app icon

FileMaker 17: Layout Mode Changes

FileMaker 17: Layout Mode Changes

The release of FileMaker Pro Advanced 17 brings some changes to layout mode with the positioning of some of the toolbars. The Field Picker toolbar has also been updated with some minor tweaks. Overall only minor changes to layout mode have been made. The workflow should be familiar to most seasoned FileMaker Pro users.

Updated Toolbar Positions

The first thing you will notice is the absence of the Field Picker, Inspector and Layout Objects buttons below the status toolbar in layout mode. All three of these toolbars have been moved to new panes which are anchored to the left and right of the window.

There are several ways to open and close the panes for these tool bars:

The Show/Hide Panes buttons at the top right of the status toolbar will open and close them. Keyboard shortcuts are also available:

  • Inspector: Command-I (Mac OS) or Control-I (Windows)
  • Field Picker: Command-K (Mac OS) or Control-K (Windows)
  • Layout Objects: Command-Alt-T (Mac OS) or Control-Alt-T (Windows)

A few additional changes may be noticed with the Field Picker:

The field type icons have changed.

The manage database button is gone from the picker. It has been moved to the bottom of the Table drop down menu. Expanding the “Drag Preferences” at the bottom of the Field Picker will display a new option to select a control style. Right-clicking on a field now presents the “Rename Field” option. Previously you had to select the field then pause and click the field name a second time to rename. This “double click” still works in 17.

Other Notes:

The functionality within both the Objects pane (formerly Layout Objects window) and the Inspector remains largely unchanged from FileMaker 16. You can still open a floating inspector window (or several) with the View->Inspectors->New Inspector menu option. It is now possible to make changes to individual objects when they are included in a grouped object. Monica Blum has written a more in-depth blog post about this new feature. You can read her post here: https://skeletonkey.com/filemaker-17-selecting-objects-in-a-group/ A new theme has been introduced in FileMaker 17: Universal Touch. This theme includes several sets of styles and a neutral color palette for simple customization.   Calvin Cooper is a FileMaker 16 Certified Developer at Skeleton Key in St. Louis, MO.

About Skeleton Key

Skeleton Key helps turn complex, complicated, and outdated systems into true information platforms. Our team of consultants and developers do this by developing custom-fit software tools and reporting dashboards that help businesses find, use, and understand their data, freeing them to focus on and grow their core business. In addition to custom databases and applications, we also provide training and coaching for getting the most out of your existing systems and understanding your unruly data. Skeleton Key is an open-book management company and active player of the Great Game of Business.

fmp17 app icon

FileMaker 17: From Products to Platform–An Evolution in FileMaker Licensing

While licensing may not be as headline-grabbing as some of the newer features boasted by FileMaker 17 (I mean, how can anything compete with Master-Detail Layouts or Default Fields?), my vote for the best sleeper feature is this: FileMaker is now officially being sold as a Platform, and not as a grab-bag of different Products.

The Way We Were

Historically the FileMaker family of products consisted of various parts that you would assemble (i.e., FileMaker Pro, FileMaker Pro Advanced, FileMaker Server, Concurrent Connections), somewhat à la carte, to achieve your desired setup. Along the way, you often had to make choices and compromises. Uncertainty about these choices, or the quantities selected along the way, could have a one-, two- or three-year impact on a licensee’s perception of flexibility. It wasn’t that it was a bad situation, just more complicated than it felt like it should be.

Clarified

The first and most noticeable difference in how the FileMaker Platform will now be licensed is just that – you’ll be licensing the platform and not the products. Your focus will shift from what to buy to how many users (and of what type) will be using my solutions? Instead of trying to enumerate the ingredients necessary to feed everyone at your banquet, you’ll focus on how many people will attend, and in which chair to seat them. The first part of that question is pretty simple to answer (i.e., what is the total population of potential users of the solution?), but the second may require us to define some terms. There are three (3) kinds of users in the FileMaker Platform:

  •  ‘Regular‘ users, who need to be able to use FileMaker Pro Advanced on their desktop workstation or laptop, FileMaker Go on their iOS device, or FileMaker WebDirect via a supported web browser.
  •  ‘Occasional‘ users, who are similar to ‘Regular’ users, but with less frequent use. If they ever need to use FileMaker Pro Advanced, they need to be counted as a ‘Regular’ user, but if they can get by with just FileMaker Go or FileMaker WebDirect, then they can be treated like ‘Anonymous’ users (defined immediately below).
  • Anonymous‘ users who will be just fine only using FileMaker Go or FileMaker WebDirect, i.e. these users do not need (nor can they use) FileMaker Pro Advanced, ever.

The next question will be what program makes the most sense for your particular scenario. Fortunately, there are only three (3) to pick from, and they have fairly distinct differences (with just enough overlap to allow for some discretionary choice if needed):

  • For most businesses, the best and simplest option will be FileMaker User Licensing, i.e. how many users will you have, of any kind (i.e., truly ‘Regular’ or ‘Occasional’ users who use FileMaker Pro Advanced, FileMaker Go, and/or FileMaker WebDirect), and at any time?
  • For some businesses, especially those with many potential ‘Occasional’ or ‘Anonymous’ users, the best fit will be FileMaker Concurrent Connections Licensing, i.e. how many users of any kind will you have, and with what level of simultaneous access?
  • For businesses where at least a third of their employees will be using the platform, the best fit will often be FileMaker Site Licensing, i.e. how many employees do you have?

Now some of those terms might sound familiar, but even so, they have evolved and changed to be more flexible, provide more value and be more clearly differentiated. A few clarifications:

  • In FileMaker User Licensing, there is no such thing as an ‘Anonymous’ user. Whether they are a ‘Regular’ user or just an ‘Occasional’ user, you count them, and you’re done.
  • In FileMaker Concurrent Connections Licensing, it’s not about how they log in, but how many need to log in at the same moment of the day. If a certain number of your users will always be logged in, start there and figure out how many of the remaining potential users will likely join them during peak usage periods.
  • In FileMaker Site Licensing, it’s about the platform for your whole company, even if only a fraction needs it now. Every employee is considered to be a ‘Regular’ or ‘Occasional’ user, and ‘anonymous’ users don’t even need to be counted, i.e. they are permitted by default (again, using FileMaker Go or FileMaker WebDirect only) and the primary limit is solution design and server horsepower.

Last but not least, you need to pick how you want to buy, and the same two (2) options are available:

  • Annual, where you lease the licenses, get all updates during the licensing period, and then must either renew your license by the end of the period or deinstall the platform.
  • Perpetual, where you buy the licenses outright, get one (1) year of updates (aka maintenance) included, and then have the (highly recommended) option to renew your maintenance (and thus any additional updates) each year thereafter.

This calculus has not changed – it’s still much more flexible (and requires less money up front) to buy an Annual contract than a Perpetual one, much like leasing a car vs. buying one.

Bundled

Since you’re now licensing the entire platform, your business will have access to every part of the platform in some way, shape or form.

For starters, there’s no more FileMaker Pro, just FileMaker Pro Advanced.

You read that right – one (1) application you can install on your Mac or your PC, with all the features the average day-to-day user, citizen developer, or professional software engineer might desire.

  • Need it to work online, with a hosted solution? OK.
  • Want it to work while developing or generating a report while working on a solution offline at 37,000 feet? Not a problem.
  • Have a fleet of Macs and PCs on your desk that you might want to take with you to a meeting, and wishing you could install FileMaker Pro Advanced on every single workstation, just so it wouldn’t matter which you grabbed as you rushed out the door. Go for it.

If you’re a licensed user of FileMaker Pro Advanced, use it where and when you need it. Period.

Everyone gets FileMaker Go.

Put it on every supported iOS device you and your licensed users might ever use. Cover all your mobile bases.

Everyone gets FileMaker WebDirect.

Use it from any supported browser on any desktop, laptop, tablet or phone. Need a list of supported browsers? Here you go.

Everything for Everybody… almost.

There are two exceptions to the exuberant points made immediately above:

  1. As a licensed ‘Regular’ or ‘Occasional’ user, you’re entitled to use any or all of these methods to access your solutions, but if you’re an ‘Anonymous’ user, then you can only use FileMaker Go or FileMaker WebDirect. I know I made that point at least twice above already, but it’s about the only caveat that most businesses will struggle to understand (editor’s note: even I mixed it up a few times while writing this article!).
  2. If you’re not a business that is looking to license for at least five (5) users, but a single user (or a small business) that is  just looking for one (1) or two (2) retail copies of FileMaker Pro Advanced, that’s still available too (Note: I’d still strongly suggest even the smallest teams consider a volume-licensing program described above, each of which starts at five (5) users; read on to see why).

FileMaker Server comes with every order…

In every program for every business, FileMaker Server is now included. You read that right – FileMaker Server comes along for the ride, so you no longer have to decide if you can afford to ‘make the leap’ to take advantage of the performance, scalability, and security that FileMaker Server offers. It’s yours. Actually, in one (1) case (i.e., FileMaker User Licensing), you get three (3) instances of FileMaker Server, which can be useful for staging your development (e.g., development, testing, and production) or for separating teams (e.g., for additional security, simpler cost-accounting or load-balancing).

… and FileMaker Cloud too!

What’s more, if you’re in any Annual program, then at least one (1) of your FileMaker Servers can be used with FileMaker Cloud. No separate FileMaker Server contract will be needed, although you will still need to sign up for a FileMaker Cloud ‘Bring Your Own License’ (BYOL) account with Amazon AWS.

Allow me to (re)introduce you to the FileMaker Data API.

FileMaker 16 introduced the world to an integrated REST Data API in FileMaker Server, but it was under beta at the time. Now, happily, the (officially renamed) FileMaker Data API is ready for prime-time, is included with each licensed FileMaker Server, and configured to provide a pool of outbound data transfer that can be shared by all external applications (e.g., custom websites or third-party systems) that want to get information from your hosted solutions. You’ll automatically get an allotment of 2 GB/licensed user/month (although it’s worth noting that that’s just for calculating the initial limit; the total is a single, large pool for the contract year), a number which can be expanded (if needed) for an extra fee.

Streamlined

In addition to being a simpler choice, and a more comprehensive offering, the new platform also offers some welcome changes to administrators, such as:

  • Once you have licensed your first five (5) users, you can increase your count in any whole-number increment you want (e.g., by just 1, or 2, 17, 36), and those new users are automatically priced and pro-rated to come up for renewal on the same anniversary date as your existing Annual contract.
  • Moving forward, you’ll only have one (1) license key for each contract so long as that contract stays active. Yes, you read that right.
  • The keys won’t change when new versions of the platform are released, or change when the number of users/connections/employees change either. Yes, you read that right too.
  • Licensing at the desktop/laptop level will be enforced on install, and by the End User License Agreement (EULA).
  • Licensing at the server level will be enforced using a new ‘License Key’ certificate that you install (or update) on the server itself.

Transitioned

To make it simple for existing customers to transition to the new version, FileMaker Inc. is going to convert all existing and active contracts to their matching counterparts in the new platform. For most customers, this will mean a net gain in the number of FileMaker Servers at their disposal. Here’s the way things will basically map:

  • First of all, if you have an active Annual contract now, you’ll get a new Annual contract. Same goes for Perpetual.
  • FileMaker Licensing for Teams,  Annual FileMaker Licensing for Teams, Volume License and Annual Volume License contracts will become FileMaker User Licensing contracts. You’ll get at least three (3) FileMaker Servers, or the entire number you had licensed (whichever is greater).
  • Annual or Perpetual FileMaker Servers with Concurrent Connections will become Concurrent Connections contracts.
  • Site License and Annual Site License contracts will basically stay the same, with a singular change: instead of support for an unlimited number of FileMaker Servers, you will now be limited to the same number of FileMaker Servers as you have licensed users, which starts at 25 users (and if you’re a site that uses more than 25 FileMaker Servers, I’d like to buy you lunch).

As you can imagine (and might already be wondering about if you’ve got a ‘mixed bag’ of products now),  in some cases the transition will be simple – one (1) existing contract will become one (1) new contract – while in others it may require the issuance of multiple contracts to ‘map’ what a customer has now to what they are entitled to in the new model.

Protected

Fortunately, it appears that FileMaker Inc. has gone to great pains to err on the side of being generous with this licensing update. In every real-world scenario we’ve tested, the outcome of the transition was an increase in the number of available FileMaker Servers and overall flexibility for our customer. That said, we understand you might have questions and we’re here to help. Whether it’s about:

  • Understanding which program is right for you if you’re new to the platform,
  • understanding how an existing contract will be converted,
  • planning how you might consolidate multiple contracts in the future, or
  • exploring how to take advantage of available price protection options for existing licensing customers,

… your resident Skeleton Key licensing expert can happily assist. Just call us at 314-353-4300, or fill out our convenient web-form now.   Mark Richman is President at Skeleton Key and a FileMaker Certified Developer and FileMaker Authorized Trainer.

About Skeleton Key

Skeleton Key helps turn complex, complicated, and outdated systems into true information platforms. Our team of consultants and developers do this by developing custom-fit software tools and reporting dashboards that help businesses find, use, and understand their data, freeing them to focus on and grow their core business. In addition to custom databases and applications, we also provide training and coaching for getting the most out of your existing systems and understanding your unruly data. Skeleton Key is an open-book management company and active player of the Great Game of Business.

fmp17 adv app icon

The FileMaker 17 Platform

The FileMaker 17 Platform is a landmark release with many new and improved features that make it more powerful and even easier to use. Here are some of the reasons why we think it’s the best version yet. FileMaker Pro 17 Advanced Earlier releases included three different versions of the desktop application…FileMaker Pro, FileMaker Pro (for User Connections), and FileMaker Pro Advanced. Version 17 simplifies this to one application…FileMaker Pro Advanced. The Tools menu can be enabled or disabled in the preferences. System administrators have the option to completely remove this option during installation, but the application name is always FileMaker Pro Advanced and Get(ApplicationVersion) returns “ProAdvanced 17.0.1”. One of the changes you’ll notice as soon as you enter Layout Mode is the addition of panels on the left and right side of the window. The left panel includes tabs for Fields and Objects. The right panel is a docked version of the four-tab Inspector. The new panels put a lot of power at your fingertips, but you may find the need for a second (or third) display so that you can comfortable work in Layout Mode on one display and view your work in Browse Mode on another. Calvin Cooper has more details here. Another Layout Mode change that is less obvious is the ability to select and manipulate individual objects within groups without needing to ungroup. This can be a nice time-saver, which Monica Blum describes here.

My Apps - FileMaker 17

My Apps – FileMaker 17 centralized App launch area

The My Apps window replaces the Launch Center with a more intuitive experience that makes it easier to open your apps and get started creating new ones. Todd Stark shares a few thoughts about the My Apps window here. FileMaker Pro 17 includes six new starter apps plus a brand new Add-on Tables feature which allows anyone to quickly add new tables and related functionality to your app. Chad Adams has more details here. A new portal option allows a developer to easily create master-detail layouts that have a great user experience. Stu Dietz shares several examples and tips here. Developers who love to create modular scripts that can easily be moved between apps will appreciate the new Perform Script by Name script step. Jay Sayers digs into what’s possible here. Developers who create a lot of tables will also appreciate the new Default Fields feature. By default, five new fields will automatically be created in each new table. The default fields can be overridden with your own favorite default fields. Jeremy Upton shares how here. The Send Mail script step has a simple but powerful improvement that allows multiple file attachments to be included in an email message. David Roche explains more here. FileMaker Pro 16 enabled many script steps (such as Insert from URL) to use a local or global variable as a target. In version 17, the Show Custom Dialog script step now allows the use of variables as the target for input fields. Jessie Cisneros shares some tips here about why that can make development a bit easier. FileMaker’s licensing options have changed significantly over the years. Version 17 takes a fresh approach to simplifying the license options and treating the previously separate products as a true platform. Whether you buy User, Connection, or Site licenses, you’ll get access to all of the individual pieces of the platform. Mark Richman provides an introduction to what’s new here. Both FileMaker Server and FileMaker Cloud now include an improved version of the FileMaker Data API that allows performing scripts and uploading files to container fields. The FileMaker Data API is now metered, but it includes a generous data allowance with all license types. FileMaker Server has a redesigned Admin Console, a more powerful command-line tool, and a trial version of the FileMaker Admin API. Together, these three admin interfaces offer tremendous flexibility and power. FileMaker Server admins will find they have some new things to learn. The FileMaker Developer Subscription includes an updated version of the iOS SDK as well as a new command-line Data Migration Tool. The Data Migration Tool solves some longstanding problems by allowing fast transfer of all data, accounts, and value lists from a solution into a clone of the solution. This tool will make it much easier and faster to move updated versions of an app from development to test or production environments. FileMaker Go 17 receives some great new features including access to sensor data and local notifications. Apps can now use auto-complete in text fields, keyboard shortcuts on external keyboards, and drag and drop of text, photos, and files on iPad. The FileMaker 17 Platform has a great set of features and we think it offers a tremendous value and flexibility. We’re excited to build new apps that are more powerful than ever.   Greg Lane is a FileMaker 16 Certified Developer at Skeleton Key in St. Louis, MO.

About Skeleton Key

Skeleton Key helps turn complex, complicated, and outdated systems into true information platforms. Our team of consultants and developers do this by developing custom-fit software tools and reporting dashboards that help businesses find, use, and understand their data, freeing them to focus on and grow their core business. In addition to custom databases and applications, we also provide training and coaching for getting the most out of your existing systems and understanding your unruly data. Skeleton Key is an open-book management company and active player of the Great Game of Business.