Meta-consulting is a service Database Pros offers to help other developers
over programming hurdles via GoToMeeting. Email John Mark Osborne or call John Mark at (909) 393-4664 to find out more about this service.
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.
Level: Intermediate Version: FileMaker 17 Category: General Tuesday, May 15, 2018
Last year was sweet sixteen. This year is prime seventeen. That's the best title I could come up with after Googling the number seventeen. Not much out there for this number. While seventeen is a prime number, prime can also describe the new FileMaker 17, adding features that will change the way you develop your FileMaker solutions. Seriously! Also, I'm going to focus on desktop enhancements but I'm sure there are many bloggers out there who will talk at length about FileMaker Go and FileMaker Server enhancements, of which there are many.
Improved Layout Tools As a developer, my favorite mode is obviously layout. So, any changes to layout mode get me excited, even if there are no "real" new features. What FileMaker, Inc. has smartly done in FileMaker 17 is anchor the Inspector, Objects and Field Picker palettes to the left and right sides of the screen. This may not seem like something to stand up and cheer about but just give it some time to percolate...
Think back to the last time you developed a solution from scratch. How many times did you move the Inspector palette out of the way so you could modify a layout. I often just close it out of frustration and then need to open it again five minutes later. Add to that how many times you lost the Inspector on your big screen monitor. It just kinda blends in with the other windows. If we're being honest, that's probably thousands of times you opened, closed and moved the Inspector... just for a single project. Now those dialogs are pinned to the left and right sides of the layout so they won't get in the way or lost. You may want to increase your real estate from time to time by hiding them. This is easily done with similar controls as seen in the Script Workspace and the Calculation dialog. Also, the same keyboard commands still toggle the display of these panes.
I say hallelujah! I've been quietly cursing the palettes in FileMaker for years, wishing for the old days of modal dialogs. Ok, that might be an exaggeration but you get my point. Floating palettes are so last decade. Thanks to Rick Kalman and his team for recognizing this interface hindrance and providing a modern look and feel. I'm sure we'll all love it once we get used to it. Yes, there will be some grumbling but the same thing happened with the redesigned Script Workspace. I was one of those nay sayers but now I dread using FileMaker 11 to create scripts. It's just so inefficient if you know the name of the script step already!
Usability Enhancements for Beginners FileMaker, Inc. has been fiddling around with the Getting Started dialog since FileMaker 11. To be honest, I haven't liked any of the offerings until this version. I'm not sure I can put my finger on exactly what I like but it just seems to work. It really doesn't do much of anything new, just different. I guess I like the interface and how it's organized. It seems obvious how it works whether you're a beginner or a seasoned veteran.
For example, there's a big "Blank" icon in the upper left corner, making it really easy for experienced developers to identify and click to create a new document. If you're a beginner, there's a "Convert" button right next to it, followed by a "Learn" button, each with it's own help pane at the right side of the dialog. Right below these three icons are all the Starter solutions. If you scroll down further, you see the Sample solutions which are described as "apps that show the possibilities". In other words, Starter solutions are very basic single table solutions that anyone just starting with FileMaker can easily modify. Sample solutions are much more complicated and can be used as is or be modified by a developer with a couple years experience.
But the fun doesn't stop there! They include other file management features with My Apps and Recent tabs. You should already be familiar with the Recent feature which has been a menu item for quite a few versions. The Recent sub-menu is still under File menu but the dialog version allows you to see the path for the first time. I don't know about you but that can be very helpful when you have a local version you are developing and a hosted version with the same name.
The My Apps feature is the same as My Favorites from previous versions, reworked into the Create New dialog. Again, nothing earth shattering here. It just seems to be done better and made accessible in a single dialog. You'll have to get used to the new terminology though. I still call them FileMaker files but I've been trying my best to call them solutions. Now I have to rework my old brain to call them Apps. Argh! It is was it is and I'm sure we'll all get used to the new branding.
When you combine the new Starter solutions in FileMaker 17 with the new Add-on Tables feature, you have a match made in heaven for folks new to the platform. Add-on Tables automatically add predefined fields, tables, relationships, scripts and layouts to an existing solution. Let's say you use the Contacts Starter solution but want to add on support for multiple phone numbers or email addresses. It's so easy because FileMaker does all the heavy lifting for you and poof, the portal appears on the layout, arranged nicely and with scripted buttons. In fact, there are total of eleven Add-on Tables that can accessed through the Portal tool. Watch the video below to see a demonstration of how a Starter solution is transformed in minutes with Add-on Tables.
While the Hosts dialog is separate from the Create New dialog, I couldn't find anywhere else to praise this nicely overhauled feature. Not only can you filter hosts but you can filter files on the host. Clearly this is the work of a fellow FileMaker developer, who much like me, has a sea of files at a particular IP Address that he needs to reduce. Now, if FMI could only do this with the Field tab in the Manage Database dialog, I'd slap myself silly. I also like how local hosts and manually added hosts are separated and easy to identify.
FYI: I've only heard one complaint about the new Hosts feature. In order to display the Hosts dialog, you need to select it from a sub-menu. It's a little more work but my response is, it still has the same keyboard shortcut as Open Remote from previous versions. Not only that, the sub-menu also displays the hosts so you don't have to enter the dialog. People always find something to complain about but I say job well done FileMaker, Inc.
Preferences and File Options FileMaker Pro and Advanced have been the same application for a long time, sharing the same code base. It's just official now! A mere check box in Preferences differentiates Pro and Advanced in version 17. All you need to do is restart the app to see Advanced features. Of course, you can configure an assisted install to prevent folks from checking this item. But, this seems like a lot of work for no reason. Let them check the box. They won't be able to use Advanced features on your solution if it has security and custom menus.
File Options also sports a new check box that allows you to turn off all toolbars including the status toolbar and menu bar but, unfortunately, does not include rulers. This is not very useful for developers as they like to control access to the toolbars in a open script via a conditional statement that differentiates between users and developers. This feature seems aimed at beginners who want an easy way to increase their screen real estate by hiding the FileMaker interface. I get it but I won't using it. And, if you were wondering, an open script will override this behavior with no flashing or jerking of the window.
Found Set Portals Now, this feature is a doozy and likely to spawn tips and tricks for years to come. The new feature allows a portal to show records from the current found set. That's right, no self-join relationship necessary! So, how is this useful? Imagine merging a form and list view. There's no need to click back and forth between a separate form and list view layout. Just click on a portal row and the context of the Body part is changed to the selected row.
SIDE TIP: You don't need found set portals to merge form and list view. Just create a list view layout and place the form view fields in the header or footer. The only drawback is the form information is always at the top or bottom of the screen. With a portal and FileMaker 17, the location of the form information is back to the body and the portal showing the list can be placed anywhere in the body part, allowing for more interface flexibility.
Found set portals will also enhance pickers or choosers. If you've ever created a picker, as a replacement for popup menus, you know what a pain they are to create from scratch. With found set portals, there is no longer a need to create relationships, calculation filters, complicated compound keys or sophisticated scripts to support pickers. Just create a layout with a portal, choose the current table and use a scripted find to change the found set (which will in turn change the content of the portal). Just add a simple button on the portal row to select the ID and you can place the ID from any portal row in any foreign key you want. How easy and cool is that! Say goodbye Selector Connector and say hello to proper use of the Anchor Buoy relational paradigm.
SIDE TIP: Selector Connector methodology allows for solution wide pickers or choosers, which saves a ton of development time. However, proponents of the Selector Connector say that you can still benefit from the Anchor Buoy system when using the Selector Connector variation, but this is simply not true. The purpose of anchor buoy is not only to organize the relationship graph but also to make it easier to pick table occurrences from dialogs. Since the Selector Connector connects all table occurrences to each other, you're again left with the same results as the spider web relational approach. See Wrangling Relationships on this web site for more information on Anchor Buoy and Selector Connector.
Both techniques mentioned above are shown in the example file available for download at the end of this article (SEVENTEEN.fmp12). I offer a more polished version of the merging of list and form view in the download file, which is likely to be the most common use. I also show how to use a found set portal picker and a simple filter to add related contacts. I still can't believe how easy the picker is to create and how flexible when combined with simple find scripts to change the contents of the found set portal. Just beautiful!
Universal Touch Theme I'm not an interface designer... at least not one of those guys who can create Photoshopped buttons from scratch. I guess I have good organizational skills because people are always saying how clean my interfaces are. This explains why themes work well for me. I don't need to do anything but place objects pleasingly on the layout cause someone has already done all the artwork for me.
I only offer my clients the choice of themes that FileMaker provides. They're clean, easy to use and readily available for an interface incompetent like myself. So, I have mixed emotions about the new Universal Touch Theme. Supposedly, it includes several sets of styles in a single theme with a neutral color palette, allowing you to easily combine various styles and colors to make your own theme. Think of it as a starting point for your own theme.
I gotta say that's above my pay grade. I like the simplicity of using the works of a world renowned interface guru like Heather Winkle, former Director of Design at FileMaker, Inc. and creator of the themes. Call me crazy but I think she knows a lot more than all of us combined. Still, people will be drawn to this new theme in an effort to brand their own look and feel. Hats off to you if you have the skills. For the rest of us, I'd recommend to keep using the finished themes.
Now for the marketing spiel from FileMaker, Inc. The neutral color palette of the Universal Touch Theme is applied to all Starter Apps and Add-on Tables, making it easy to customize them with your own color scheme. It also has default field sizes and text block sizes geared towards all languages and platforms. Sounds like a winning idea but I'm still stuck on how to develop my own color scheme. I can tell when I like something, I'm just not very good at coming up with matching colors.
FYI: I asked the FileMaker development team if the Universal Touch Theme was aimed at a single layout for all devices. I had already tried the same layout on a Macintosh, an iPhone and an iPad and it worked remarkably well. So, I wasn't surprised when Robert Holsey said, "Yup, that’s the idea. The theme uses sizes and fonts that should work well across the entire platform. It is designed for touch first, but should still work well everywhere". If you're a professional developer, you should still design layouts for each device but beginners might find this theme eases the transition into intermediate FileMaker development.
Selecting and Modifying Grouped Objects This feature isn't at the top of my list but there have been times, with complicated layouts, where ungrouping and regrouping presented significant difficulty. The example I remember is the calendar solution available for sale on this web site. It has a complicated layering of fields and buttons in a portal, replicated 42 times to create a month view. Imagine the number of times I had to group and ungroup each of the sets of objects. I don't know how many times but I know it was multiplied by 42 every time :( The Objects palette, introduced in FileMaker 16, helped make editing the objects in my calendar solution much easier so I can see how editing grouped objects enhances the modification of complex layouts. I just don't see it as an every day feature.
The way it works is you click once to select the grouped objects and a second time to edit the objects in the group. The second click places a dashed rectangle around the objects. Now you can select any object inside the dashed border and resize, move, format or anything you can when the object isn't grouped. This feature couldn't be more natural to access and is likely to make tough jobs just a little easier.
Multiple Email Attachments Here's a feature that's been asked for so many times over the past decade, I never thought it would ever come to fruition. Hooray! Do I need to explain this one? Let's make sure. In FileMaker 16 and earlier, the Send Mail feature only supports a single attachment. That's one PDF, one image or one Excel document. That's it. With FileMaker 17, you don't need to purchase a plug-in for this single basic ability. Just add multiple paths in the Send Mail Attachments dialog. Normally, multiple paths are treated on a first come first serve basis but the paths in Send Mail are all considered matches. Just separate each path with a carriage return and you'll get a dialog like you see below.
In addition, the Send Mail script also supports multiple attachments using variables. Just declare as many variables as you want with the Set Variable script step and then include them in the Attach Files area of the Send Mail script step. Each variable just needs to be separated by a return, as with the static paths. Again, instead of the normal Specify File behavior, where FileMaker chooses the first valid path, the Attach Files option now looks at all paths.
Default Fields I'm not sure how much time this feature saves a seasoned developer. All it does is populate any new table with housekeeping fields, including a primary key, account create and modification and a timestamp create and modification. The first thing I'm going to do is change their silly naming conventions to match my standards and change the primary key to an auto-enter serial number instead of Get(UUID). Yes, you can modify an XML file to change the default names and characteristics of the fields but it just seems easier to copy and paste them from one table to another. It's not that the XML file isn't easy to read, I just don't want to do it on all of my machines. And, when I use a client's machine to work on a solution, I'll need to copy a modified DefaultFields.xml file to their computer... if I remember to bring it.
I sure wish FileMaker, Inc. would offer a simple toggle in Preferences to turn it on or off for those of this that find this feature unnecessary. Instead, you need to create a blank file named "DefaultFields.xml" to a particular location on your hard drive. I just used TextEdit to create the file but use whatever you want. It just has to be in the right location with the right name. Here are the locations:
If you want to modify the XML file to change the names of the fields or even change the options that get applied, here's the location. I highly recommend making a backup first.
Mac: /Applications/FileMaker Pro 17 Advanced/FileMaker Pro Advanced.app/Contents/Resources/en.lproj/ DefaultFields.xml
Win: <drive>:\Program Files\FileMaker\FileMaker Pro 17 Advanced\Extensions\English\
FYI: On the Macintosh, you can access the Contents folder by Control-Clicking the FileMaker application and choosing Show Package Contents. You'll also need to create the Shared folder.
BTW: I include a copy of the DefaultFields.xml file in the downloadable SEVENTEEN.fmp12 at the end of this article. It uses my naming conventions and auto-enters a serial number rather than Get(UUID).
Copy/Paste Custom Menus There's no screen shot for this feature because the dialog hasn't changed from previous versions. There's no Copy or Paste button like you see in Manage Database. No worries. I would use the keyboard commands anyhow. However, I do wish they had offered an import feature like they do with Custom Functions. Yes, there are almost always going to be way more Custom Functions than Custom Menus but copying and pasting more than one Custom Menu is going to exasperate my carpal tunnel with all that repetitive movement between files.
Security Ok, I said I was only talking about desktop features but Steven H. Blackwell would smite me if I didn't talk about new security additions to FileMaker Server 17. I think "smite" is a word they used when Steven was growing up but that was so long ago, LOL. Anyhow, the online help that comes with FileMaker 17 describes the account lockout feature as "after trying unsuccessfully to sign in to a hosted file several times within a few minutes, you are not permitted to try again for several minutes." I thought that was really vague so I asked the product management team for more specifics. What they told me is the lockout for the account occurs after five failed logons in a five minute time period. The account will be locked out for five minutes. If you're taking the FileMaker 17 certification test, just remember 5/5/5.
This feature requires FileMaker 17 Server but any client from FileMaker 14 and beyond can be locked out. However, earlier clients will get a slightly different error message than the one shown above. Conversely, if a FileMaker 17 client connects to a FileMaker 12 through 16 server, the old behavior of dismissing the credentials dialog after four attempts will occur and no lockout will be imposed.
In addition, this feature only works with internally authenticated accounts. Externally authenticated accounts, including oAuth, have their own rules for failed logon attempts. If a lockout occurs, it pertains to ANY file on the host where that account name is being used.
Scripts There are a few new script steps like Open Hosts and Open My Apps but they are inconsequential, merely opening the referenced menu item. There are also a few new iOS steps but I'm not discussing those in this article. I'm more interested in the changed scripts steps for the desktop.
For starters, Perform Script and Perform Script on Server have also changed and now support calculated script names. Just change the Specified script "from list" to "by name" and the familiar calculation dialog will appear. Then, all you have to do is specify the script name. An example of a simple static reference to a script might look like the following:
Not only can scripts from the local file be calculated but so can scripts in an external FileMaker file. Start by defining an external reference to the file in Manage External Data Sources, if one doesn't already exist. In the calculation on the Perform Script step, specify the external file using the data source name (not the file name), followed by two colons (::) and ending with the name of the script. It's almost like referring to a related field. For example, a simple formula specifying a static path to an external script might look like the following.
The new "by name" option allows you to shrink a conditional script down from ten, twenty or more lines of code to just one line. This is common in a dispatch script that controls other scripts. For example, you might have a master script that calls one of ten sub-scripts depending on a script parameter. The FileMaker 16 way would be to use a conditional:
If [Get(ScriptParameter) = "Script 1"] Perform Script ["Script 1"] Else If [Get(ScriptParameter) = "Script 2"] Perform Script ["Script 2"] # ETC End If
With FileMaker 17, that script would be just a single line:
Perform Script [Specified: By name; Get(ScriptParameter); Parameter: ]
Just be careful you don't change the name of one of the scripts or it will fail, unlike the hard coded predecessor in FileMaker 16.
A small change that might be big for some folks is the addition of folder or directory creation to more script steps. This feature allows users to create a folder right from the output dialog where you name the file, if you are allowing the dialog to be viewed by the user. This feature has been added to the following steps:
Export Records Export Field Contents Save a Copy as Save Records as Snapshot Link Save Records as Excel Save Records as PDF
I don't find this feature that useful since I name outputted files with data from FileMaker and place them in specified directory like the desktop. I just find my clients lose less files this way.
However, I do find the changes to Insert from URL and Show Custom Dialog script steps very handy! All the mother ship has done is add the ability to force results into a variable but this small change will unclutter the Fields tab in Manage Database since I won't need to add global fields just to temporarily hold some data. In the case of the Show Custom Dialog, any of the three input fields can now be changed to variables. For Insert from URL, the result can be returned to a variable.
Functions There are three new functions of which one is for FileMaker Go and the other is uneventful. GetSensor returns the value of the specified sensor for an iOS device and will not be discussed further in this article. Get(UUIDNumber) return a numeric UUID which is good for distributed systems but rarely used in my consultancy, preferring the more flexible serial number as a unique identifier. I'm not sure why we need a number counterpart to Get(UUID) but obviously some developer talked FileMaker, Inc. into adding this feature for some arcane reason.
However, Get(ActiveRecordNumber) could be quite handy. It's different than the existing Get(RecordNumber) which simply displays the number of the record as it appears in the found set. Get(ActiveRecordNumber) actually returns the active record number. For example, if you create an unstored calculation field containing Get(ActiveRecordNumber), it will populate all records with the same record number, updating as records are navigated.
SIDE TIP: The Get(RecordNumber) result is relative and will change depending on the found set and sort order.
Get(ActiveRecordNumber) and Get(RecordNumber) were designed to work together to identify the currently selected record in a found set portal. My first thought is the ability to make scripted buttons only appear on the active row using Hide Object and a simple comparison:
Get(ActiveRecordNumber) <> Get(RecordNumber)
But, I'm not sure how useful that would be. Then you would have to click on a record and then click on a button. There's probably some good reason why this feature was added but I don't think it's as obvious as other functions they added in the past. I even asked the FileMaker Development Team and they pointed me to the online help which showed how to make a button appear on the selected row. Been there, done that, LOL. I think someone will come up with the de facto standard super cool use for this function and I think it will have something to do with the Hide Object feature. We'll just have to wait and see.
Richard Carlton came up with something I think is a better idea for Get(ActiveRecordNumber). His idea is to make the text of the selected found set record turn a different color with conditional formatting. Both Richard and I have both tried to do this with object states on the Appearance tab in the Inspector but it's just not possible. So, I'm including both these techniques in the example file you can download at the end of this article. BTW, the conditional formatting formula is the opposite of the Hide Object formula:
Get(ActiveRecordNumber) = Get(RecordNumber)
I wish Get(ActiveRecordNumber) worked in a portal like Get(RecordNumber) but it just ignores the portal and shows the current record number. However, Get(ActiveRecordNumber) does work in list view but requires a refresh, unlike it's counterpart in a found set portal. No big deal, it's easy to set an OnRecordLoad script trigger to perform an Object Refresh on the button(s) you want to appear on the selected record.
Data Migration Tool The FileMaker Data Migration tool is probably the most significant feature released with FileMaker 17, allowing you to move data from a FileMaker file to a clone. It's not in FileMaker 17 but a separate command line driven executable UNIX file. On the Macintosh, I will be using Terminal which is included on every Macintosh in the Applications folder. However, you can download terminal applications for Windows as long as they run in 64 bit. Otherwise, everything else should be the same.
There are two reasons why this utility was created:
Customers that have experienced data corruption and need to revert to a clean clone of a FileMaker file.
Developers who want to quickly move information to a new version of their solution.
Both of the above scenarios require a significant amount of work to manually import data across many tables or script the process. Imagine all the time spent lining up the fields for each table and testing it to make no mistakes have been made. This tool is a godsend.
When opening Terminal on the Macintosh, you will be presented with a prompt similar to the following:
Of course, you will see the name of your computer and user name instead of mine. Everything needs to be typed in on a single command line but I will break it up into three parts so it's easier to understand for those uninitiated to the ways of UNIX. Start by typing the path to the FMMigrationTool. I'm using an absolute path which begins with the user information:
Mine happens to be on the desktop but yours might be located in a subdirectory. I'm not here to teach you how to create paths in Terminal so refer to this excellent blog called Coding Corner for assistance with absolute and relative paths. The next step is to enter the path of the source file that contains the data you want to migrate, beginning with the reference to "-src_path" to specify it as the source:
Make sure to type a space between the first entry specifying the location of the FMDataMigration tool and the source file, as well as between "-src_path" and the actual path. The next step is also preceded by a space separator:
Make sure this file is an unmodified clone. FileMaker flags a frsh clone and the migrator tool checks, as I found out the hard way. The entire entry will look like the following, just so you can see it all in one place:
Once you have typed the entire line, hit the Return or Enter key and you should see a report similar to the screen shot below, if everything is accurate. It took me a couple tries to get it right the first time.
If you're like me, this stuff is foreign. But, you have to admit, for command line, it's not that hard to do. It also works on any .fmp12 file including FileMaker 12, 13, 14, 15, 16 and 17. The tool just needs to run in a 64 bit environment. In addition, you can only migrate one file at a time. This tool is not trying to be a swiss army knife solution. Just a good solid tool with one command. Since most solutions are a single file these days, it shouldn't be an issue for most folks.
In order to get this tool, you need to purchase the FileMaker Developer Subscription (FDS) for $99.00. It includes a FileMaker Server Development License, Pre-release software, the FileMaker Training Series: Advanced and the iOS App Software Development Kit (SDK). The copy of FileMaker Server is test only, supporting only three licenses. FileMaker Business Alliance (FBA) members may not get access to this awesome tool so I'd recommend forking over the $99.00.
UPDATE: Apparently FMI decided to allow FBA members access to the Data Migration Tool via the FileMaker Community. If you aren't able to log on to the FileMaker Community, this link won't work.
SIDE TIP: On the Macintosh, you can drag files into the Terminal window and the path will be entered for you.
If you still find the command line interface challenging then Productive Computing, Inc. has a tool that provides an easier interface with drag and drop file paths. It's called the FM Data Migration Assistant and is completely FREE! Kudoes to PCI for giving away this tool! You'll still need to get an FDS subscription to gain access to the FileMaker tool but this offering from Productive Computing will provide ease-of-use even for terminal experts.
Format For better or for worse, FileMaker 17 continues with the same .fmp12 format. There are pros and cons about sharing a format with earlier version of FileMaker. The biggest disadvantage is the ability for someone to open a file with FileMaker 17 features in an older version. In some cases the features don't display and in others they just aren't noticeable. But, in all cases the features won't work and may perplex newbies. It's best to set the minimum version to 17.0 in File Options just in case. On the advantage side, anyone can open their FileMaker 12 file in FileMaker 17 and it will work exactly the same with no need for conversion.
Hidden Gem This new feature doesn't seem to be documented anywhere but it's one I've been hoping to see for a long time. The screen shot says it all! Ok, if you don't see it I guess I'll let you know. In FileMaker 17, you can now specify a script parameter without clicking into the Specify Script dialog. Do you know how much time this small little feature will save me. Instead of duplicating a button and changing the script parameter to match the current context using three clicks, I can now do it with one click. In addition, I won't be unwittingly attaching a script parameter to a script that doesn't need one just because I duplicated a button and didn't see the script parameter. I'm forever confused by script parameters that do nothing. It just wastes my time trying to figure it out. This feature should stop that poor use of my time.
Don't Worry For some reason, FileMaker, Inc. removed the next layout, previous layout, layout slider and current layout indicator from the toolbar, leaving you with just the Layouts menu to navigate. Maybe they thought it was a cleaner look but the first thing I did was customize my layout toolbar and added it back. Freaked me out when I first saw it but then I gradually realized it was probably just customization. Phew! Only two months off my life on that one, lol.
Final Thoughts I've bashed a few features but overall I think this is an awesome upgrade for the desktop! I especially like found set portals and the migration tool but there are many good features. Besides, my dislike might be another developers like.
This blog is completely free. Please support it by clicking on one of the advertisers at the left side of the window or becoming a patron. Thanks so much!
You do not need to type in the three paths! (on Mac; I don't know about Windows). Just drag each file into the Terminal window, and the path will automatically be filled in. Each file can be anywhere on your computer; they do not have to be in the same directory.
1: Launch Terminal.
Terminal starts, opens its window, and types in the command prompt, ending with a dollar sign and a space.
2: Drag the FMDataMigration file into the Terminal window from wherever it is on your computer.
Terminal will type in the complete path.
3: Type a space and then "-src_path" (without the quotes), and then a space.
4: Drag in the source Filemaker file from wherever it is on your computer.
Terminal will type in the complete path.
5: Type a space then "-clone_path" (without the quotes).
6: Drag in the clone Filemaker file from wherever it is on your computer.
Great overview JMO, thank you! I'm also excited about the data migration tool and the dialog change of being able to specify a script parameter without clicking into the Specify Script dialog. The dialog change will prevent a lot of parameter problems and create a big time savings!
You could use ActiveRecordNumber in a found set portal to easily highlight the selected record. First, you need to create an explicitly _unstored_ calculation field (e.g. zRecordNumber) that is set to Get ( RecordNumber ). That way, it evaluates relative to the field's context. Then, the row in the portal knows its own RecordNumber (within the portal), as opposed to the layout's record number. You may also need a field: zIsActiveRecord that is unstored and tests for:
Get(ActiveRecordNumber) = Get(RecordNumber)
Then, in the portal, you can use conditional formatting using the portal's zIsActiveRecord field.
I don't have FM 17 to test this, but that should work. You could do the inverse to have buttons that only appear in the found-set-portal row that is also the active record.
We discussed this possibility during the beta testing of FileMaker 17 but came to the conclusion that it was easier to highlight the active row using the object state in the Appearance tab in the Inspector. What we found wasn't possible with other features was changing the text color which is why I used it as an example in my video.
First off, love the website and your articles. This one was fabulous. Great job Mark, as always, and kudos for supplying the file - always makes life easier to see it in action. Been a big fan for years and I still have and have used a number of your articles in the old FileMaker Advisor. Kudos.
Yes, that is basically correct Steve. The Found Set Portals feature unclutters the relationship graph with a new way of creating pickers. But it does something else wonderful and merges form and list view. Maybe some people call this a picker but I call it icing on top of the cake for this new feature.