"No Holding Back FileMaker Blogging"


Navigation:


Support this site by clicking on a sponsor below or becoming a patron!



$10.00 Beginner Video Training



Become a patron of this FREE web site!


Recent Blogs:

Everything Changes
Everything Changes

Subsummary Unique Count
Subsummary Unique Count

Scripted Change Log
Scripted Change Log

Abstracted Log
Abstracted Log

Decluttering
Decluttering


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.


Create a Complete Contact Manager


Quick Tip:

Indexing
FileMaker Pro indexes every word in a text field so that finds can be performed quickly. Think of the analogy of a book. Rather than trying to locate something by thumbing through each page, you look in the index and find all the pages numbers at once. FileMaker works in the same way. In order to make finds as fast as possible, the first 100 characters of every word is indexed. If you click into a field and type Command-I (Macintosh) or Ctrl-I (Windows), you can view the index of a field. Most characters are indexed but you may be surprised what characters designate a new word other than a space. The index does take up space, so if a field is not going to be searched on or used as a match field in a relationship, set the Storage Options in Manage Database to never index that field.



Beginner, Intermediate and Advanced Video Training


Fun Stuff:

FileMaker, Inc.
FileMaker, Inc. or FMI is a wholly owned subsidiary of Apple, Inc. It was once named Claris when it also sold MacWrite, MacPaint, Claris Emailer, ClarisWorks, etc. but changed it's name in 1998 when it focused on FileMaker. FileMaker started out as a DOS application called Nutshell but was shaped into the powerhouse it is today by Claris and FMI.



Beginner, Intermediate and Advanced Video Training







RSS Feed
Window Locking
Level: Intermediate
Version: FileMaker 20
Category: Scripting
Friday, January 5, 2024
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.

Window Locking


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.

Window Locking


With a simple one-to-many relationship, you can add multiple contacts to a single company record using a portal.

Window Locking


The focus of this article is that simple little button in the portal that goes to the related record.

Window Locking


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.

Window Locking


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.

Window Locking


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:

The Philosophy of FileMaker 20 Video Training



Author:
John Mark Osborne
jmo@filemakerpros.com
www.databasepros.com

Example File (available to patrons at $5.00 per month): Download here if you are a patron

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!

Add Comment:

First Name: *
Last Name:
Email: *
Web Site:
Comment: *
 Email Addresses will not be shared on the web site!