In a typical day, a FileMaker user is interested in storing information in a custom app and then reporting out on that data in many different ways. A record, at the very heart of FileMaker, accomplishes this need. Here, data is entered and stored, and from this object, information is retrieved. One way data is entered is through FileMaker Drag and Drop, and therein lies a problem.

The Life Cycle

A record has a life cycle. It is created, edited, and committed to the file. Sometimes it is deleted. This cycle happens over and over. A record may go through many edits and commits in its life.

A primary job of FileMaker developers is to control that record life cycle. We set up strict controls about when a record can be created, edited, and deleted. We build logic to ensure a record has the correct type of information, and we work to ensure that the record is committed with integrity.

Like a vampire or a walker, however, there’s a user experience piece of FileMaker that is completely outside this life cycle and disrupts how a record is manipulated and then committed. That is the Drag and Drop.

FileMaker Drag and Drop: the Gotchas

FileMaker drag and drop is a great feature for fast data entry. This feature is commonly used for container fields and PDFs or pictures, but it can also be used to drag text data to a field. And that action is the disruption. When dragging data from another source into FileMaker, a user is almost completely subverting the record’s carefully structured life cycle, and thus the unexpected can happen.

Here’s a possible scenario: The user drags a text block from a website or email. She wants to save the text of an article or the current price of an item. The user simply highlights the text on the web page and clicks on it. Holding the mouse down, she drags the text over to the open empty and inactive field on the layout. Finally, she lets the mouse go and the text fills the field.

To the user, all is good, but under the hood, all sorts of unexpected things are happening:

The record is never opened. Or is it?

Normally when I type in a field, the record opens. FileMaker holds this record open for all edits. This doesn’t happen in a FileMaker drag and drop scenario. The data viewer, when watching the function Get(RecordOpenState), does not update from zero. Practically it may have opened, but the problem is that we cannot get to the open state of the record.

The record is never committed.

Well, I take that back a bit. Yes. It is committed because the data is stored in the field and record. Like the open state, we cannot get to the moment before the record is committed.

The modification count goes up

The result of the function Get ( RecordModificationCount) in the data viewer, increments by one each time.

Object script triggers do not run at all or properly

Mislav Kos and Wim Decorte at Soliant Consulting have a great rundown of all the script triggers and when they happen. The script trigger sequence, however it breaks down in a drag/drop scenario:

• onObjectModify does run, but it runs after the record has already been committed (or the record has been closed).
• The rest of the triggers do not run at all, no matter if they were meant to be a pre- or a post- trigger.

These facts present many problems for the developer. We are not able to control the life cycle of the record. We don’t get to capture when a record is open or before it is committed. Our lack of control over these means we cannot rely on script triggers to check field data for validation or for anything else we might do.

The Solutions

We can’t allow users to enter data without going through the proper business logic. So I can think of two solutions: either disallow drag and drop or highly control when a user can enter data into a record by any means they wish.

Disallow it

The first method is easier said than done. FileMaker Drag and Drop a preference in the app on each user’s machine. It is NOT specific to the file. So a developer or IT person would have to turn this off for every user. And of course, it can be turned on again in the preferences menu by a savvy user.

Disable it

The second method holds more promise: As a developer I might want to control when a user can enter data. I would have a separate data-entry layout and scripting to open a record and then check to make sure the record can be locked. When finished, the user would click a button that runs a script that checks various validations and allows the record to be committed or causes it to be reverted. Controlling the life cycle of the record means I could allow drag and drop.

Disallow it (Again)

Going back to method one, there is a way to disallow FileMaker Drag and Drop for all fields in a table without resorting to visiting each machine to turn off the app preference. The technique consists of a nondescript little field (text or number type) in the table where we want to prevent inadvertent drag and drop. I named my field “zz_ValidationField” so it sorts to the bottom of the field list. I’ve learned this from wise people: sort fields that do not contain data to the bottom.

On this field, I added validation in this manner:

• The “Allow user to override during data entry” is unchecked.
• The Validation can happen either “Always” or “Only during data entry”.

• Validation by calculation is used. Inside this is the function Get(RecordOpenState).

• Uncheck the “Validate only if field has been modified” checkbox at the bottom left.

Explanation

This setup simply prevents drag and drop from happening when the record is not previously open.  This field’s validation will fail if the record is not open ( Get ( RecordOpenState) = 0 ) and thus will not let the data be saved. The custom message doesn’t come up since the record wasn’t open in the first place.

Conversely, if the user opens the record  (Get (RecordOpenState) > 0 ) via scripting or clicking in any field and then drags and drops, the validation will allow the drag-drop to happen as normal.

As FileMaker developers, we have to control every aspect of our custom app so that we can ensure data integrity. The FileMaker Drag and Drop experience, dragging text blocks or PDFs gets around our control unless we take an extra step to ensure that users don’t get carte blanche in adding data to the file.

Download Demo File

Download