Avoiding Multi Window Record Locking

Introduction

This is what we are trying to get rid of. That situation where you lock yourself out of a record because you already have it open in another window. We've all seen it, and it can be highly frustrating.

The issue is more prevalent in solutions that employ session/interface-based approaches, where the user may be editing records through a particular record that defines their session. Unless managed then spawning new windows can result in the user ending up on the same record.

There is no great reason why a user should ever see this dialog - a user can only ever interact with one window at a time. It makes little sense to leave a window in an uncommitted state while they move to another window - well at least in my experience!

So come with us on a journey to find a solution to this timeless problem, you may learn a thing or two along the way.

Example File

This article is based on our example file which also includes examples of the solution you can try out, along with additional information. We highly recommend downloading and checking it out while you read. We spend a lot of time on these!

Download the example file here

Time For a History Lesson

Let's go back now. The year is 2010. The Web Viewer has been out now for a couple of years since version 8.5. It's slowly gaining traction as a tool for not just displaying google or FedEx websites, but as a way to enrich solutions with Javascript integration, helped largely in part by Digital Fusions Reactor plugin.

Back then the Web Viewer behaved slightly differently than it does today. It had a particular quirk in how it evaluated its URL calculation. The calculation would evaluate not only when the web viewer was in focus, but also when not in focus, and even more importantly even when the window which the web viewer was in was not the active window.

A young Weetbicks saw this as an opportunity to exploit and exploit he did. If a Web Viewer was evaluating a calculation when the active window changed, we could use it to write a calculation that determined if a window had just lost its focus, and if so run a script using a plugin (Reactor at the time) to commit the window.

This was the code:

Let ( [

~windows = WindowNames ( Get ( FileName ) ) ;

~active = GetValue ( ~windows ; 1 ) ;

~this = Get ( WindowName )

];

"data:text/html," & 

If ( ~this ≠ ~active and Get ( RecordOpenState ) ; ReactorRunScript (  Get ( FileName ) ; "Commit" ; "" ) ; "" )

)

The beautiful thing about this code is that the calculation would evaluate from the context of the Web Viewers window - that being the one that just lost focus.

Fast forward to some time in the future - perhaps around FileMaker 14 (we are not quite sure) and this technique no longer worked. The Web Viewer now only evaluated its calculation when loaded, or when it gained or lost focus.

Why Not Use an onTimer?

It's now 2022 and we were still looking for a solution. Now, there obviously has been a solution right in front of our noses for many years - an OnTimer script. Why not just install an OnTimer in every window that checks whether the window is active, and issue a commit if it is not? 

This does work. The issue we have however is that it is an active approach. We are forced to run a script every 1-2 seconds to do this check. This can become really annoying especially if trying to do development or debugging. 

We did however use this technique recently in our article on how to prevent users from becoming IDLE in a record, and quietly commit them. This was using an OnTimer.

Here we wish to use a passive approach - something that sits in the background and only rears its head when required. This was what the Web Viewer provided us in 2010, and now we need a new solution.

Shifting Our Attention to Window Focus

Our earlier Web Viewer approach was concerned with determining when a window had lost its focus. Now however we switched our attention to finding something that might evaluate on a layout when a window gained focus as this seemed more likely than the former approach.

We tried most things but it seemed in this day in age no layout object would reevaluate its calculation simply by losing or regaining window focus.

Are Web Viewers the Solution? (again)

Once again we pursued the web viewer, although it proved fruitless. They seem like the best approach given their ability now to perform FileMaker scripts from within the Javascript.  Try as we might, the closest we could get was an implementation that relied on the Web Viewer being given focus in order for its code to evaluate - it simply wasn't going to cut it.

Purely out of interest we included this in our example file for you to see in action. The Javascript code checks whether the document has focus or not, and is able to carry out an action accordingly, such as running a FileMaker script.

Aha! Custom Menus!

The only element of a layout we could find that would actually evaluate a calculation when a window gained focus is that of a Custom Menu. When a window gains focus a Custom Menu can be evaluated to determine its visibility and its name. This happens every time a window gains focus.

That was the breakthrough required!  Credit must go to our friend Steve Senft-Herrera who put us on the right track here and suggested the Custom Menu could be the way to go.

Now it seemed so simple:

1. Use a Custom Menu Set on your layouts.
2. Attach a Custom Menu where its name contained a calculation.
3. Have that calculation run a FileMaker Script to Commit the previously selected window.

And that's exactly what we did.

Forcing a Commit Record

We force a commit in a calculation by using a plugin. These days we prefer BaseElements Plugin by Goya. Note that the issue of window record locking is mostly a desktop issue hence why we are not focussing our efforts on iOS and WebDirect as both of those platforms have solutions to this issue through different design choices.

The code is pretty simple:

BE_ScriptExecute ( "Commit" )

We put this into a custom function so we can easily modify the code if need be.

Dealing With Other Situations That Can Load a Custom Menu

It's not just window switching that forces a custom menu to load. The following will also do this: 

• Window Changes (obviously)
• Switching Modes
• Switching Views
• Switching Layout

We only wish to run on a window change, so we needed a way to suppress all the other situations.

 The solution in our script is to set a global variable to the active window name but only do so if the active window name is different from that stored in the variable currently. Only when they are different can we be sure a new window has been selected.

Dealing With Runaway Scripts!

Now that we are only concerned with when the active window changes, the rest of our script can commit the previous window as follows:

1. Select Old Window
2. Commit
3. Re-select New Window 

Uh-oh, we have a problem! We know our script will run every time a window is given focus, and steps 1 and 3 both switch windows and will trigger our script. 

We wish to avoid our script firing on both of these script steps.

To do this, we set a global variable - $$SUPPRESS - used to suppress our script triggering for the duration of when it is set. 

This $$SUPPRESS variable is checked in our menu calculation and if it is set will not trigger our script to run again.

The @COMMIT Custom Function

So let's look now at the calculation that drives everything from the Custom Menu. We put this in a Custom Function simply so we can easily edit the code.

If (  $$SUPPRESS ; "" ;  Let ( ~commit = BE_ScriptExecute ( "Commit" ) ; "" ) )

First, if the suppress variable is set we do nothing and return an empty string.

If it is not set then we wish to initiate our Commit script which we do using a Let statement. We return an empty string.

This custom function can be placed in any calculation in a Custom Menu, such as its name or visibility. We prefer to place it in an existing common Custom Menu that would appear in any Menu Set, such as within the File menu. Because the function returns an empty string we do not need to worry about it impacting the rest of a calculation for name or visibility.

In Conclusion

We have come a long way since 2010 and while the Web Viewer technique back then was actually a bit nicer (and if it worked today would be even nicer with FileMaker.PerformScript instead of a plugin required) we have adapted and found a viable solution to this issue.

Can you improve on this technique or offer any valuable insight or feedback? We'd love to hear from you in the comments.

Example File

As mentioned above, we always include an example file with our articles to help you learn and explore. We spend a lot of time on these so please do check it out.

Download the example file here