Meta-Consulting
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.
Search for Empty Searching for records with an empty field works most of the time using a single equal sign (=). It can fail if a user has fat fingered a field by entering a space, a return or some other invisible character. While the field contains valid characters, the field is technically empty. In order to avoid this problem, search with two equal signs (==).
DevCon History Here's a list of the FileMaker Developer Conferences* through 2020:
#
Year
Location
23
2020
Nashville, Tennessee**
23
2019
Orlando, Florida
23
2018
Grapevine, Texas
22
2017
Phoenix, Arizona
21
2016
Las Vegas, Nevada
20
2015
Las Vegas, Nevada
19
2014
San Antonio, Texas
18
2013
San Diego, California
17
2012
Miami Beach, Florida
16
2011
San Diego, California
15
2010
San Diego, California
14
2009
San Francisco, California
13
2008
Phoenix, Arizona
12
2007
Orlando, Florida
11
2006
Orlando, Florida
10
2005
Phoenix, Arizona
9
2004
Phoenix, Arizona
8
2003
Phoenix, Arizona
7
2002
Palm Desert, California
6
2001
Orlando, Florida
5
2000
Palm Desert, California
4
1999
San Diego, California
3
1998
Monterey, California
2
1997
San Jose, California
1
1996
Santa Clara, California
* Name changed to Claris Engage in 2020 to match renaming of FileMaker, Inc. to Claris.
**Due to the COVID-19 virus, this conference was changed to a virtual conference.
Window locking is akin to record locking and is considered the same error when it comes to the Script Debugger (301). Essentially they are the same except that window locking doesn't require the FileMaker solution to be hosted on a server to reek havoc with scripting and manual editing of records. In other words, window locking is record locking in a single-user scenario but only on the same record. It has nothing to do with multiple users.
Demonstrating Window Locking Window locking might be best demonstrated using a simple example of Companies and Contacts. Imagine you have a table of companies with multiple contacts for each company.
With a simple one-to-many relationship, you can add multiple contacts to a single company record using a portal.
The focus of this article is that simple little button in the portal that goes to the related record.
Every programmer does it but do they ever consider window locking? Sure, record locking is a big thing but what about what happens when the record is being edited in the portal and then the GTRR button is clicked? Try it and you'll find you can can't edit the record in the resulting window. That's because you can't edit the same record in two different windows, even in single-user mode, no matter what type of window is displayed. Document, Floating, Dialog and Card windows will all lock the record if it's being edited in the parent window in the portal.
First Thoughts Your first thought might be to commit the record using the Commit Record/Request script step before performing the Go to Related Record step. That'll work fine on the first related record in the portal but if you click the button in any other row, it's always going to go to the first record. Even though committing the record releases the lock, it also deselects the current portal row. Therefore, the GTRR step simply goes to the first related record displaying in the portal.
My First Time The first time I tried to solve this problem, I continued to use the Go to Related Record step but tracked the window names with a script variable and the Get(WindowName) function. It worked fine but the script was obtuse, there was some flashing going back and forth between the two windows (even with the Freeze Window script step) and it didn't work with the Card type window. I had to go to the related record, reselect the original window with the Select Window script step, commit the record and finally reselect the new window. It was a crazy script that I quickly discarded.
FYI: A Card Window is attached to the parent such that they move together. Therefore, the parent window cannot be selected or referenced. The same is trued for the Dialog type window since it is locked on top of the parent. The child window can be moved but the parent cannot be selected.
A Better Way I knew there had to be a better way but my brain was fixated on the Go to Related Record script step. Once I thought outside the box, the solution was so simple. All you have to do is set a variable to the related record primary key, commit the record, open a new window and perform a find. Error capturing is even needed because you know you are going to find that primary key in the related table. It's that simple.
FYI: I would still use the GTRR script step whenever possible since it's easier to implement with just a single script step.
Additional Thoughts This find technique is also useful when you don't have a portal or relationship already made. Just as the ExecuteSQL function was designed to unclutter the Manage Database dialog from single purpose relationships, so can this find method serve the same purpose. In my long development career, I have found there is usually a relationship already available but if you find yourself in a situation where you are creating a relationship for a single feature, consider both of these methods.
Alternatives There are always alternative methods depending on the situation so I want to go over a couple so you don't think opening a new window is the only solution. A new window is best when drilling down several tables deep to create related records of related records. You really have no choice but to open a new window and possibly another new window, depending on how deep you need to go. But, if you have just one level then consider a popover.
Popovers are easy to program and allow access to related data from a portal that is too small to display all the fields. What a popover can't do is allow diving through multiple levels of related records. Just as you can't put a portal inside a portal, you also can't put a Popover inside a Popover.
Other solutions include an email button to access an email address that can't be displayed in the portal. You'll still need a new window or a popover to enter the data (unless there is some other interface outside the current layout) but it can allow you to quickly email a contact, as shown in the example file included with this article.
The same is true for accessing the mobile phone which can't be displayed in the portal. Just use the Dial Phone script step to dial the phone. A major drawback of the Dial Phone script step is it's not compatible with the Macintosh operating system. Windows and iOS are good to go.
Find out More This article comes from an excerpt from my full length videos titled the "Philosophy of FileMaker 20". Just visit:
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!
