Saturday, August 21, 2010

New Template Part 2

In April I mentioned I'm updating my standard starter template: this has been completed and used for a couple of solutions now.

One of the main reasons for the upgrade was the interface design changed introduced in FMP 10 and carried over to FMP 11: the status area is now a user-configurable toolbar area at the top of the screen, and not at the left hand side as had been in FMP 9 and earlier, since time began.

Computer monitors are now all "widescreen" so while they offer a broad vista horizontally, vertical screen space is at a premium. The new design is very frugal with screen space vertically to allow for this.

I have also put a HUGE amount of development effort into managing multiple windows. Many solutions use global fields or variables to track interface and navigational data such as the currently selected tab or the field that the table is sorted by. All of these solutions suffer the problem that they only work for one window: if the user makes a new window of the current screen, there is no way to track this navigation data for each window separately.

My solution stores the navigation and interface data in global variables that incorporate the window name into the variable, thereby allowing multiple windows to exist independently and simultaneously. The trick (or one of them, there are many) is to encode the window name to ensure that only variable-legal characters are used. Script triggers introduced in FMP 10 generate the global variables automatically as users create windows and clear them when the windows are closed.

To achieve the creation of the global variable names I create a 32 bit binary hash of the window name and convert this to decimal, which reduces it to around 16 characters (variable names can be up to 100 characters). This step alone required my learning about hash algorithms, selecting one that would be appropriate for the reasonably short window names expected - the HashFNV1a algorithm - and re-creating the algorithm as a FileMaker recursive custom function. This in turn required the development of a custom function to XOR two binary numbers. I've shared both my hash and XOR functions on Brian Dunning's custom function site, bringing my contribution to 12 functions there.

XORbin
HashFNV1a32

I then created custom functions to work as an "interface" for generating the variable names in one step, and another for reading the variable name in one step. The system worked extremely well until I had a large data set on a hosted file, when in list view the screen would slow to a crawl. The problem was traced to the fact that the hash was being recalculated for each record displayed on the screen. I solved it by "patching" the hash custom function with another that cached the window name and the hash result in a global variable, so the hash value is only ever generated once per session. Problem solved!

This system is now in 3 solutions that I have developed and implemented, and it's working well.

Interestingly, in a previous job I was in the interview panel for my replacement. They mentioned that that had used my custom functions for calculating the DistanceBetweenPoints in one of their biggest projects.

2 comments:

  1. The link to DistanceBetweenPoints takes you to XORBin. The correct link for DistanceBetweenPoints is http://www.briandunning.com/cf/143

    ReplyDelete