Team DF and Weetbicks blogs and news

RAG Bots In FileMaker - An Early Exploration

Wed, 13 May 2026 09:55:36 +1200

Introduction

In our previous articles we have looked at what AI is, how semantic search works, how AI features like embeddings are showing up in FileMaker, how to generate a response from a model, and most recently the "Perform SQL Query by Natural Language" script step. If you've been following along, you may have noticed we're building towards something practical…

A way to literally talk to your data!

We want to build a chatbot that we can have a natural conversation with about a specific client or project. Not a generic AI that knows a bit about everything, but something that knows our data: meeting notes, project history, correspondence, and anything else we know about that client. Something we can ask questions of and get useful answers back.

The technology that makes this possible is called RAG, Retrieval-Augmented Generation. In this article we're going to look at what RAG actually is, how it works, what we're trying to build with it, and the three main ways we see that you could approach it.

Disclaimer: At the time of publishing, all prices and storage limits in the article were accurate. But the world of AI is moving fast and changing quickly. Please be sure to verify the costs and limits against recent documentation.

So What Is RAG?

RAG stands for Retrieval-Augmented Generation, and it’s the core idea behind any system that lets you chat with your own data.

To understand why it matters, it helps to think about the problem it solves. Language models are trained on enormous amounts of text, but that training has a cutoff date, and more importantly it doesn't include your data. If you ask a language model about a meeting you had with a client last Tuesday, it has no built-in knowledge of that at all... and nor should it!

This is where AI systems can start to get into trouble. Newer models are better at admitting when they don't have enough information, but they can still guess, fill in gaps, or sound more certain than they should. Without access to the real client data, that's exactly the kind of situation where you can end up with a plausible-sounding answer that isn't actually true.

One obvious way around this is to just include all your data in the conversation. Dump all your client docs into the prompt and ask the model to answer based on them. That gives the conversation Context.

We do not recommend sending your raw data to an AI...

(Or any other API type service for that matter — your accounting system might be the exception.)

If data privacy matters, that usually means using a paid AI model rather than a free one. Even then, it is worth checking the settings carefully to make sure your data is not being retained or used for training. That can improve things, but it still does not give you full control. If you want the highest level of security and ownership over your client data, a local setup is really the only option.

RAG is the smarter solution, instead of throwing everything at the model, you first retrieve only the most relevant pieces of information, then add just those to the prompt before asking the model to respond. It's more targeted, more efficient, and helps ensure the answers generated are based on real data. That's what reduces the risk of hallucinations.

The "space" where your embedded documents live, is what we are calling a RAG space. OpenAI calls theirs Vector Stores; other providers use different terminology, but the concept is the same.
RAG works in two stages:

Retrieval: when the user asks a question, the system searches the RAG space to find the most relevant pieces of information.
Generation: those pieces are handed to a language model, which reads them and uses them to produce a response.

So How Does Retrieval Work?

The retrieval stage is essentially a semantic search. If you have read our Diving Into Semantic Search article, a lot of this will be familiar. If not we encourage you to read that article for more detail.

The first step is to embed all of your documents using an embedding model to get a vector for each one. These vectors are what is actually stored in your RAG space. You could think of the vectors as a sort of index based on meaning.

When a user asks a question, that question is embedded using the same model, producing its own vector. The system then compares the question's vector against every document vector in your RAG space using cosine similarity. The documents with the highest cosine similarity scores are the ones retrieved and passed to the language model.

It's also worth noting that retrieval quality is heavily influenced by how you chunk and structure your documents before embedding them. Smaller, focused chunks tend to produce more precise results, because the vectors are based on smaller chunks of text, and therefore the meaning the vector represents is more precise.

Large monolithic documents can dilute the semantic signal and make it harder to find the right content. We touched on that in our semantic search article, and the same principles apply here.

Building a RAG Bot for Client Data

Now that we understand what RAG is, let's talk about what we are actually trying to build.

The goal is a chatbot that knows about a specific client: their meeting notes, project history, correspondence, and anything else relevant. This is where a lot of the earlier pieces start to come together: embeddings, semantic search, and generating responses from models all in one workflow. The model never needs to be trained on any of this data. Instead, each time a user asks a question, the most relevant documents are fetched from that client's RAG space and placed in front of the model in real time.

The key design decision is that we want a separate RAG space for each client. This way when a user opens a chat for Client A, the system retrieves from Client A's space only. This keeps responses focused and avoids the risk of information from one client bleeding into answers about another.

So the question becomes: what's the best system to build this on? We will be looking at 3 different options:

OpenAI Vector Stores
Claude / Anthropic with an External Vector Database
Local RAG with FileMaker AI Server

As we investigate each option we will post accompanying articles.

Welcome Matt!

Fri, 10 Apr 2026 11:39:00 +1200

Firstly, we’d like to announce and warmly welcome Matt Haughton to the team here at Digital Fusion. Matt joined us in late February and has already become a valued member of the team.

Now onto Matt himself—and importantly, what makes him a special person and a great developer?
The good news is we didn’t need to dig too far; he provided plenty of nuggets of gold himself.

Matt comes to us with a Bachelor of Science in Artificial Intelligence. In 2026 that’s very relevant—but he was awarded the degree in 2002, so he was clearly ahead of his time. Claude tells me that was when the rest of us were still trying to master Snake on our Nokia 3310s.

After completing his degree, Matt moved into the world of FileMaker, working across multiple industries in the UK. In 2009, he joined a UK Claris Partner, MaJic Solutions, based in Milton Keynes.

You may be wondering what brought Matt to New Zealand. Well, this is where the real nuggets of gold start to appear.

Matt was an avid player of the game Clash of Clans, as was his clan leader—who just so happened to be based in New Zealand. Over a number of years, a romance blossomed, with the clan leader eventually travelling to the UK to meet Matt in person.

The relationship continued to grow, and the pair were married in Christchurch in 2016. They then returned to the UK, where they lived for seven years before ultimately making their way back to New Zealand.

We’re pleased they saw the light and are now living and working in Christchurch, along with Matt’s daughter.

Matt’s a man of many talents—and a few quirky life choices…

He may look very innocent, but he’s trained in the art of Brazilian Jiu-Jitsu.
Like all good modern men, he’s a dab hand in the kitchen and enjoys pairing his meals with a well-made cocktail.
Matt didn’t arrive in Christchurch empty-handed—he also brought along his three cats: Christopher, Jasper, and Kevin.
And in one of life’s more questionable decisions, Matt once drove a Ford Ka completely decked out in Astroturf. If that raises a few questions, be sure to check out the photo below.

We’re thrilled to have Matt as part of the Digital Fusion team. He brings an extraordinary depth of experience, a razor-sharp technical mind, and the kind of personality that makes the office an even better place.

Natural Language Queries in FileMaker (2)

Thu, 06 Nov 2025 10:08:00 +1300

Introduction

If you haven’t yet read Part 1 of the Reconnect article, we suggest you read that first. Part 1 covers the Perform SQL Query by Natural Language script step, the different available variables and how to set them. We also cover how the script step works and interacts with the selected LLM.

In this article, we are diving into the different methods you can use to improve the results of the script step. We will look at how you can set up LLM comments in your database and the kind of information that needs to be in these LLM comments. We will also be covering how you can set up different prompt templates and the sort of information that you can include in them.

The DDL and LLM Comments

Now I am sure there is some confusion around the DDL at this point, so let's try and clear that up. In my opinion, the DDL is misnamed. What DDL actually stands for is Data Definition Language, which makes the “Get DDL” action the equivalent of a “Get English” action. What you are actually getting with the “Get DDL” action is the database schema, expressed in the Data Definition Language, for the tables you’ve allowed the model to access. So really, a “Get Table Schema” action would make more sense.

Even Claris’ own documentation describes it this way:

“Returns the database schema (in Data Definition Language) that this script step generates and sends to the model.”

(Claris Help – Perform SQL Query by Natural Language)

What’s in the DDL

When you run the Perform SQL Query by Natural Language script step, FileMaker builds a DDL structure for each table you’ve selected.

The DDL includes:

The table name
The field names
Each field’s data type (text, number, date, etc.)
And any comments associated with those fields

For example:

If you haven’t set up any LLM comments, the entire schema for every selected table is sent through. This is rarely what you want. In larger systems with wide tables, this can mean hundreds of fields and long comment strings being transmitted — adding unnecessary tokens and irrelevant detail for the model to process.

How LLM Comments Change the DDL

FileMaker provides a way to control what is actually sent to the model by marking specific comments as LLM comments. These are just ordinary field comments in the Database Manager, but when you prefix them with `[LLM]`, FileMaker recognises them as AI-specific instructions.

Example:

Once you add even one LLM comment to a table, FileMaker changes its behaviour, and only fields with LLM comments are included in the DDL; all other fields in that table are excluded

This has three key benefits:

Token efficiency – the DDL sent to the model is much smaller, so requests cost fewer tokens and execute faster.
Privacy control – sensitive fields like driver’s licence numbers, tax IDs, or internal notes are simply omitted from the data the model ever sees.
Reduced context noise – irrelevant or low-value fields (such as system flags, constants, or relationship keys) are excluded, so the model focuses only on the schema that’s meaningful to the query. This makes its understanding sharper and reduces the chance of it generating SQL that references unrelated tables or join conditions.

From Claris’ own best-practice guidance:

“Add the [LLM] tag to limit fields included”
(Schema Best Practices for SQL Generation)

Writing Effective LLM Comments

Because the model only sees schema and comments (not live data), a well-written LLM comment needs to include all the context a human developer could infer from the data itself.

That means describing:

What the field represents
Possible or expected values
How those values should be used or filtered

Good example:

Poor example:

The first one gives the model usable context to generate the right SQL, even when multiple fields or tables could be relevant.

Best Practices for LLM Comments and DDL

Using LLM comments turns that schema into a controlled vocabulary for the model, ensuring it understands what each field means while keeping your solution efficient and private.

If you’re building anything more than a quick demo, start by adding LLM comments to your most important fields. It’s the easiest way to shape how the model sees your data — and just as importantly, what it doesn’t see.

A few habits make a big difference when setting up LLM comments and managing what goes into the DDL:

Keep it focused - Add LLM comments only to fields the model needs. Once you add even one, only those fields are sent — keeping the schema smaller, faster, and cheaper to process.
Exclude what you don’t want shared - Leaving [LLM] off a field is the easiest way to hide sensitive or irrelevant data, such as licence numbers, constants, or internal keys.
Explain intent, not just names - The model can’t see your data, so be explicit. Describe what the field means, possible values, and how it should be used.[LLM] Record status. Values: 'active', 'deleted'. Only include 'active' records.`
Stay consistent - Use a clear, repeatable format for comments — what the field is, what values it holds, and how to use them.
Iterate as you go - Test a few queries, see what the model gets wrong or overuses, and adjust your LLM comments to guide it better next time.

Being deliberate with your LLM comments keeps the schema lightweight, protects private data, and gives the model just enough context to produce accurate SQL without guesswork.

Prompt Templates

Now that we’ve covered the DDL and how the model understands your schema, the next question is: how does it know what to do with it?

That’s where Prompt Templates come in.

Prompt Templates act as predefined instruction sets that tell the LLM how to behave when interpreting a query. They sit between the user’s natural language prompt and the database schema, giving you a consistent and controllable framework for how SQL is generated and how responses are phrased.

You configure them using the Configure Prompt Template script step, and then reference the template name inside Perform SQL Query by Natural Language. Each template can hold two optional components — an SQL Prompt and a Natural Language Prompt — which are sent along with every request.

The Two Prompt Types

Each template has two prompt options you can enable:

SQL Prompt
Natural Language Prompt

They do very different things.

SQL Prompt
The SQL Prompt gives the LLM a list of rules on how to structure its SQL. This is essentially the system prompt for the query generation part. It defines things like:

How to format field names and dates
Which functions to avoid
How to limit rows
What parts of the schema are allowed to use

Here’s an example based on one of my templates:

During testing, I found the model kept returning queries that used the DATE_TRUNC function, which isn’t recognised in FileMaker. So I added a rule to tell it not to use that function. These prompts will probably evolve as you discover little quirks or unsupported syntax that cause errors.
You can also use the SQL prompt as a bit of a safety net. For example, you might add information about a field like “record_status” so that if a full LLM comment is missed, the model still knows how that field should be used.

Natural Language Prompt
The Natural Language Prompt is much simpler. It just tells the model how to return the final answer — the format and style of the response, not the SQL itself.

For example:

You can think of this as the “presentation layer” for the model’s response. In most cases, you won’t need to edit it much — once you’ve got a format you’re happy with, you’ll likely leave it as-is.

Using Prompt Templates in Practice
Prompt templates are stored in memory once configured, so I normally call Configure Prompt Template early in the process — usually during file open or before the first query is made. After that, I just pass the template name into any Perform SQL Query by Natural Language script steps that need it.
Because the templates are separate from the scripts, you can update and refine them without touching any user-facing code. This is especially handy when you’re trying to fix small issues — you can adjust your SQL rules, add or remove restrictions, or fine-tune the tone of the model’s answers without needing to edit multiple scripts.

Best Practices for Prompt Templates

Here are a few things that have worked well in practice:

Create different templates for different contexts - Keep the rules focused on one area of your system (e.g. contacts, sales, projects). This makes it easier to manage and debug.
Iterate as you go - Start with the defaults and adjust the SQL Prompt whenever you notice recurring issues — like invalid SQL functions or unwanted joins.
Use a numbered list - The model follows instructions more reliably when rules are listed clearly in order. Avoid vague instructions such as “try to”.
Always include the schema reference - End your SQL Prompt with `Only utilise the following database schema: :schema:` so the model stays anchored to your actual tables.
Keep the Natural Language Prompt simple - It doesn’t need much tweaking beyond defining how you want the answer displayed (plain text, summary, etc.).

Summing Up

The new Perform SQL Query by Natural Language script step opens up a completely different way to interact with FileMaker data — but it’s not magic out of the box. To get meaningful, accurate results, you need to teach the model how your system works.
The DDL defines what the model can see. LLM comments let you refine that definition, focusing only on the fields that matter and stripping away the noise. Prompt templates then shape how the model interprets that schema and writes SQL, giving you consistent, predictable behaviour across different contexts.
When you combine clear [LLM] comments with well-tuned prompt templates, you turn FileMaker’s “natural language” query from a novelty into a genuinely useful interface for exploring data — one that feels simple for the user but is carefully engineered behind the scenes.

Natural Language Queries in FileMaker (1)

Wed, 05 Nov 2025 12:05:00 +1300

Reconnect - The Illusion of Simplicity: Natural Language Queries in FileMaker

If you attended Reconnect  2025, you will have seen our presentation on integrating natural language queries with FileMaker. If you missed it, consider saving the date for next year. These companion articles build on that session, offering more detail and letting you explore the concepts at your own pace.

But first the original presentation:

Overview

The session explored how natural language queries can enable users to interact with their solution and data using the “Perform SQL Query by Natural Language” script step to create a chatbot. But it's not as simple as just plugging in the script step and giving it a chatbot interface. For example, here we do have a correct answer in that there are 5504 records in our contacts table; however, in our system, we use soft deletes, so 1500 of those contacts are not visible in the system and should not be counted.

We walked through:

The script step and the various parameters that can be set
How the script step interacts with the LLM
Different ways to improve the results
LLM Comments
Prompt templates
A simple use case
A summary of good practices to get into

In this article, we cover the first two points, first going over the script step, followed by how it works and interacts with the selected LLM. In the second article, we cover the different ways that you can improve the results.

Perform SQL Query by Natural Language Script Step

This script step lets you query your database using plain language instead of writing SQL by hand. It uses an AI model to interpret your prompt, understand the database structure, and generate the right SQL queries. Once those queries are run, the model can return the results in natural language.

The process typically works like this:

The script step sends your prompt and the relevant database schema (based on the Data Tables you’ve specified) to the configured AI model. This can include any extra context from a prompt template.
The model analyses both the prompt and schema, then generates one or more SQL queries to get the requested data.
The script step receives the generated SQL and executes it.
The results of the SQL query are sent back to the model.
If the model decides that more data or further refinement is needed to answer the prompt fully, it can generate and run additional queries (repeating steps 2–4). This allows for more complex, multi-step queries.
Once the model has what it needs, it produces a final response based on the original prompt and the query results.
The script step then stores that final response in the Response Target.

This is a large script step with a lot going on, a minimum of 11 different options you can set, so we broke this down into each of the different options.

Account Name

Before any of the new AI script steps are used, you first need to call the “Configure AI Account” script step once. This script step really only needs to be called once at file open, and then the account name used in that call can then be used for all the other AI script steps.

This script step allows you to set an account name (plain text), select your model provider (a drop-down list of the following providers: OpenAI, Anthropic, Cohere, or Custom), and also enter an API key (plain text).

Model

The model is the Large Language Model (LLM) that you want to use for this script step. This is entered in plain text, and must be a model from the provider that was specified in the “Configure AI Account script step.

Prompt

This can be a variable or a field, and is simply the question you want answered. From our example, this would be: “How many contacts in the system?

Options specified

There are a couple of different ways to set the options. First, there is the “From List” option, which gives you access to a dropdown list of Actions, a few different ways to select tables that the script step will have access to, and also shows the“Stream” checkbox option (which we will cover later in this article). The second way to set the options is via a JSON Structure, which allows a more dynamic way to setup the script step. You can generate the JSON in the script and pass it as a variable to the script step, this means that you don't need to edit the script step when you want to do things like change the tables that you want access to.

Actions

There are 5 different actions available. Most of these are to enable you to see what the LLM is sending back in response to the script step being run, but one action is to expose some of the information that you are sending through to the LLM.

Tables

To select the tables that you want to be able to query, there are three different options: From list, By name, and By DDL.

From list: Select specific tables from a list.

This allows you to select any table occurrences in your current file. This is an important thing to note if you have a data separation model (a user interface file and a data file). You will need to make sure that you have a table occurrence of any tables from your data file if you want to have access to them.

By name: Provide a list of table names as a text expression.

Separate multiple table names with carriage returns. A simple text list of the table occurrence names. Again, these have to be in the file you are currently in.

By DDL: Provide a custom DDL text expression.

This allows you to control exactly which schema information is sent to the model.

We will discuss DDL further on in this article, but in short, the other options for selecting tables will automatically send the DDL for the tables you select through to the LLM to allow it to understand the data structure. If you select the “ByDDL” option, then you will need to construct the DDL for the tables yourself, and this is what is sent through.

Stream

The stream option determines how the response is delivered when the Action is a Query.

On: The response is retrieved and delivered incrementally (word by word or in phrases). This can make the FileMaker client feel more responsive.
Off: The entire response is retrieved before it is made available. This may cause the FileMaker client to appear unresponsive while waiting for the complete response.

Prompt Template Name

We will look at the prompt templates in more detail later in this article, for now, you just need to know that you can use the “Configure Prompt Template” script step to expose FileMaker's default prompt templates and name and edit these, or simply create your own prompt templates. Once the “Configure Prompt Template” script step has been called, you simply enter the Template name that you chose into this option on the “Perform SQL Query by Natural Language” Script Step.

Parameters

This is a JSON object that consists of key-value pairs for additional parameters that are supported by the model provider. For example: `{"temperature": 0.7, "seed": 42}`. You should refer to the model provider's documentation for key names of supported parameters and their valid ranges.

Response Target

This is simply the specified field or variable that you would like the response to be saved into.

Perform JavaScript in Web Viewer

This option allows you to specify a Web Viewer object and a function to call in that Web Viewer. This is how we displayed the conversation in a messaging window.

How it Works

The “Perform SQL Query by Natural Language” script step works a little differently from most script steps we are used to. Usually, we call a script step and expect that step to do just one thing. e.g.

Set Field
Go to Layout
Pause Script
Etc.

The “Perform SQL Query by Natural Language” script step has a bit of back and forth with the LLM to get a result.

First, the prompt (User's question) is sent through to the LLM along with some instructions on how the LLM should answer, and the DDL (table schema in the Data Definition Language)
The LLM processes this prompt and additional information and formulates an SQL statement that is sent back to FileMaker.
FileMaker runs the SQL statement.
FileMaker sends the result of the SQL statement back to the LLM (Even if there are errors)
Steps 2-4 may be repeated several times in order to get a final result.
The LLM sends back a final result that is then displayed to the user.

You can think of the LLM as an intern or apprentice; it will do its best to produce the correct SQL statement the first time, but it may not always get it correct. This is why there is a feedback loop here, the first statement may be wrong, it may have some valid SQL that FileMaker cant process correctly, as FileMaker's ExecuteSQL function only supports a limited subset of SQL syntax. So the result is fed back to the LLM to allow for another attempt to get the answer to the prompt.

Summary

In this first part, we’ve taken a closer look at how the “Perform SQL Query by Natural Language” script step actually works. We have broken down each of the available options, explored how FileMaker communicates with the LLM, and walked through the sequence of steps that happen behind the scenes when a query is run. What looks simple on the surface is in reality a layered process involving schema definitions, prompt handling, and multiple rounds of interaction between FileMaker and the model.

In Part 2, coming soon, we’ll move on to the practical side — looking at how to improve the results you get from this script step using LLM comments and prompt templates to get more consistent and reliable answers.

Tool Calls: Giving AI Agents the Keys

Fri, 26 Sep 2025 16:05:12 +1200

In a previous article we looked at how AI agents can plan tasks and do more than just answer questions. To perform those tasks, agents need a way to interact with other systems. This is where tool calls come in. Think of tool calls as the verbs that let an agent take action—fetching data, running a calculation, or sending a message.

What are tool calls?

A tool call is simply a request an agent makes to another service to get something done. This fits into the broader agent model discussed in our companion piece “From Chat to Action: Agentic AI in FileMaker”, where an agent isn’t limited to conversation but can plan, act and iterate. Imagine you ask a colleague to look up the weather: you give them a clear instruction and they return with the result. A tool call is the same idea, but formalised for an AI.

Developers are used to writing API calls, such as `GET /weather?city=Auckland`, to make software talk to a weather service. Agents don’t know how to write code. Instead, they select from a list of tool descriptions and fill in the blanks. Each description tells the agent what the tool does, what inputs it expects and how to provide them.

These descriptions are part of a growing set of AI‑native services. Unlike traditional APIs built for programmers, AI‑native services are written in plain language so that an agent can understand them. Once a tool is described in this standard way, any compliant agent can use it, no matter who wrote the tool.

How does a tool call work?

As Claris FileMaker developers, we can think of tool calls like calling a custom function or script step. You define the inputs and outputs, and the AI just plugs them together to carry out your request.

Tool calls follow a straightforward cycle:

Recognising the need for help – the agent reads your request and realises it doesn’t have the information or ability to answer on its own.
Picking a tool – it looks through its available tools and chooses the one that fits the job, guided by the descriptions.
Creating the request – the agent writes down the tool name and the details it needs, such as which city to look up.
Running the tool – the system running the agent executes the request. Importantly, the agent doesn’t run code itself; it hands off the work.
Getting the results – the tool sends back the answer.
Using the answer – the agent adds the new information to its conversation and plans what to do next.

Because the agent never runs code directly, you can set strict rules about which tools it may use and how their outputs are handled. For instance, you might only allow an agent to read data but require a human to approve any changes.

Why give AI access to tools?

Allowing an agent to call tools expands its usefulness well beyond writing sentences. In our companion article, From Chat to Action: Agentic AI in FileMaker, we discussed how a smart assistant can interpret your natural‑language query, plan what it needs to do, pick the right tool and iterate until it completes the task. When you marry that agentic logic with FileMaker’s new AI script steps, you get a system that understands what you mean and then works with your data in safe, predictable ways.

Here’s why tool access matters – and how it plays out in FileMaker:

Understanding your intent and run the right script step. The agent translates everyday language into specific actions. Using the Generate Response from Model script step (with appropriate tool definitions), a user can ask, “What is the average invoice total for customer X over their last 10 invoices?” The agent is able to interpret this request and call the appropriate tools to complete the task and answer your question.
Fetching fresh data from your own app. With the Generate Response from Model step in agentic mode, the AI can call FileMaker custom functions to run SQL queries. This means the agent isn’t guessing at answers; it’s retrieving up‑to‑date information directly from your database.
Chaining actions into a workflow. As described in the agent article, the AI can plan its next steps and decide what to do next. In terms of our question above, this means it can execute SQL to retrieve the last 10 invoice totals. It can then call the appropriate calculation tools to work out an average.
Keep things grounded and controlled. Tool calls rely on real data, which reduces the risk of hallucination. Because you define the tools – for example, which fields can be searched or which functions can be called – you control exactly what the agent can do. And with Set AI Call Logging, you can record every request and response for auditing.
Work seamlessly with structured data. Tools return results in predictable formats, making it easy for the agent to use them in its reasoning.

By combining natural‑language understanding with clearly defined FileMaker actions, agents become practical assistants that can interpret your queries and act on your behalf. The model isn’t free to do anything it likes – it calls only the tools you’ve described, and FileMaker’s script steps give you a high degree of control over those interactions.

Cautions when using tools

Giving an agent access to tools is powerful, but it also increases the risks. The same safeguards recommended for agents apply here:

Scope – define exactly which tools are available and what actions they can perform.
Transparency – keep logs of each call and its parameters. FileMaker’s tool call logging and other platforms’ tracing features are invaluable.
Human oversight – review the outputs before applying changes. Use agents to suggest actions rather than performing them automatically.
Security – keep API keys and credentials safe. Don’t expose them to the agent’s chat history.

You should also consider what happens if a tool returns no results or an error. Just like with FileMaker scripts, you should build in error handling so the agent doesn’t loop endlessly or give misleading answers.

Remember that tool calls are part of a bigger system. When tools are well described and access is carefully managed, they enable agents to move beyond static chat into practical assistants. Misconfigured or overly permissive tools, however, can lead to unwanted changes or security issues.

Summing up

Tool calls give AI the ability to act. By defining tools with clear descriptions and parameters, you create a safe environment where an agent can fetch fresh data, perform computations and automate tasks on your behalf. As the ecosystem of AI‑native services grows, understanding how to design and manage tool calls will help you unlock the full potential of agentic AI.

With these new commands in FileMaker we can get started now — so start small: define one or two safe tools, test them with the Generate Response from Model step, and log every call. You’ll quickly see how tool calls move AI from text "chat" towards practical, controlled automation.

Possible use case: Post-meeting voice capture in FileMaker Go

After a client meeting, a user can open FileMaker Go on their iPhone and say something like, “Create a new note for Customer X. The contents should be…”
The agent understands the request and then uses the appropriate tools to find the contact, create a new note record, and populate it with the dictated notes.
You could even get the AI to improve/summarise the dictated notes.

Tool calls turn AI from a talker into a doer. For Claris FileMaker developers, this means moving beyond chatbots into assistants that can fetch, calculate, and act inside your apps—with you always in control. Start experimenting with small, safe tools, and you’ll discover just how far agentic AI can take your FileMaker solutions.

From Chat to Action: Agentic AI in FileMaker

Tue, 02 Sep 2025 03:00:00 +1200

Artificial intelligence is rapidly appearing everywhere, and new features arrive so quickly that it can be hard to separate marketing hype from genuine advances. When FileMaker 2024 added AI script steps, we explained how to harness those tools without getting lost in the hype. This article continues that mission and focuses on AI agents.

If you’re wondering what an agent does and how it differs from a typical chat interface, read on…

Simple Chat vs AI Agents: What’s The Difference?

A simple chat system is very good at having a conversation. You ask a question and it responds based on what it has learned from existing text. But that is all it can do. Imagine talking to a helpful librarian: they can tell you what they remember, but they aren’t allowed to leave their desk or look at any new books. They can’t go into the archive to check records, phone another library for an update or fill out a form for you.

Going Agentic

Making AI “agentic” can be likened to giving that librarian the keys to the archive, a telephone (or an internet connection!) and a checklist…

It can still talk to you, but can now also:

Plan multiple steps – it breaks down a task into manageable steps rather than answering in one go.
Use external tools – it knows when and how to run a search, query a database or use a calculator.
Decide what to do next – based on what it finds, it chooses whether to keep searching, try a different approach or finish.
Work iteratively – it can loop through these steps until it completes the task.

Put simply, a chat system is like a conversation that never leaves the room. An agent turns that conversation into a set of actions. It still "thinks” with the same kind of language model, but by calling tools and services it can fetch fresh information and carry out tasks that the model alone could never perform.

Why Not Stay With Simple Chat?

Traditional chat interfaces are wonderful for brainstorming and summarising text, but they have some important limits. Imagine reading from a reference book that was published last year: it will never include today’s news or weather. In the same way, language models are trained on data up to a certain date and do not know about anything that has happened since. They also can’t do anything with your data — they can’t look up a record in your database, check a live stock price or move a file.

Because a simple chat system cannot look up fresh information, it sometimes tries to fill the gap with a best guess. This is known as “hallucination”, when the system produces an answer that sounds plausible but isn’t correct. An agent overcomes these limits by recognising when it needs help, calling the appropriate tool and using the result to inform its answer. By tapping into live data sources and other services, the agent reduces the risk of outdated or invented answers and can actually perform tasks on your behalf.

AI Agents In Practice

When FileMaker added the Generate Response from Model script step, it included an Agentic Mode that behaves like an AI agent. In this mode, your script can send instructions that describe what the agent should do and which tools are available. The agent plans its workflow, calls the appropriate tool (e.g. `execute_sql` or a custom function) and returns the result. You can even inspect the order of tool calls for debugging purposes.

Similarly, the wider AI ecosystem is moving towards AI‑native services. Anthropic’s Model Context Protocol (MCP), introduced in late 2024, created a standard language for agents to talk to all sorts of services.

Software providers are building AI‑native interfaces that expose human‑readable descriptions and parameter schemas, making it easier for agents to understand how to interact. Within months of the protocol’s launch, thousands of tools appeared, allowing agents to access databases, browse the web, manipulate files and send emails.

For example, Xero introduced an MCP back in March this year, and other services such as Stripe, Paypal and Slack have MCP options.

What Should You Watch Out For?

Giving an agent access to tools is powerful, but it also increases the risks. Our earlier advice about not letting AI modify your data still applies. Keep these cautions in mind:

Scope – define exactly which tools the agent can use. For example, expose a read‑only SQL query function but not a function that updates invoices.
Transparency – log each tool call and its parameters. FileMaker’s tool call logging and other platforms’ tracing features are invaluable.
Human oversight – review tool outputs before applying changes. Use agents to suggest actions rather than performing them automatically.
Security – ensure that API keys or database credentials are stored securely and not exposed to the agent’s chat history.

Agents are also subject to the usual AI limitations: they inherit biases from their training data, can misinterpret instructions and may need careful prompting. While tool calls reduce hallucinations, they don’t eliminate them entirely.

Summing Up

An AI agent combines the conversational strengths of a language model with the ability to act. By defining what it can do and placing guardrails around those actions, you create a safe and structured environment where the agent can plan, call tools and iterate. This turns a chat‑style exchange into a workflow capable of retrieving real‑time information, performing computations reliably, and automating routine tasks.

With thoughtful design and human oversight, AI agents can move beyond simple chat into genuinely useful assistants that save time and reduce manual work.

Example Use

Let's say you've come out of a meeting and want to capture your thoughts and actions

Using an AI agent you'd be able to open FileMaker Go and say something like: “Create a new note for Customer X. The contents should be…”
The agent understands the request, and then uses the appropriate tools to find the contact, create a new note record, and populate it with the dictated notes.
You could even get the AI to schedule the next action reminder or extract key points from what you've said.

Generate Response from Model

Wed, 06 Aug 2025 12:39:56 +1200

FileMaker 22 (also referred to as FileMaker 2025) introduces a range of new tools for integrating AI into your solutions. In this post, we’ll be focusing on the Generate Response from Model script step, which allows scripts to send prompts to an AI model and get a response. At its simplest, it drops a ChatGPT-style chat straight into your solution; type a prompt, and get an answer. This is similar to using ChatGPT in a browser, but switch on Agentic Mode, and that same step can plan tasks, invoke tools such as SQL queries or own custom functions, and iterate until it gets the result you need.

Just like previous AI features, you’ll need to run the Configure AI Account script step first. This sets up the AI account by name, specifying the model provider (or endpoint) along with an API key. In this example, we’re using OpenAI, but the script steps also support Anthropic, Cohere, and even custom endpoints.

Once your AI account is configured, you can use Generate Response from Model to interact with the model of your choice.

At its simplest, this script step works just like ChatGPT in a browser: you send a prompt, and the model replies. It doesn’t know anything about your FileMaker file or its data; it’s just a general-purpose LLM chatbot. The real power of the Generate Response from Model script step comes when you enable Agentic mode. So what is agentic mode?

Agentic Mode

Agentic mode is where the AI behaves more like an agent, meaning it can:

Plan its next steps
Use tools or external functions to carry out tasks
Make decisions based on the outcomes of those actions
Work iteratively, evaluating results before continuing

This is quite different from the usual prompt-and-response setup, where the AI just replies to what it’s given. In agentic mode, the AI can reason through a problem step-by-step and call tools as needed.

LLMs are inherently probabilistic, meaning their responses can vary each time. But in agentic mode the LLM can use tools, which adds a layer of determinism, allowing the AI to produce more consistent and reliable results.

Generate Response from Model - Tools

When Agentic mode is enabled on the Generate Response from Model script step, the AI is given access to two built-in tools provided by Claris: `execute_sql` and `retrieve_image`. You’ll find more detail on both in the Claris Help documentation.

In addition to those, you can expose any Custom Functions in your file as tools for the AI to use. All tools must be defined in a JSON structure that’s passed to the AI agent. The exact structure can vary depending on your model provider, so it’s important to check their documentation. OpenAI’s guide for tool usage can be found here.

In general, each tool definition will need to include:

the name of the tool
a description of what it does
a list of parameters it accepts
a description for each parameter, including whether it’s required or optional

Generate Response from Model - Agentic Setup

To get started with Agentic mode, there are only a few key fields you need to set:

Agentic Mode

Enables agentic behaviour, which allows the model to plan and take actions using tools.

Tool Calls From Model

This is a response field. When the model uses tools, the results will be returned here in the order they were called.
This is mostly used for debugging, as it shows which tools the model called and in what order.

Instructions

This is where you describe the agent’s role using plain language. For example, what it's meant to do, what tools it should use, and what kind of output you expect.

Tool Definitions

This is where you enter the JSON that defines which tools the AI can access. This might include the built-in Claris tools or any custom functions in your file.

Generate Response from Model - Demo

We’ve included a simple demo file that shows how to use this script step to build an AI-powered calculator.

Download The Demo!

The file defines four custom functions:

CF_Add
CF_Subtract
CF_Multiply
CF_Divide

Alongside these, we’ve added three tables: Agents, CustomFunctions, and CustomFunctionParameters.

These tables use calculation fields to generate the JSON tool definitions that get passed to the model.

The CustomFunctionParameters table generates the JSON for each tool’s parameters (the properties block), e.g.,

This parameter JSON is combined in the CustomFunctions table to create the full JSON definition for each tool, e.g.,

The Agent table pulls all the individual tool JSON objects together into a single JSON array, which is passed to the model as the Tool Definitions.

A simple way to confirm that the AI agent is working and actually using the tools is to modify one of the custom functions to return an obviously wrong result. For example, change CF_Add to always return 99, then ask the agent, “What is 2 plus 2?” The response should come back as 99, showing that the model used the tool rather than calculating the answer itself.

DF Con 2025

Wed, 23 Jul 2025 12:13:07 +1200

While not the most exciting name, “DF Con” is our own, internal-only, Digital Fusion Conference and we had our 5th one back in June — once again, it was a huge success so I'll share some insights in to how we do this and what we get out of it all.

Born out of the pandemic to avert cabin fever (i.e. being stuck in NZ!), we created our own event. It’s proven to be a winner in terms of knowledge sharing, team building, and just plain geek-out fun.

Theme

The moniker “DF Con” is rather generic so we spice it up with a unique theme each year: our destination this year endured a rather large tectonic event not so long ago, and of course a tonic is good for reinvigoration, so combining those two ideas gave us:

TECH TONIC

And with that we created a “logo”, printed some posters and some merch (thanks to our wonderful, long time client QTCo!)…

…and of course, developed a Tech Tonic cocktail — “Hex on the Beach”

(er, as in hexidecimal numbering system used in coding... not casting spells!)

Kaikōura

This year we headed to Kaikōura, a small coastal village 2.5 hours north of Christchurch New Zealand.

The Sudima Hotel

One thing we've learned from doing these events is that the venue makes a big difference because it shapes the dynamics of the conference, from the mixing and mingling, to the smooth running, quality of food and of course, the service.

And that's why we returned to the superb Sudima Hotel for a second time. It's luxurious, great value, all under one roof, and with staff and organisation second to none. It's ideal for us and we'd highly recommend it for either a personal trip away or a company conference.

Mixed Agenda

So, what did we do exactly? And was it beneficial?

Well, we’ve honed the formula over the years, and each year it seems to get better… needless to say, DFCon 2025 was the best yet!

So here's what we did exaclty:

There were 7 presentations and 3 panel discussions over the two days:

Autonomy and Alignment — factors as we grow the team, by Craig and Kris

Designing and Tuning Large Databases — tuning for performance, storage and manageability, by Daniel (aka Weetbicks)

FileMaker Upgrade Tool — A deep dive into the "Claris Upgrade Tool" for patching FileMaker databases, by James

A Day In The Life of Running The Office — a highly entertaining look at the administrative side of DF, all represented in The Sims 2, by Karesha and Cindy

Everyone's In Sales — at least that's according to Stu who ran us all through a sales 101 course in 15 mins flat!

Mental Models In UI Design — presented by one of our in house interface designers, Paul Baker

Claris Studio — What's happening with this new product from Claris and how does it complement FileMaker, by Sam

The sessions were interleaved with group panels where 3-4 people were selected to discuss certain topics of interest:

FileMaker ETS — What’s coming in the next version of FileMaker and specifically, how will these new capabilities be useful in the solutions we build.

SysAdmin — everything to do with hosting, networks, software setups and information security.

AI and FileMaker — discussing when and how we should be using the new generative AI tools.

But Wait… That’s Not All!

We also had 2 Hands-on Workshops

#1 Working with OData — a pivotal integration technology for the platform going forward, run by Paul Hutton.

#2 Working with AI — we added and tuned an "App Assistant" agent to an existing CRM database solution, run by Oscar Frith-Macdonald

Both were immense fun due to the gamified way the guys put the workshops together, making for extraordinarily engaging learning exercises.

And then there was the Bonus Session:

“Ask Me Anything” a sort of fireside chat with the boss…

AND… there was a quiz and a scavenger hunt interleaved, some nice meals and a few beverages to help quench the inevitable thirst (for knowledge of course)!

Afterwards, we surveyed attendees (which was everyone in the company) and the feedback was overwhelmingly positive with accolades and thanks to the organising team (Stu, Cath, Karesha), the presenters, the activity organisers, and the destination!

It's a big call to close up shop for a couple of days, and we thank our patient clients for bearing with us if your support was affected, but the overall impact on team building, collaboration and professional development is huge: we will keep doing this as it helps us be better developers and a better team.

FileMaker 2025

Thu, 10 Jul 2025 12:14:15 +1200

FileMaker 2025 Arrives!

FileMaker 2025 was recently released, and we are pleased to say that there are a number of features that are quite user-oriented which I'd like to highlight.

(There are plenty of others talking about the developer oriented stuff too of course such a Soliant's very thorough piece on this new version.)

The following features are ones that we think that you as our clients will find interesting and hopefully result in either a better experience or discussions about how they can be used better in your business/organisation.

FileMaker 2025 = FileMaker v22.0

We will start with a quick side note. As with the last two releases of FileMaker, Claris has done a good job of confusing everybody with their release numbering. As much as this article is on FileMaker 2025, the technical version number is FileMaker v22, and that’s likely the numbering you will hear from your developer. It seems the marketing and tech departments at Claris can’t get together to decide on a less confusing path. For the remainder of this post, we will refer to things as v22, v21, etc.

Upgrade Now?

Next up, the question we get a lot when new versions are released: when should we upgrade? Our suggestion is that you hold off for a month or two, let the dust settle, and let them get any bugs ironed out. We typically see Claris release one or two point updates (e.g., FileMaker v22.0.1) in the first month or two post-release, taking into account anything that needs fixing.

Saying that, if you are one of those people who feels the urge, if you do upgrade FileMaker Pro to v22, you can still connect to FileMaker Server v21.0 but not older versions of FileMaker Server.

Keep in touch with your developer; they can give you guidance on when it’s right to upgrade.

Onto the features that might appeal or be of interest…

AI Capabilities

AI is the big news in this new release of FileMaker. There have been AI features in v20 and v21, but with v22 we are taking the next big leap. The three major improvements are:

LLM integration — the ability to use AI language models (LLMs) directly in FileMaker scripts
Vector search — this gives us the ability to search on “meaning” from both data and images.
Natural Language Query — the ability to ask questions of your database in plain language

To help understand the value of these, here are some very simple use cases where you can imagine things in action in your own solution:

Extract meaning from PDFs.

Let’s say you have PDFs in your database, such as meeting notes, documentation, contracts, invoices, purchase orders, etc. We can now feed these to a language model, which in turn allows you to ask questions about the information and data in the PDFs.

Searching images by description

You spend a lot of time out in the field collecting data and taking photos via FileMaker Go on your iPhone or iPad. You may visit the same site 6-7 times over the space of a year, and you want to be able to search for all images taken over those 6-7 visits.

As with PDFs, FileMaker can now catalogue the “meaning” of those images—i.e., extract a description of the image. This means you can search through the images based on descriptions of what you’re looking for.

Automate customer support

One of your clients has a question; they send it to you via email, where it gets parsed into your FileMaker solution as a query. With the use of AI, we can identify that client and potentially answer that question without the need for human input.

For example, a client wants to know what stage their job is at. They email in, FileMaker picks this up, identifies the customer, looks into their job tracking area, identifies where the job is at, creates an email, and sends this back to the client. This is a very simplistic example, and there are likely to be ‘checks and balances’ along the way, but it demonstrates where you can get better efficiency.

Let's conclude our discussion about AI and FileMaker

Security around the use of AI is paramount both for yourselves, Digital Fusion, and FileMaker. With the current release of FileMaker, we now have more options from both the commercial providers such as OpenAI, Cohere, and Anthropic, but if they don’t suit, then we can use a local LLM on a server of your own so that data isn’t being shared out in any shape or form.

Enhancements

As much as AI is the hot topic, there are some other points that we think might be of interest:

FileMaker WebDirect — For those users of WebDirect, we are now pleased to say that Claris has somewhat resolved the issue of using the back button. Now when you click the back button, you will get a warning box that asks if you want to leave the site. This is a great addition, as we have been putting ‘workarounds’ into our solutions for the last few years.

New look on Mac — If you are a Mac user, you will notice that there is a new look when you upgrade to FileMaker Pro 22. For Windows users, don’t fret; this is really just a reshuffle of how a few things look. We are hoping they will include this same look for you shortly.

OData API — Everyone now should know what an API is and what it does, but for those that are still a little confused, it’s the ‘pipe’ that runs between two pieces of software to allow for sharing of data. Not all APIs are created equal; sometimes the ‘pipe’ is very thin and restricts the flow of data.

The good news is Claris is now moving ahead with the OData API being its preferred. This means we can connect to more pieces of software and do it better. Connected software/applications are the future, so we are excited by what's possible.

One side note: Claris will deprecate the Data API at some point (we expect it to be a few years off). This will mean that at some point we may need to get into your solution and do a bit of switching about, but we will be in touch if/when that happens.

Harnessing AI In FileMaker

Wed, 28 Aug 2024 10:59:11 +1200

Let’s face it, the tech world is going crazy over “AI” with promises of exciting and seemingly unlimited potential on offer. There’s a lot of hype, and it’s hard to determine the reality of what ’ve got now, where it’s going, and what we can and should be doing with it all.

So our aim here is to “keep it real” and take a close and practical look at the ways we can use AI tools now to enhance FileMaker solutions. Our plan is to keep experimenting with the new stuff and to share here in our blog what we’re learning and what we’re thinking can be achieved.

As an example, the new Semantic Search capabilities mean we can provide the ability to search textual data stored in the database based on “meaning”. The implications of that are that maybe we could be capturing and storing more descriptive text in our solutions.

Let's Get It Started

To begin with, Oscar's written a great foundational piece looking at the way AI technologies are built. If you’re a developer, it really helps to have that stuff in mind, so we recommend starting there:

An AI Overview

Semantic Search

Our first "deep dive" is into semantic search with FileMaker:

Diving Into Semantic Search

But as part of this intro, let’s first take stock…

What Have We Got Now?

The standard API capabilities already in FileMaker have allowed us to integrate external AI services but there are now new features coming to FileMaker which open doors for how we use AI right within the database. FileMaker also has had the ability to use machine learning (great for pattern recognition) for a long time.

But as of latest version of FileMaker 2024, we’re seeing the first specific tools for LLM and generative AI being added to the platform — Claris are rolling these new features out progressively with each new update. Here’s what the state of play is now:

Claris FileMaker Pro 2024 brings:

New AI script steps:

Configure AI Account: Simplifies setting up an AI account by name, integrated with providers like OpenAI. Custom models can be configured by entering the endpoint.
Insert Embedding: Embeds vector representations of input text into fields or variables within FileMaker Pro.
Insert Embedding in Found Set: Extends embedding insertion to all records within a found set, enhancing bulk data processing capabilities.
Perform Semantic Find: Executes semantic searches within specified fields, refining search results based on contextual meaning rather than exact keywords.
Set AI Call Logging: Controls the logging of AI calls for enhanced traceability and debugging.

New AI functions:

CosineSimilarity: Calculates similarity between two embedding vectors, aiding in data comparison and analysis. It returns the similarity as a number between -1 (opposite) and 1 (similar).
GetEmbedding: Retrieves vector representations of input text as container data using designated embedding models.
GetEmbeddingAsFile: Converts embedding vectors from text to binary container data format.
GetEmbeddingAsText: Converts embedding vectors from binary container data back to text format for easier manipulation and analysis.
GetTableDDL: provides table information in Data Definition Language (DDL) format, facilitating schema management and integration tasks.
GetTokenCount: Estimates token counts for specified text inputs, useful for AI model training and validation.
Get(LastStepTokensUsed): Retrieves details on tokens utilised in the last AI script step executed, aiding in script debugging and optimisation.

As you can see from this list, FileMaker is currently geared towards embedding vectorized LLM data and using that to perform semantic searches, so that’s what we’ll start with.

Before you dive in, here are a few considerations to keep in mind:

Cautions!

A general rule of thumb: Don't use AI to modify actual data in your systems.

As discussed in our previous article, it’s crucial not to allow AI to directly modify your FileMaker data due to the potential pitfalls. For instance, you should avoid letting an AI model calculate your average invoice amount or handle anything related to numerical data—tasks better suited to traditional tools in FileMaker. Remember, the AI models we’re working with are large language models, not mathematical models.

Instead, use AI to provide recommendations and insights, which you can then review and implement manually. AI can also be a great tool for summarising large blocks of text, though you may want to add an extra line at the end to state that this summary was produced by an AI model, similar to OpenAI’s DALL_E 3 adding an AI watermark in the metadata.

This approach ensures:

Accuracy: By reviewing AI recommendations, you can verify their accuracy before applying changes to your data.
Control: Maintaining manual control over data modifications prevents unintended consequences from AI errors or biases.
Transparency: Understanding and documenting the decision-making process ensures that changes to your data are transparent and justifiable.

If you are going to allow an AI to modify your data, it is important to keep an unmodified version of that data and have a human verify any modifications the AI makes.

Some Uses For AI In FileMaker

Now with the warning out of the way, what are some good uses of AI in your FileMaker solution?

1. Data Analysis and Reporting

AI can quickly analyse large datasets to identify patterns, trends, and anomalies that might not be immediately obvious to a user.

Generate Insights: Automatically produce comprehensive reports that highlight key performance indicators, trends, and forecasts within your FileMaker databases.
Anomaly Detection: Identify outliers and anomalies in your FileMaker data that could indicate errors or opportunities for further investigation.

2. Predictive Analytics

By using historical data, AI can make predictions about future outcomes. In FileMaker, predictive analytics can be applied to:

Sales Forecasting: Predict future sales based on past performance and current market trends within your FileMaker solutions.
Inventory Management: Forecast inventory needs to prevent overstocking or stockouts using your FileMaker data.

3. Enhanced Search and Retrieval

AI can improve the search capabilities of your FileMaker databases by understanding context and relevance, leading to more accurate and relevant results. In FileMaker, enhanced search functionalities can:

Semantic Search: Go beyond keyword matching to understand the intent behind a search query, providing a more accessible way to query the data in your solution.

4. Natural Language Interfaces

AI-powered natural language interfaces enable users to interact with FileMaker using everyday language. In FileMaker, natural language capabilities can:

Simplify Queries: Allow users to ask questions or make requests in plain language, which FileMaker can interpret and execute.

Where Can You Start?

While we did mention that AI can be used for data analysis, reporting, and predictive analytics, These are tasks more suited to the machine learning side of AI, and these tools have already existed in FileMaker for a long time.

As previously mentioned, the new script steps introduced with FileMaker 2024 are geared towards embedding (or vectorizing) your data through a language model (LLM) and using that approach to perform semantic searches on it. So let’s dive into adding a semantic search to a FileMaker solution:

Diving into Semantic Search

Diving Into Semantic Search

Wed, 28 Aug 2024 10:32:08 +1200

In this article, we’ll take a deeper dive into semantic searches—what they are, how they work, and when to use them. I'll start by answering some fundamental questions:

What is semantic search?
What is embedding?
How does embedding enable semantic search?
When should we use semantic search?

Next, we will share our journey of implementing AI in a FileMaker solution, including the step-by-step process of setting up a semantic search. And finally, there is a demo file provided so you can play with semantic searches yourself and see how different models perform.

So, What Is Semantic Search?

A semantic search is a search technique that aims to improve search accuracy by understanding the context of terms within a search.

Unlike traditional keyword-based searches, which match exact words, semantic searches consider the intent behind the search and the contextual relationships between words.

What Is Embedding?

Embedding is the process of taking your complex data and converting it to a string of numbers, where each number represents some “attribute” of the original complex data. In natural language processing, embeddings convert words, phrases, or sentences into vectors of real numbers, capturing semantic meanings and similarities.

For a more detailed explanation of embedding, please refer back to our last AI article.

How Does Embedding Enable Semantic Search?

Embedding allows the semantic meaning of words or phrases to be given a set of numerical values. We can then compare these values to find data with a similar meaning rather than being an exact match of words or phrases.

When Should We Use Semantic Search?

The first thing you will need to consider is the type of data you want to work with. It's likely that a lot of the data in your FileMaker solution is actually too structured for semantic searches. For example, there is little point in doing a semantic search on invoice totals; this is very clear and structured data and best suited to traditional search methods.

Semantic searches are much better used for searching blocks of text for meaning and context. So if you have all of your client meeting notes in a database, this would be far better suited to a semantic search.

Traditional Keyword Search:

Query: "project deadlines"
Results: Returns notes that explicitly contain the exact phrase "project deadlines."

Semantic Search:

Query: "project deadlines"
Results: Returns notes that discuss topics related to project deadlines, even if they use different phrases or terminology. For instance:

"We need to finalise the timeline for project completion."
"The client is concerned about the due dates for deliverables."
"Ensure the milestones are met within the agreed schedule."
"Deadlines for the project phases were reviewed and adjusted."

Embedding Your Data and Using Semantic Search

The first step in using AI is to configure your AI account. This is done with the Configure AI Account script step. This allows you to either select OpenAI or set a custom endpoint. You will likely want to incorporate this script step into your startup script to ensure that an AI session is started for a user when they open the system.

Next, you will want to embed your data. As discussed, a lot of your data will not be suitable for a semantic search, and it's probable that even the data that is suitable could be improved. Given the previous example of client meeting notes, we can actually improve the context of those notes very simply by creating a field containing all the data you want to embed. The easiest way we found to do this is to create a calculation field that is a list that includes all the data you want to embed, in this case the client name and a brief description of what the notes are.

Selecting a Model

You may need to be careful with the model you use when embedding your data. Models have limits on the number of tokens sent per minute (TPM), the number of requests per day (RPD), and the number of requests per minute (RPM). Unfortunately, it's not really possible to say how big a token is; a token could be a whole word or just a single character, depending on how frequently the model has seen that word. More common words are likely to be tokens in themselves, whereas less common words could be split up as individual tokens for each character. OpenAI does offer some general rule-of-thumb calculations to make a good estimate of how many tokens a block of text is likely to have; these can be found here. Below are OpenAI’s free limits, though these can be increased if you pay. So if your meeting notes are pretty long and you don't want the end of your notes to be cut off, you may need to pay for higher limits, or another option may be to chunk your data and have smaller embeddings.

One thing to be aware of is that a request is made up of tokens, and with the limits, the token is king. For a very extreme example, say you are using the gpt-4o model and you have a request that is 30,000 tokens. While you technically have 500 requests per minute, you have used up all your tokens for that minute in one go, so you now can't make any more requests. This is a very unlikely scenario, but definitely something to keep in mind.

Another consideration when selecting a model could be the size of your database. Different models will embed your data differently; some may create a vector of 500 dimensions, others could create a vector with 2000+ dimensions, and the more dimensions, the larger the size.

When embedding data, the number of dimensions is constant, regardless of the data you are embedding.

Single Word Input: "cat"

Vector Size: 1,536 dimensions (if the model's output is 1,536-dimensional)

Paragraph Input: "The cat sat on the mat."

Vector Size: 1,536 dimensions

Usually you will be embedding large blocks of text, so the size is likely to reduce, but if you are embedding small bits of data with a large model, you may actually create an embedding that is larger than the original data. In FileMaker, it is also important to embed your data into a container field to help reduce the size. You can embed directly into a text field, but in this case every character will be 2 bytes, and when one dimension is something like 0.003164375, that can add up to a lot of bytes (22 in this case, or 88 bits), whereas if you store the embedding in a container, this is saved as a binary number (0.0000000011001111011) and would take just 20 bits. Another good reason to embed into a container is that container fields can't be indexed, so if, for some reason, you do embed into a text field, you will need to make sure to turn off indexing for that field, or your file size could grow very quickly.

Open AI offers more generic models, but you will likely get better results by using a model trained on your data. For example, a generic model working with data about rocks is likely to group all the different rock types together because they are all just rocks. Whereas a model trained on data about rocks will do a far better job of distinguishing between different types of rocks. Think of it like asking your average Joe on the street about your data vs. asking a specialist in the field.

Embedding your data

Before we get onto embedding your data, there are a few key things to remember and consider. To do a semantic search, you will need to embed your question and then compare that embedding to your embedded data to find the closest match. The important thing to remember here is that your question will need to be embedded with the same model that your data was embedded with. If that doesn't make much sense, don't worry; this will be explained in more detail further on; you just need to remember to use the same model.

Once you have selected your model, you will need to embed your data. We recommend at least keeping your embedded data in a separate table and potentially even a separate file. This will allow you to easily store and manage different embeddings. (Yes, I know we said you should use the same model for everything, but when getting started, you may want to test different models and see which works best for you.)

Another size issue to consider is that, though FileMaker allows you to save your embedded data into a text field, the recommended method is to use a container field. The reason for this is that a container field will be smaller than using a text field, and FileMaker can search faster on the container.

The easiest way to embed your data is by using a found set, so first find your data. Once you have the data you want to embed, simply use the Insert Embedding in Found Set and select the field in your base table as the source and the container field in your embedded table as the target. This can be quite time-consuming, so it is probably best done server-side.

A Note on Embedding Your Data

As mentioned in the section on selecting your model, the number of dimensions remains constant, whether you embed a single word or an entire paragraph. This is an important consideration when embedding your data, as you may want to think about breaking down your data into smaller chunks before embedding. When performing a semantic search, the results reflect the context or meaning of the embedded content. For instance, if your meeting notes cover various topics across different paragraphs, embedding them as a whole might generalise the context of the entire meeting, leading to a loss of specific details. By chunking your data into smaller, more focused segments, you can preserve a clearer context for each part.

The need to chunk your data can also depend on the model you are using and the data you want to embed. A larger model with more dimensions is likely to capture and retain the context of a lengthy text block better than a smaller model, which might lose some nuances. Therefore, when using a smaller model, you might want to invest more time in carefully chunking your data before embedding. Unfortunately, there’s no one-size-fits-all approach here; it largely depends on the nature of your data, your budget, and the time you’re willing to spend on the process.

Adding a Semantic Search

The next step is to add a semantic search. To start with, we just added a text field for the search input. We then used the Perform Semantic Find script step to both embed the search entry and compare it to the embedded client notes. This script step also lets you choose how many results are returned, and the cosine similarity (a cosine similarity of 1) means identical data. (A cosine similarity of -1 means opposite data.)

This did produce reasonably good results, but due to how embedding data and using cosine similarity work, we found that slightly modifying the search input did help to improve the results. A semantic search is able to determine meaning and context, but to an extent, this is just how similar your search input is to the result without being an exact match. This means that if we can make our search look more like the embedded data, we will get better results.

The way we made the search entry more like the already embedded client notes was to add a pop-up entry for the client name and then convert the search input into a list before performing the semantic search. This should improve the semantic search as the cosine similarity for ClientName in the already embedded data and the SearchClientName should be 1.

A note on where to preform your searches

As we suggested, your data should be in a separate table or file, so when performing your search, you should go to the table the embedded data is in to perform the search rather than trying to search through a relationship. Better still would be to perform your search server side and then just return the relevant records. Otherwise, you are trying to search through all the embedded data locally, and those embeddings can be a lot of data to transfer to the client.

This is also an argument for trying to perform some standard FileMaker searches to reduce your found set before performing a semantic search. This will greatly increase the performance of the semantic search.

Sorting your results

A nice feature of the Perform Semantic Find script step is that it returns your results sorted by cosine similarity, which is great if your embeddings are in the same table as the unembedded data. However, we suggested keeping your embedded data in a separate table, which likely means you will be using a Go To Related Record script step to display the found records, and you will lose the sort order.

To get around this, we added an unstored calculation field on the Client Meeting Notes table, which is the cosine similarity. This also requires embedding your search input into a global variable before doing the semantic search.

CosineSimilarity Calculation Unstored, = CosineSimilarity($$EmbeddedSearchinput; ClientNotes_Embedded::ClientNotesEmbedded_Small)

Once the Go To Related Record script step is complete, you can sort by the cosine similarity field. At least working locally, the performance on this is pretty good, as you are likely only returning a small number of records. However, if your solution is not local or you are retuning lots or records, then you will likely see a hit to performance.

Improving your results

We found that the semantic search did a great job at finding relevant records but wondered if it could be improved. We sometimes found that the most relevant result for our search was not actually the most useful result. So one method to improve the search would be to make it a two-part search.

For example, you let the user do a semantic search with natural language and return the results for that. The user can select the result they think is best and use that result for another semantic search, this time using the embedded data for that record as the search input. The chances are this will contain a lot more information than the user's natural language search, so it may produce better results.

Another thing you may want to test is making that two-part search a behind-the-scenes search. So you take the top result from the natural language search, use that record for the second semantic search, and only present the results from the second search to the user. If you are doing this, then you want to be very sure the first result is a good result; otherwise, you might be searching for a bad result for similar bad results. One way to mitigate this would be that you only perform the second search on the record if the cosine similarity is greater than 0.8 (or whatever value you find works best for you).

Finally, you may want to do an initial standard FileMaker search to get a reduced found set, then perform your semantic search on that found set.

Conclusions

Semantic search tools can be really helpful and powerful tools, but only when the data suits that kind of search. So going forward with FileMaker solutions, you will want to be aware of what data might suit a semantic search and then make sure that data is in a good structure for a semantic search.

Ultimately, it's likely you will have to do quite a bit of testing around the semantic search to find the best option for your data. But once setup, you will have a very powerful search built into your solution.

Demo

Now wouldn't you like to see firsthand how different models and query formatting can affect your semantic search? Well, fear not, we have a demo file where you can have a play yourself, look under the hood and see the data structure, try and enter some really obscure prompts, and see if you can get a result you just wouldn't be able to with a standard FileMaker search. This demo file contains around 4000 book summary records with large and small embeddings for each book.

Some Interesting Stats About The Demo File

When it came to providing this demo we came up against a couple of hurdles with the size of the file, so we dug down into what exactly was causing this demo to be so much larger than our other demos — over 200 MB in fact:

For starters the demo admittedly has many more records than we normally include as we wanted to provide a good selection of sample data for you to play with.

But the raw data is not what is causing the size issue, in fact the raw book data, all the images and text in the demo file, scripts, etc came to just 38MB.

The bulk of the file size comes from the large embeddings at 100.6MB which is double the size of the small embeddings at 50.3MB.

Again this highlights the importance of testing and finding the best solution for you. If size is a consideration for you, then you may want to opt to use an embedding model with fewer dimensions.

An AI Overview

Tue, 30 Jul 2024 07:48:26 +1200

Before we launch into this...

Allow me to introduce Oscar Frith-Macdonald, one of our distinguished developers at DF. Oscar has studied the use of Machine Learning to facilitate image content searching for the UK National Archives. Who better to educate our team on the inner workings of artificial intelligence? His explanations are so excellent that we’ve invited him to write for the esteemed Weetbicks blog.

Take it away Oscar...

FileMaker — Now With AI!

For a while now, you have been able to access AI through the insert from URL script step and standard API calls (see Cath’s blog article). But FM 2024 is integrating a lot more of this directly into FileMaker, making it easier than ever to use AI in your solutions.

Now, there is a lot of great information on the cool things AI can do and also on the rather funny times it gets things wrong. However, we feel there is a lack of information on exactly what AI is. So this article is to help give you an understanding of how AI works, and this should help prevent you from falling into some of the pitfalls:

We will cover what AI is, some of the dangers of using AI, and how it can be useful. Hopefully, this will give you an idea of how best to use the new features safely.

So what is AI?

The best way to think of AI is as the outer shell of a Russian doll made up of deep learning (deep neural networks), artificial neural networks, and machine learning.

To break it down:

Machine learning (ML) is a subset of AI that involves training algorithms to learn from and make predictions based on data.
Artificial neural networks (ANN) are a subset of ML that mimic the human brain's interconnected neuronal structure to process information in layers.
Deep learning is a further specialisation within ANNs, utilising multiple layers (deep networks) to analyse complex patterns in large datasets.

In essence, each layer builds on the previous one, advancing the capabilities and complexity of AI.

Artificial Neural Networks

An artificial neural network (ANN) is an interconnected group of nodes, similar to the vast network of neurones in a brain.

Here, each circular node represents an artificial neurone, and an arrow represents a connection from the output of one artificial neurone to the input of another.

An ANN is composed of layers of interconnected nodes, or neurones.

These layers are typically organised as follows:

Input Layer: This layer receives the raw data. Each neurone in the input layer represents a feature or attribute of the data. For instance, in image recognition, each neurone might represent a pixel value.
Hidden Layers: These layers process the input data through a series of transformations. An ANN can have one or more hidden layers, where each layer consists of neurones that apply a mathematical function to the inputs and pass the results to the next layer. The term "hidden" refers to the fact that these layers do not directly interact with the external environment; they only communicate with other layers within the network.
Output Layer: This layer produces the final output of the network. The output can be a single value (e.g., a prediction or classification) or a set of values (e.g., probabilities for different classes).

Each connection between nodes has a “weight” to it, which is adjusted during the training process to minimise errors in the output. This process is similar to learning in biological brains, where synaptic strengths change to improve performance.

Deep Neural Networks

Deep Neural Networks (DNN) are a specific type of artificial neural network, with multiple layers in between the input and output layers.

A simple ANN may have just one hidden layer (shown in the diagram above), and a DNN adds many more of those hidden layers.

These additional layers enable DNNs to model intricate patterns and representations, making them highly effective for a wide range of tasks, particularly those involving large and complex datasets.

So what's happening in these hidden layers?

Each hidden layer transforms the input features into increasingly higher-level abstractions. Initially, the network might extract simple features (e.g., edges in an image). As the data passes through more layers, the network can recognise more complex patterns and structures (e.g., shapes and objects).

For instance, in image processing:

First Hidden Layer: Might detect edges and basic textures.
Intermediate Hidden Layers: Might detect patterns and shapes, such as corners or circles.
Deeper Hidden Layers: They might detect more complex structures, such as faces or objects.

Machine Learning

Machine learning (ML) focuses on developing algorithms that enable computers to learn from and make predictions or decisions based on data.

Unlike traditional programming, where explicit instructions are given to perform a task, machine learning allows systems to learn and improve from experience without being explicitly programmed.

Machine learning consists of three main points:

A Decision Process: Machine learning algorithms predict or classify based on input data, whether labelled or unlabelled, to identify patterns within the data.
An Error Function: This function assesses the model's predictions by comparing them to known examples, thereby determining the model's accuracy.
A Model Optimisation Process: To improve the model's fit to the training data, the algorithm adjusts weights to minimise the difference between actual examples and predictions. This iterative process of evaluation and optimisation continues until the desired accuracy is achieved.

Data Vectorisation

Data vectorisation is a key component of many AI models, though not all, which is why it wasn't included in the earlier Russian doll analogy.

Data vectorisation involves transforming raw data into a numerical format suitable for machine learning algorithms. Essentially, it converts data into numerical vectors, which are arrays of numerical values representing various features or attributes of the data. This numerical representation allows qualitative information, such as meaning to be quantified and compared to find similarities.

When data is vectorised, the numerical values generated are referred to as "dimensions." The more dimensions a vector has, the more accurately it can represent the data and facilitate comparisons.

Consider a simple example where the only two words in your vocabulary are "door" and "wall." In this case, the vectors might only have two dimensions:

"door" : [1, 0]
"wall" : [0, 1]

In other words, this limited vocabulary would be represented as [0, 0]. Comparing "door" and "wall," we see they are distinctly different in this simple two-dimensional space. If we introduce the word "window," its vector might look like this: "window": [0.6, 0]. Comparing "window" to "door" and "wall," we can see that "window" is more similar to "door" than "wall."

In reality, vectors typically have many dimensions, representing various attributes or features. These dimensions can be imagined in a virtual space, where the vector indicates a position within this space.

Cosine similarity is then used to determine how close two vectors are within this multi-dimensional space. By measuring the cosine of the angle between two vectors, we can quantify their similarity, ranging from -1 (completely opposite) to 1 (identical).

So, really, what is AI?

Now that you have an understanding of the different components that make up AI, let’s dive deeper into what AI truly is.

Knowing that a house is made of bricks and cement doesn't fully convey what a house is; it’s the same with AI.

When you hear the term ‘AI,’ you might think of iconic characters like HAL 9000 from 2001: A Space Odyssey or Data from Star Trek. These examples represent machines with the capacity for reason and autonomy, known as artificial general intelligence (AGI). However, this is not what most modern AI refers to. Today, when we talk about AI, we're actually discussing Narrow Artificial Intelligence (NAI).

Narrow Artificial Intelligence (NAI)

NAI is essentially an excellent piece of prediction software designed to perform specific tasks. Unlike AGI, which has the ability to understand, learn, and apply knowledge across a wide range of tasks at a human level, NAI is specialised. It's important to remember that it will only be an excellent piece of prediction software for the inputs it was trained for.

Here are some key points to understand NAI better:

Task-Specific: NAI is designed to perform a specific task or a set of closely related tasks. For instance, a language model like ChatGPT is trained to process and generate text but cannot create images.
Data-Driven: The effectiveness of NAI depends heavily on the quality and quantity of data it has been trained on. It makes predictions and decisions based on patterns found in this data.
Prediction-Oriented: At its core, NAI is about making accurate predictions. Whether it’s forecasting sales, recognising speech, or recommending products, NAI’s strength lies in its ability to predict outcomes based on input data.

The importance of training data

The performance of NAI systems is tightly linked to the data they are trained on:

Relevance: The training data must be relevant to the task. A language model trained on diverse and extensive text data will perform well in text-related tasks.
Volume: Larger datasets typically result in better performance, as they provide more examples for the model to learn from.
Quality: High-quality data, which is accurate and well-labelled, leads to better predictions.

There are three main forms of training, and all are used within the AI space.

1. Supervised Learning:

Supervised learning plays a significant role in training models like GPT. During the initial pre-training phase, the model learns from a large corpus of text data that includes pairs of input (e.g., text snippets) and output (e.g., the next word or sequence of words). This helps the model understand language patterns, grammar, and context. Key points include:

Pre-training Phase: The model is trained on vast amounts of text data from the internet in a supervised manner to predict the next word in a sentence.
Fine-tuning: After the initial pre-training, the model can be fine-tuned on specific datasets with labelled data for particular tasks, further enhancing its performance.

2. Unsupervised Learning:

While the initial phase of pre-training can be considered supervised learning due to the nature of the task (predicting the next word), it also has aspects of unsupervised learning:

Learning from Unlabelled Data: The massive text data used in pre-training is not explicitly labelled with specific tasks but consists of raw text. The model learns patterns, structures, and relationships in this data without specific labels guiding the learning process.

3. Reinforcement Learning:

Reinforcement learning has been notably applied in models like ChatGPT for specific aspects of training, such as fine-tuning the model's responses to be more aligned with human preferences.

Reinforcement Learning from Human Feedback (RLHF): In the case of ChatGPT, after the initial supervised learning phase, the model undergoes reinforcement learning, where human feedback is used to reward desirable responses and penalise undesirable ones. This process involves:
Human Labellers: Provide feedback on model outputs, ranking them based on quality, which is then used to further fine-tune the model.
Policy Optimisation: Adjusting the model's parameters to maximise the reward signals obtained from human feedback.

While NAI is powerful, it comes with limitations:

Lack of Generalisation: NAI cannot generalise knowledge beyond its training. A language model won't understand visual data unless it has been specifically trained to do so.
Dependence on Data: NAI’s accuracy is limited by the data it was trained on. If the data is biassed or incomplete, the AI’s predictions will reflect these issues.
Absence of Understanding: NAI does not possess true understanding or consciousness. It operates purely based on learned patterns, without any comprehension of the content.

NAI and GPT

It's pretty difficult to talk about AI and not mention OpenAI and GPT at all, so how does GPT fit into the world of NAI? Let's start with what GPT stands for:

Generative Pre-trained Transformer

Generative: This refers to the model's ability to generate text or other forms of output.
Pre-trained: Before fine-tuning for specific tasks, the model undergoes extensive training on a diverse dataset to learn language patterns, grammar, and general knowledge. This pre-training allows the model to perform well on various tasks with minimal additional training.
Transformer: This is the underlying architecture of the model. Transformers are a type of neural network designed to handle sequential data and have become the standard for natural language processing tasks due to their efficiency and effectiveness in understanding context and relationships within the data.

GPT is actually an excellent example of NAI, as it's very obvious that none of the GPT models can do everything. They have had to be narrowed down to specific tasks such as ChatGPT, ImageGPT, etc. As their names suggest, they have similar base GPT models but have then been trained for specific tasks.

These different models can work in conjunction with each other to provide a “wider” AI experience. This is why ImageGPT can generate an image from a text input.

Example Workflow

1. User Input: The user provides a text prompt, e.g., "a two-story pink house shaped like a shoe with a small garden in front."

2. Text Processing: A language model (like ChatGPT) processes the text to ensure it is clear and extract essential elements, e.g., "two-story pink house," "shoe shape," "small garden in front."

3. Image Generation: The processed text is fed into a text-to-image model (like ImageGPT), which then generates an image based on the description.

AI Considerations and Mitigations

While AI is a powerful tool, there are important considerations and potential pitfalls to be aware of. Understanding these can help you better navigate the challenges and maximise the benefits of AI.

Pitfalls and Issues:

Bias in AI: AI systems learn from the data they are trained on. If this data contains biases, the AI will likely reproduce and even amplify these biases. For instance, an AI trained on biased hiring data might favour certain demographics over others. It's crucial to ensure that training data is as unbiased and representative as possible. One of Google's issues with the AI summary was pulling information from places like Reddit and presenting it as fact.
AI Hallucinations: AI models, especially those dealing with language, can sometimes generate outputs that seem plausible but are completely incorrect or fabricated. This is known as AI hallucinations and occurs because the AI predicts text based on patterns it has seen, even if those patterns lead to false information.
Overfitting: An AI model might perform exceptionally well on training data but fail to generalise to new, unseen data. This issue, known as overfitting, can lead to poor performance in real-world applications.
Data Privacy: AI systems often require large amounts of data, which can raise concerns about data privacy and security. It's important to handle personal and sensitive information responsibly, ensuring compliance with data protection regulations.
Complexity and visibility: Many AI models, particularly deep learning models, are complex and operate as "black boxes," making it difficult to understand how they arrive at specific decisions. This lack of transparency can be problematic, especially in critical applications like healthcare or finance.

AI Hallucinations and Incorrect Results

Hallucinations are probably one of the biggest issues with AI, especially when the AI will provide an answer that seems plausible and will also present it as fact.

Hallucinations can happen for several reasons:

Incomplete Data: The AI might fill in gaps with fabricated information if the training data is incomplete or lacks context.
Pattern Recognition: The AI tries to predict the next piece of information based on patterns, which might lead to incorrect associations and results.
Ambiguous Queries: Vague or poorly defined inputs can cause the AI to generate misleading or incorrect outputs.

To mitigate these issues, it’s important to:

Validate Outputs: Always cross-check the AI’s outputs with reliable sources or experts in the field. N.B. As it is a well-known issue that these generative models can generate false information, many AI models have now been designed to return links to their source so that it is easier for a user to verify the information the model has returned.
Provide Clear Context: Ensure that queries are specific and provide enough context for the AI to generate accurate responses.

Improving AI responses and ensuring correct information

To enhance the reliability and accuracy of AI responses, consider the following strategies:

1. Use High-Quality Data: Ensure the training data is high-quality, representative, and as free from biases as possible. Regularly update the data to keep the AI model current. Use your own existing data and examples when asking a question about AI; this will help to ensure it's only using information you consider to be true.

2. Implement Human Oversight: Use AI as a tool to speed up human decision-making rather than replacing it entirely. Always have a human look over the result to ensure it is correct.

3. Clarify Queries: When interacting with AI, especially language models, frame your queries clearly and precisely. The more specific the input, the more accurate the output is likely to be. Don't be afraid to send pages of information in your prompt to the AI, but be aware there is usually a cost for this.

4. Employ Ensemble Methods: Combine multiple models or methods to cross-verify results. Ensemble techniques can help improve accuracy and reduce the likelihood of errors. It's also important to use the correct model for your task.

5. Educate Users: Ensure that users understand the capabilities and limitations of AI. Providing training on how to interact with AI systems and interpret their outputs can significantly improve outcomes. One of the most important points is to ensure your users are aware that the AI could be wrong.

Welcome Karesha

Mon, 29 Apr 2024 13:52:00 +1200

We are a bit late to the party with this post, but as they say, better late than never.

We would like to welcome Karesha Walker to the team as our ‘new’ Office Administrator. She’s been with us nearly six months to date, and has made a massive impact on the business, notably her love of pot plants has infected the DF office in Christchurch.

Digital Fusion were very lucky to nab Karesha, her previous job was CEO of her household, having raised two young boys and two Chihuahuas over the last five years. After escaping that job it should be a cinch to help manage 16 developers and a few account managers (plus all those pot plants). It could be a few years before she whips the CEO into shape, but the money is on this happening.

We asked Karesha to give us a few interesting facts about herself, and she turned up the following…

Her favourite animal is a bison
When she was a child she was a severe sleep walker and would do weird and wonderful things like bathing her dolls and making food
In her earlier years she attained a Teaching Degree
She's had the same friends since primary school
She project managed the build and did the interior design of her new home after living in a 30 square foot tiny home for 2 years…

That certainly turned up a few things we didn’t know.

Welcome Karesha to the team, if the first six months are anything to go by, you will have us all in tip top shape (and working in a jungle) in no time.

Reconnect Experience

Mon, 22 Apr 2024 08:52:00 +1200

Having attended only one other FileMaker Conference, (An in-house event just three weeks after joining Digital Fusion), I was excited at the opportunity to meet the broader FileMaker community in Sydney at the Reconnect Conference.

Despite my excitement, there was an underlying nervousness about what to expect from the sessions. Would they delve into highly technical topics beyond my understanding? Could I follow sessions led by developers using different data structures? And, would the warmth and support I experience at Digital Fusion extend to the wider FileMaker developer community?

I must admit, as a newcomer to development, I thoroughly enjoyed every aspect of Reconnect.

The conference struck a perfect balance between social interactions and informative sessions. The evening before the conference kicked off, we visited the Apple offices for a Q&A session with the Claris team. This provided insights into the relationships between Claris and other FileMaker developers.

The social aspect of the conference was an eye-opener for me. The first night was nothing short of fantastic! After a few drinks at a stunning rooftop bar, I summoned the courage to mingle with the FileMaker community, and what a community it is! Everyone was incredibly friendly and genuinely interested in each other's backgrounds. The atmosphere was electric, with attendees eager to reconnect and engage in meaningful conversations.

I found the topics covered a wide spectrum, and even the technical sessions were accessible, thanks to well-demonstrated workflows, such as Andrew McCallum's transactions presentation.

Charmaine and Salvatore's discussion on Business Analysis was particularly enlightening. Having just completed my first System Design, I found their insights invaluable, especially regarding identifying business needs and engaging with the right Stakeholders to gather project requirements effectively. Their modular approach provided a structured framework that I can apply to future analysis and design phases.

Of course I cannot overlook Cath and Jamie's sessions (not that I'm biased) on the development of “MTS Connect” for the Mobile Tyre Shop.

As a Developer, hearing a Client perspective on how FileMaker transformed their business by streamlining processes was incredibly inspiring. Seeing how the MTS solution was developed and used has highlighted the effectiveness of Cath's modular approach in building the MTS solution. Their collaborative relationship serves as a testament to Cath's exceptional skills and dedication to pushing boundaries to achieve remarkable results with the MTS solution.

I could not have wished for a better experience at Reconnect, and can’t wait to go along to another…

PS: We figured Maddy enjoyed the experience so much she might like to talk some more about it…

FileMaker ChatGPT Integration

Tue, 19 Mar 2024 12:12:00 +1300

Simple integration using ChatGPT and FileMaker Pro solving two business problems.

Introduction

By now, almost everyone has heard of ChatGPT, marvelling at its ability to write poetry, tell jokes, and entertain. But what about its practical applications in business?

Are there any? We think so, and have started to solve some real world problems with the technology. These simple use cases will focus on how to use ChatGPT to improve or provide substitutes for the text we give it.

TLTR?

We explored three methods for generating text, experimenting with different prompts and requests. We landed on the last method as the most feasible option for our purposes. This method involves using functions included in the request to return predicable JSON formatted results.

Download the Example file here

Problem 1: Unprofessional Texts (SMS)

Have you ever received an unprofessional text from a business? Maintaining a consistent company style in custom messages can be challenging. ChatGPT can take the original message and provide alternative options in the writing styles of your choice.

By using a variety of writing style (tones), we can craft appropriate responses to align with the impression the business wants to give.

Here are some common styles or tones you could use to covert the original message. The prompt might include key words like; formal, casual, serious, friendly, optimistic, pessimistic, scientific, concise, descriptive, persuasive, professional, trustworthy or informative. Combinations of them work well too for example:

Friendly and professional
Authoritative and informative
Urgent and persuasive
Casual and conversational
Professional and trustworthy

Problem 2: Poor SEO

When generating website content it can be common to use a FileMaker database to generate content. In this case we want to create a description for multiple suppliers. We will customise each entry by incorporation details such as their establishment date, the brands they represent and their location. Using these variables we can create a block of text which nicely summarises a unique description for each supplier

However, an issue arises when the content, while unique, follows a repetitive structure, potentially harming SEO performance. It would be better to have the ability to quickly generate high-quality content without having to spend hours brainstorming or writing drafts.

In this case we can use our FileMaker description as the input and generate multiple options in the tones of our choice. Each of which will have unique content and now unique structure too.

How Much Will It Cost?

Charging is approximately 0.03 cent per request (for around 750 words or 1K of data). The pricing model is complex, depending on the number of tokens exchanged and the request processing time.

The model you use also has different pricing structures. Using GPT-3.5 Turbo models are far more cost-effective than GPT-4. The same request as above using GPT-4 would cost 9 cents per request.

One thing we know about AI is that this is a very dynamic landscape. This article was written in March 2024, but to view the most current pricing, please refer to Open AI’s pricing page for further information.

What Is A Token?

Language models perceive text as a series of numbers, known as tokens, rather than in the same way that humans do. There are many advantages to Tokenising the data including reduced request transfer size and search ability. It does make it more difficult to know exactly how big your request is and therefore how much it is going to cost but there are tools for measuring request size in tokens.

To find out more about what a token consist of refer to the help document on Managing tokens

Privacy And Security

OpenAI will store your data for 30 days. Do not send any information you do not want to share. In our cases there is no private information contained in the posts, but we will look at how to use local Large Language Models to reduce privacy concerns in the future.

Creating The Right Prompt.

This is the number one tool for managing your response. In the demo file you will see that by changing the language code in the prompt (one word) we will receive an entirely different message. These models can’t read your mind. If outputs are too long, ask for brief replies.
Set the right tone by suggesting how you want the response to be returned for example, casual but informative. State the audience and the goal and any know constrains.

Models are known to return wild responses so much so that the term Model hallucinations is used. You can reduce this by improving your prompt or by adding a mock conversation sequence to your request. The model will look at the mock conversation as a prototype on how to respond more appropriately

Prompt engineering is bound to become a specific skill. One which is certain to have an impact on the usefulness of the responses you receive. To learn more, read the Open AI guide on prompt engineering.

Which Model To Choose?

Change is happening fast. On the 4th January 2024 GPT3 and GPT 3.5 were depreciated. This article was written in March 2024 so currently we recommend that you use either GPT-4 Turbo Preview or GPT-3.5 Turbo.

GPT-4 Turbo Preview

has improved language understanding and generation capabilities compared to GPT-3.5 Turbo.
offer better accuracy in generating text and evaluation
has a larger context window with a maximum size of 128,000 tokens compared to 4,096 tokens for GPT-3.5 Turbo.

GPT-3.5 Turbo

is generally faster than GPT-4 Turbo Preview
costs much less per token

You can use both, as you reference the Model as part of your cURL request. For our purposes we chose GPT-3.5 Turbo generally because the queries are simple and non computational and would be more cost effective using the cheaper model.

As announced in March 2023, OpenAI regularly release new versions of `gpt-4` and `gpt-3.5-turbo`.

Each model version is dated with a month and date suffix; e.g., `gpt-4-0613`. The undated model name, e.g., `gpt-4`, will typically point to the latest version (e.g. `gpt-4` points to `

After a new version is launched, older versions will typically be deprecated 3 months later.

If you want to use a specific model you would reference it as ["model": "gpt-3.5-turbo-1106"], for our purposes we used the undated model which is simply referred to as ["model": "gpt-3.5-turbo"]

Recent enhancements to models include: improved accuracy, improved function calling support, understanding images, reduce cases of “laziness” where the model doesn’t complete a task.

Setting The Temperature Parameter

Lower values for temperature result in more consistent outputs (e.g. 0.2), while higher values generate more diverse and creative results (e.g. 1.0). Select a temperature value based on the desired trade-off between coherence and creativity for your specific application. The temperature can range is from 0 to 2.

We didn’t use temperature in this example but it is another useful tool in shaping the model responses.

Getting Started

In the demo file we will query the API to receive 3 variations of the input text, giving each of them a slightly different tone. We will look at 3 ways you can change the response received by those queries and which method is the most reliable.

Download the Example file here

Setting Up An OpenAI API Key

If you already have one of these, then you can skip this whole section! If not then read on…

First, create an OpenAI account by signing up at https://openai.com/

Choose the API platform. Click on the API Key link. Accounts need to be verified with a mobile phone number before you can add a new API key.

The introductory offer gives your account $18 free credit and this can be used against any API key you generate. We were allocated $5 credit when setting up a second account which shared the supplied phone number with a previous account. The tip here is that you do get a small amount of credit to get started, and a little goes a long way.

Connecting To The API

Use the following URL:

Endpoint: https://api.openai.com/v1/chat/completions

Below lists the main elements of the cURL request:

-X POST
-H "Content-Type: application/json"
-H "Authorization: Bearer XX-KXXXXXXXXXXX" (where XX-KXXXXXXXXXXX is your API key)

The data portion of the post will specify:

The Language model you want to use
The Prompt and any input text
[Optional] Mock conversations used to pre prime the language model into sculpting your response
[Optional] Temperature

For example:

Option 1: Basic

For this example we used the following prompt:

“Provide three variations for this message using en_GB language. option1 Friendly and professional. option2 Authoritative and informative. option3 Casual and conversational. where the message is: Hi Cath your order has arrive. book in a fitting time which suit on 1800 0222 233 or visting www.teamdf.com”

The incorrect spelling and bad grammar is deliberate as we want the API to improve on our submissions :)

The response is returned as JSON (always) but will typically be dumped into one element
choices[0].message.content

The variations are separated by a double line break.

Problems With This?

The API will return inconsistent results, which makes parsing the result difficult. For example the way the variations were presented inside the content could change from call to call.

The following had been observed…

Option 1:\nHi Cath, your
Option 1:Hi Cath, your
Option1:Hi Cath, your
Option1: (Friendly and professional)Hi Cath, your
Variation 1:Hi Cath, your

This could likely be improved with a more detailed prompt but its still not reliable to parse, which makes this method a bit too basic for practical use. However this would be more practical if you are asking for one answer at a time rather than 3 like this example.

Options 2: JSON

You can specify to have a JSON object returned. This showed more promise.

For this example we used the following prompt:

“Provide json three variations for this message using en_GB language. option1 Friendly and professional. option2 Authoritative and informative. option3 Casual and conversational. where the message is: Hi Cath your stuff has arrive. book in a fitting time which suit on 1800 0222 233 or visting www.teamdf.com”

It was important to including the word JSON at the start of our prompt and to add response_format:{ "type" :"json_object"}, to the data portion of the post.

This worked better. By returning the result as JSON elements, removed the issue of manually parsing the result of the first method.

However, the elements returned were not 100% reliable either. With this method you will always receive valid json however the number of elements and naming convention is not guaranteed. We noticed that if the input text was crafted more like an email, elements such at Attention, Action and Signature may be returned as would Tone on occasion.

An improvement on the Basic technique but still too unreliable to work with. No doubt this could also be improved by a more specific prompt.

Options 3 Standardised JSON

The last method we settled on was to use a function in our request to specify the JSON we wanted returned.

Functions are a way to force the model to return the response in a standardised format.
They are named and declared as part of your call. Meaning you now have control over the format of the response. You can also set data rules on the elements including length and the accepted values.

cURL request including the function

Response:
Instead of the response returned in the location choices[0].message.content it will now be returned referencing the function like so: choices[0].message.function_call.arguments

Lessons Learnt

Along with the variation in responses, there were other issues we overcame on our journey.

Language Variations

The responses received were in American english. This wasn’t ideal for our audience and the answer was to be more specific in our prompt. Adding the term en-GB to our prompt translated the response.

When specifying the prompt using ISO 639-1 language code is best That’s en-GB for British (not en-UK), and en-AU, en-NZ, en-CA, en-IE etc.

Using en-GB spelling is generally a safe bet for all non-US countries unless you are very particularly about some of the language differences. If you use Australian English, it starts to overdo it, saying things like “G’day mate!” Unless of course, that’s what you want…

Saying The Right Thing

We had to tweak our prompt a fair bit. It seems like this is really important and there will be a lot of information around tips for crafting the perfect prompts.

Despite carefully crafting our prompts, the language model occasionally overlooked parts of our requests. For example, most of the time our responses were in en-GB, but not every time! Occasionally they would be returned using American spelling. These are the kind of improvements we can expect to see as the Language Models mature and the reason why eye - balling the responses is so important.

Stripping Links

In some cases we wanted to include a specific URL. No matter how we changed the prompt we could not guarantee that the URL would be included in the variations. There is bound to be a way to enforce this but we changed our workflow to not need that and stopped looking to solve this problem. If you know a way then please leave a comment, we would be interested to learn.

Exceeding Rate Limit:

We hit rate limits while using an OpenAI account without a credit card.
"message": "Rate limit reached for gpt-3.5-turbo-0613 in organization org-XXXXXXXXXXX on requests per min (RPM): Limit 3, Used 3, Requested 1. Please try again in 20s. Visit https://platform.openai.com/account/rate-limits to learn more. You can increase your rate limit by adding a payment method to your account at https://platform.openai.com/account/billing.",

Final Comments

This is a simple integration but was very useful from a business standpoint. We would love to know what business problems you are solving with AI.

Hope you found this interesting. Download our file and have a play.

Development Excellence!

Fri, 01 Mar 2024 10:19:00 +1300

We won! And of course we absolutely deserved to win — the solution built by Cath Kirkland for our client Mobile Tyre Shop, is a tour de force of what can be accomplished with FileMaker, a top notch development team, and a client on a mission…

The Client

Mobile Tyre Shop (MTS) is a unique and extraordinarily innovative business, disrupting the tyre industry in Australia with the “tyre shop that comes to you.”

Tailor Made

After trying a standard ERP software product, MTS recognised they needed a bespoke approach to their business systems:

To meet their needs a whole new “operating system” was needed that would integrate a myriad of different services, from tyre suppliers, to car registration details, to phone systems and of course their website.

To do that, in fact to build any bespoke software project, you need to align some major elements:

A committed Product Owner who knows what’s needed
The right Platform with flexibility and rapid development
Developers with the skills, experience and knowhow to deliver

And perhaps the single most important and overarching characteristic:

An exceptional collaboration between the Product Owner and the development team.

Much of the success here can be attributed to Cath, who spearheaded the development efforts, along with Jamie Cartwright, the Chief Operating Officer at MTS, for his vision and determination.

Together they formed a dynamic duo and carved their way through challenges and complexities to deliver an extensive software solution with quantifiable benefits to the business such as —

40% reduction in sales staff
70% reduction in the number of staff now needed to do scheduling
Fleet customers are managed by a single person

…and the company is now positioned to double the number of jobs per day, without needing more administrative staff.

Customer Service

It’s also about improving customer service: there’s a raft of client interactions facilitated by the software — for example, when a tyre is scanned into the warehouse, the system automatically messages the client telling them their tyres have arrived, and provides a link to schedule the fitting at their convenience.

MTS have also levelled the playing field in their industry by integrating with all the major brands, and many not so major brands, plus Amazon and eBay. By bringing all this data together in one place they’ve made the market more accessible and transparent so that the customer gets the best deal and chooses the right tyre for their needs.

As a testament to how successful this approach is, MTS are now seeking a smaller office space with a bigger warehouse — that’s a wonderful outcome because it means they're doing more of what they actually do, with less administration and management, and in the process providing better customer service for the win!

There’s a lot more we could say about the system — it’s an exciting project and we continue to build upon it even though it’s well and truly earning it’s keep already. We’ll do more in depth looks at the system itself in the future. For now though we’re celebrating…

Congratulations To Our Team

To Cath for the incredible commitment and hard work it’s taken, for the relationship and collaboration you foster so very well with your clients.

To our entire team of 16 developers, because we all benefit from the support, knowledge and combined expertise of the entire team.

And two particular giants at DF: Steve and Daniel.

To you all — Well Done!

And A Huge Thanks to MTS!

Travis Osborne, founder and CEO, for the vision to bring the business to life, for selling the dream and for empowering his team, particularly Jamie, to find the best solutions…

Jamie, for being an incredible product owner and evangelist, and for being articulate and forthright enough to shout about it from the rooftops!

Thank You All!

Welcome Oscar

Tue, 24 Oct 2023 18:24:00 +1300

We would like to welcome a new member to the DF team, Oscar Frith-Macdonald.

Oscar’s got a unique background, plus a unique dress sense, by the looks of the following photo. He likes a bit of unicycling, juggling, and stilt walking, and actually did a 240km charity cycle on a unicycle…

These highjinks aren’t entirely unique at Digital Fusion — we have one other developer that has a background with the circus (it must be a FileMaker thing)! …so if AI ever takes over our jobs we have a plan B.

Oscar comes to us all the way from the UK, where he was born in London but moved to Cornwall when he was young. His connection to New Zealand started with that move to Cornwall when his parents almost decided on NZ instead, so when he got the chance to study abroad for a year he jumped at the chance to see us down here — well, Wellington specifically.

The draw of NZ was too much and he returned last year, picking Christchurch as his new home this time round.

Oscar has a Bachelor of Engineering in Electrical and Electronic Engineering. Those skills landed him with a very interesting first job in the UK, developing software for the conversion of old luxury cars to electric power at Lunaz Design.

Outside Work

Outside of work, Oscar and his partner are adventure nuts, which is possibly why they picked Christchurch which is on the doorstep to all sorts of outdoor activities — they’re into hiking, rock climbing, and getting out amongst the best NZ has to offer.

We welcome Oscar to the team, and look forward to plenty of banter when NZ and Australia take on the English in cricket or rugby.

As You Were

Wed, 20 Sep 2023 15:33:00 +1200

Over the last few years, Claris have been making changes across their platforms including introducing some new products. We've been slow in how much we communicated about this because on the whole the changes were not going to have a huge impact, or at least not in the short term, and we've been uncertain on how it would all work exactly…

Without going into great detail, Claris intended to have two platforms, the original FileMaker Platform that we all know and love, and a new one called the "Claris Platform" that would encompass the new products as well as a new version of FileMaker itself under a new name.

Claris Studio

As part of this, they released a new product, Claris Studio, which is essentially an easy-to-use, purely web-based, database and form builder. This would allow users to spin up a web form for things like conference registrations, internal forms etc etc. The data captured in these forms would then flow through into Claris Pro, the FileMaker Pro type app on the Claris Platform side the equation.

Studio has the makings to be a great addition to the product range from Claris and a very useful compliment to FileMaker. As a product it’s still in its infancy, and Claris are making changes to it on a very regular basis. I think that in another six to twelve months we'll start seeing all sorts of use cases and ways that it can help expand on the capabilities of FileMaker.

We recently used Studio in the organisation of the Reconnect.Sydney conference, the local APAC for FileMaker developers. It helped us build forms for speaker registrations, filter the speakers we wanted, collect their bio’s, photos etc. All this was spun up without any coding required, no need to set up a server, and zero deployment effort.

Simplification

Before we go too deep into all of this, things have changed, and we believe for the better and simpler: Claris announced last month that they are going to go with just the single platform moving forward, that being the "Claris platform", comprising of:

In short, they are consolidating the new products with the tried and true FileMaker line, and calling it the "Claris platform", but keeping the FileMaker name and product as it is (confused yet?!)

The big win for you if you have FileMaker already is that Claris Studio which was limited to the new Claris Platform, will now work with the current FileMaker product line.

All up we think this is a great move by Claris, they listened to feedback about the two platforms, and have made the right decision. What it has shown to us is that Claris are continuing to try things, sometimes they don’t get it right, but they are trying, and we think thats great.

If you'd like to know more, here's Claris' own recent presention on their platforms:

Claris Product Strategy Update 2023

FileMaker OCR Integration with Veryfi

Tue, 18 Jul 2023 23:08:00 +1200

Introduction

Hey there!

Are you tired of spending countless hours manually entering data from documents?

Check out OCR for a little slice of magic! OCR (Optical Character Recognition) is a fantastic technology that can transform printed or hand-written text into JSON format that can then be easily used to populate FileMaker records.

In this example we will use the paid web service by Veryfi to read invoice documents but there are many other OCR services available. Our choice to use Veryfi was mostly based on the standard JSON reponse they return.

Are you ready to get started? Let's dive in! Download the example file below:

Download the example file

What You Will Need

First, you will need to create an account with Veryfi.

https://app.veryfi.com/signup

You have 14 days to use this account for free with limitations. After this point you will need to create a paid account, or add billing details to your own.

Next, go to the Settings → Keys page and create a new API key

https://app.veryfi.com/api/settings/keys

The information you will need to record from this page includes the following:

Client ID
Client Secret
Username
API Key
and the URL https://api.veryfi.com/api/v7/partner/documents/

Now you have all the tools you need, create a layout and add a container field for receiving the document you want to read.

The file contents will need to be Base64 encoded to include into the cURL which we will build up and send to Veryfi.

Now we have the contents of the file all nicely packaged up into a variable. Veryfi requires two pieces of information to be sent. The file name and the encoded file. Build up your data string like so escaping the quotes as needed.

JSONFormatElements (

\"file_name\": \"" & GetContainerAttribute ( HOME::fileadd_dragdrop ; "filename" )& "\"" &

", \"file_data\": \"application/pdf;base64, " & $file & "\"" &

"}"

)

End result required:

Veryfi supports the following file types .pdf, .htm, .jpeg, .avif, .heic, .gif, .webp, .txt, .html, .heif, .ofd, .png, .jpg, .zip with a maximum file size of 20mb.

Sending the Request

Next we want to build up the CURL request. In this case we are using a POST and sending the authorization details of our API key and account set up earlier.

"-X POST" & ¶ &"-H \"Accept: application/json\"" & ¶ &

"-H \"Content-Type: application/json\"" & ¶ &

"-H \"CLIENT-ID: " & $clientid & "\"" & ¶ &

"-H \"AUTHORIZATION: apikey " & $account & ":" & $apikey & "\"" & ¶ &

"--dump-header $responsestatus " & ¶ & //gets us a response code

"-d @$Data" & ¶ &

"--trace $$trace “ [Optional; used for troubleshooting]

Now use Insert from URL to send the request

In this case we are setting the response into the $Response variable so you can check this for a valid response of 201.

The document will be returned as JSON listing out elements such as but not limited to:

Want To Know More?

Check out Veryfi's documentation for further information on the JSON response or other details.

https://app.veryfi.com/api/docs/

Example File

As mentioned, 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.

Click here to download the example file

Google Maps in FileMaker

Tue, 18 Jul 2023 16:29:00 +1200

Introduction

Wow, there are endless possibilities with Google Maps! But where do we even begin? In this demo, we'll show you just how effortless it is to find and display the travel time between any two locations using Google Maps.

Imagine this: you're using FileMaker Go, and in just a few clicks, you can instantly know your exact location and estimate the travel time to your next destination or important meeting.

Now, here's the slightly tricky part - getting your hands on a Google API key. If you don't have one don't worry we will take you through the steps of getting one. Let's get started and discover the benefits of this integration…

Example File

Are you ready to get started? Let's dive in!

Download the Example File

Setting-up A Google API Key

If you already have one of these, then you can skip this whole section! If not then read on…

You will need to set up a Google API key. This involves creating a cloud.googe.com account and using a credit card.

In most cases usage rates fall in the free zone, mostly because Google currently gives you a $200 recurring monthly credit. Some of their rates are here:

https://developers.google.com/maps/documentation/directions/usage-and-billing

Finding the right place to set up a Google API key can be a pain and you have to enable the services you want to use. But don’t worry once you have the API key it's smooth sailing from there!

1. Go to the Google Cloud Console https://console.cloud.google.com/projectselector2

2. Select a project, or create a new one.

3. Go to the APIs & Services > Credentials page.

4. Create Credential, select API key and choose the following options:

Choose Application Restriction if any.
Click Restrict key.
From the Selected APIs dropdown. Enable the following:

Directions API, Geocoding API, Geolocation API, Maps JavaScript API, Places API (you wont be able to select some of these until there is billing information added.

To finalise your changes, click Save.

The Google APIs

When you set up your Google API key you do get the option to enable the services you want to use. If you are going to be using Google Maps integration for a multiple integrations in your FileMaker database we suggest setting up multiple keys. In the event that you do start to get charged you then have a little more visibility as to where those charges are driven from as the charges get linked to the API key. We didn't do this here but you know… you live and learn!

For more information on the services we use look here:

Directions API

Get directions between locations, for driving, cycling, transit, and walking:

https://developers.google.com/maps/documentation/directions

Geocoding API

Convert addresses or Place IDs to latitude/longitude coordinates and vice-versa:

https://developers.google.com/maps/documentation/geocoding

Geolocation API

Uses cell phone towers to establish a gps location:

https://developers.google.com/maps/documentation/geolocation/overview

Maps JavaScript API

Build dynamic, interactive, deeply customized maps, location, and geospatial experiences for your web app:

https://developers.google.com/maps/documentation/javascript

Places API

Get location data for over 200 million places, and add place details, search, and autocomplete to your apps:

https://developers.google.com/maps/documentation/places/web-service

Getting Started

Download the demo file and enter your own API key.

The main block of code contains a couple of substitutes. We have inserted tags into the code to make it simple to substitute with your own data. The minimum data you will need is the

Start coordinates (longitude + latitude)
Destination coordinates.
API key
Mode is optional and will default to driving if not specified

Returning The Travel Time

The code also contains the name of a script which will get called when the map loads in a webviewer. The time is passed as a script parameter in seconds.

The script name in the example file is called:

[MAP: SetTravelTime]

You can customise this to call your script by changing the name directly in the map code.

For Example...

In our example we demonstrate the travel time in New York City across central park. Changing the mode of transport re-calculates the optimal route and estimated travel time for the 4 modes Google allows you to select.

Note: For each mode to work there does have to be sufficient google data to revaluate the route. For instance biking mode does not work in Christchurch, NZ due to a lack of google data.

40 minutes to walk from The Metropolitan Museum of Art to Times Square.

29 minutes by public transport

13 mins to drive

But the winner was 12 minutes to bike between the two points.

Compare some other locations in our demo file or add your own.

What's Your Current Location?

Using FileMaker Go this is simple to work out as we can use the FileMaker Function

LocationValues(200;10)

Where 200 represents the accepted accuracy in meters and 10 represents the maximum acceptable time in seconds since the location was last looked up. This function returns a delimited list of location information where:

1st value = latitude

2nd value = longitude

On non-iOS devices you could use Geolocation API which uses cell phone towers to establish a gps location.

How To GPS Your Addresses

In reality to use this integration your contact addresses have to be GPS’ed. There are two main ways to do this.

At the point of data entry
Retrospectively.

That choice will be up to you. There is code in the example file which will retrospectively loop through a bunch of addresses and use the Google Places API to code them.

Alternatively you can use a widget like Google address validator in a web viewer to enter and code addresses as you go.

Hope you found this interesting. Download our file and have a play.

Example File

As mentioned, 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.

Click here to download the example file

Server Compatible Dynamic Portal Sorting

Tue, 02 May 2023 09:17:00 +1200

Introduction

In this article we're going to show an approach to dynamically sort a portal. By dynamically we mean allowing the end user control over which field a portal is sorted by.

Traditionally this has always been difficult in FileMaker because portals are sorted using the standard sort dialog, which only allows you to hard-code one or more predetermined fields as the sort order - there simply is no ability to programatically change the field defined.

There have been a number of approaches to this issue over the years and all are certainly usable and do the job. They do however suffer from a few drawbacks which we'll also discuss.

Cut to the chase, what is your solution?

We're going to do things a little different in this article. Usually we go through a detailed explanation of a technique before getting to the final implementation. We're going to flip this on it's head and instead tell you what the approach is up-front.

The remainder of the article will then go into all that nitty gritty which we really think you will find interesting and informative. It helps to understand why this particular approach has been taken so you can get an appreciation for the challenges involved in portal sorting.

So here is our approach

Firstly, we're going to sort a portal by each records internal ID. This can be obtained using the Get ( recordID ) function. We then set into a calculation field which we'll call rowid.

When we specify the sort field used, we're going to use the additional option to use a Custom order based on a Value list.

This value list lies at the core of our ability to sort dynamically. It will be a value list of rowid values for the records in the portal but the value list will present them in an order which matches the desired sort order we want.

If the value list is in the desired sort order and we're sorting the portal based on rowids being in this order, then our records will then also be sorted in this dynamic order.

SO, that's the theory anyway. Now lies all the tricky business of implementation. Time to come with us on a journey of learning!

Example File

Now is a great time to download the example file. We have invested a lot of time again in providing an informative and easy to follow example file that not only explains the technique but lets you explore it for yourself.

Please download the example file here.

And now for the nitty gritty and interesting stuff…

In a nutshell this approach seems simple but it relies on quite a few interesting techniques to get it to work. it also draws upon historical techniques which we have had to refine for this process. We're going to go through all of these in some detail.

First, some history on Portal sorting

In order for a portal to be dynamically sorted, it has to allow each individual user control over how they choose to sort it. Simply sorting a portal by a predefined stored field will not allow this, because the stored value cannot change on a per-user basis.

For this reason, most dynamic portal sorting solutions involve the use of an unstored calculation field for sorting. The value of an unstored calculation can be different for each individual user because the result is not stored, and can dynamically change.

If a portal is sorted by an unstored calculation, and the user can programatically change the value of this calculation, then they can affect the portal sort. This is the exact technique Digital Fusion has employed for our dynamic portal sorting for a number of years.

There are some good articles on this topic. Soliant Consulting have an implementation, as does MainSpring here .

Our approach of choice is a custom function provided by the developer Ugo Di Luca of DL Systems. You can find the custom function here.

Ugo's custom function can be used to produce a result of any number of various fields in a given table, in either ascending or descending order, for the purposes of sorting. He does this by converting a fields value from it's default format (e.g. numeric, date, timestamp, text) into a text string representation capable of being sorted as a text field.

What problems does dynamic sorting face?

While Ugo's solution is ingenious and works, it does suffer from a limitation of unstored calculations. An unstored calculation can only be one field type. If an unstored calculation is thus used as the basis of a portal sort then any field it represents must be cast into the same format as the unstored calculation.

Take a text calculation where we want to be able to dynamically change it's value to be that of other fields. These other fields could be numbers, dates, timestamps or times. Simply putting these types of values into a text field is not going to allow them to sort correctly.

The simplest example of this is the number 1 versus number 10. In number fields, 10 is greater than 1, but as text, 1 is greater than 10. This immediately breaks any sorting we would want to do on numbers.

To resolve this, Ugo has to convert all fields from their base format (e.g. number) into a text string representation that can still preserve sort ordering.

This adds quite an extra layer of overhead to this technique and is a drawback when sorting on lots of records.

The Server sorting issue

Furthermore, in order to dynamically specify which field to use in the unstored calculation, it relies on a user specific preference, and this is often handled through a global variable or global field. The value of an unstored calculation for one user may be entirely different for another user - keep this in mind.

In FileMaker Server 19, a new feature was introduced called Server Side Sorting. Basically this allows FileMaker Server to carry out the sorting of records where previously this was done entirely on the client machine. This greatly improves sorting performance as previously all sorting was handled client side and required the transfer of all records being sorted from server to client.

BUT (and there is always a but) this feature itself suffers from some problems when it comes to sorting unstored calculations.

When server sorts an unstored calculation it does not expect the value to be different for different users. It actually calculates the same value for all users and ignores any user specific preference.

As a result, this sorting technique breaks when FileMaker Server carries out the sorting.

Unfortunately we have no control over this feature other than to entirely disable it. When enabled, FileMaker Server makes a determination as to whether it will sort records or whether it will defer this to the client. This decision is made on various heuristics to do with server load.

In practice when FileMaker Server 19 came out, we saw our dynamic portals only sort correctly some of the time - the times where server was not doing the sorting.

This led us to the conclusion that unstored calculation based approaches are simply not that reliable from FileMaker 19 onwards.

A "Stored" Solution: Value Lists

So if we can't use an unstored calculation, how on earth do we do dynamic sorting? Well let's take a look at the sort dialog again:

We have this option here to sort based on a custom order. Ha! That sounds kind of like what we're trying to achieve. This is the option we investigated and looked to exploit.

So let's sort our records based on something unique such as the internal record ID. The field itself we choose is somewhat arbitrary so long as it is unique, and this internal record ID works best.

The actual sorting is done in the value list because it is the order of the value list which will determine the order of the records.

How does sorting based on Value Lists work?

Right, so all we need to do is build a value list of rowids which are in an order that we want our records to be sorted. Simple right? NO you fool! Nothing is simple when it comes to value lists!

We have to first understand what options we have when it comes to sorting a value list.

With sorting, we really have no options for a custom order. The order of a value list is always based upon sorting the primary field, OR by the secondary field if applicable. In the case of a text field this is always alphabetical which for us is useless - we don't want rowids sorted alphabetically, we want them in a predefined order of our choosing.

Which leads us to the next insightful breakthrough.....

The first challenge - Sorting a value list!

This:

There is an option to re-sort values based on a different language. Why would you generally want to do this? Well let's say you had values in a field that were German words. You don't want to sort these using the English alphabet which might be the file default, and so you instead choose from this drop-down the German language. So this is a language resort.

One of the available languages however is Unicode. Unique is a language which not only includes alphabetical characters, but numeric, and many other symbols. Each character is defined by an ASCII code number, and when sorting a value list by Unicode, it is actually being sorted on its underlying ASCII code.

Why is this of any relevance here? Well it all comes down to a very special ASCII character which has opened the door for custom value list sorting…

Enter the BOM

This character is called a Byte-Order Mark, or BOM for short. It is defined as a zero-width no break space. If you want to learn more you can read the wikipedia page here.

For us, the important characteristic about this code, is that it is invisible. We can include this character in a text string. It does not appear in the string, but it does influence the sorting of that string when sorted by Unicode.

The BOM character can be written in FileMaker using the Code function, i.e.: Code(65279)

So how does BOM sorting work?

Soliant Consulting first introduced this technique in this seminal article from 2012. I encourage you to read and learn about the technique here as they do a better job of explaining it than I ever can.

When a BOM is placed at the start of a string, it alters where that string appears in a Unicode sorted list. By appending more or less BOM's to the start of a string, you can alter it's position in the list when sorted by Unicode.

Here's an example where X is a BOM:

X3958

XX113

XXX924

XXXX2281

These values appear in this order when sorted by Unicode. The list is sorted according to the number of prepended BOMs.

This technique has been used with great success to allow record-based value lists to be ordered based on some sort order for each record. A calculation simply prepends a number of BOM items to the value based on where you want that value to appear in the value list.

Let's bring this back to our approach…

We are trying to build a value list of rowids in a specific order, so we could use this BOM technique to achieve it. This is exactly what we did – initially…

The second challenge - BOMs bomb out at a point

So, it turns out that the BOM technique works great when the number of values in your value list is relatively low (under 100 values).

Once you hit approximately 100 values things start to go haywire and the values are no longer correctly ordered, so why is this the case?

In the above image we have a list of numbers which are prepended with BOM characters (shown in red). This field was used as the basis of a value list, and the above values were obtained using the ValueListItems function. This function returns us the list of values as they appear in the value list.

Now, what you'll see here is 3 entries look drastically out of place. These occur from line 110 onwards, however when this issue presents itself depends also on the length of the number.

Why are they so far out of the desired order?

Turns out the issue is to do with how Value Lists order items. They do so using a fields Value Index. In FileMaker, a value index is not the entire value. This is the definition from FileMaker help:

A value index is created by taking each line of text (delimited by the carriage return character) and taking up to the first 100 primary character weights that all the characters in that line generate, according to the Unicode Collation Algorithm. See Choosing a language for indexing or sorting.

In short, once we max out the size of the value index for any given field value, things just don't order correctly. The first characters in this technique are always BOM's so at some point the value index for all records just becomes a big set of BOM's (not the actual field value we want which is the number component).

In short - BOM is great for small value lists, but don't use it on larger ones!

Can we use something other than a BOM to the same effect?

So BOMs kind of bombed out (pun intended), but perhaps not all is lost. Can we salvage something from the lessons learned about BOMs and how they help to do sorting?

Our main issue with them is the length of the BOMs breaking our value indexes. What if we can represent a large number of BOMs by something else which is much shorter?

The solution to this came from the brilliant mind of Steve Senft-Herrer (you may know him as Steve_ssh). What if we simply used a mapping of a values position to letters, and prepended the letters instead?

To show you what we mean consider the below mapping:

0 -> a

1 -> b

2 -> c

...

9 -> i

We simply map a number to a letter. To preserve correct positioning of a number, we always pad a number out with 0's until it is of a constant length. Let's pick 10 digits, so the number 1 becomes 0000000001.

Now consider the number 3,489,941. This could be represented as 0003489941 , or mapped is aaacdhiida.

Putting this all together, the value list from our earlier example would now look something like this:

aaaaaaaaab3958

aaaaaaaaac113

aaaaaaaaad924

aaaaaaaaae2281

This can be sorted as Unicode or Alphabetical and works the same way, it's the constant length alphabetic string at the start which determines the actual sorting of the values.

Wait, is this really going to work?

Remember, we're trying to sort a portals records by rowid, using custom ordering based on a value list that looks like the one above. Is that actually going to work?

If I want rowid 924 for example to sort to the third position as above, is it going to work given that technically speaking 924 is not in the value list, it is instead represented as aaaaaaaaad924?

Strangely enough, yes it will!

So, as it turns out in yet another interesting quirk of Value Lists, if you sort by a number field and choose to custom order based on a value list, then FileMaker will interpret the values of that value list as being in the same format as the field you are sorting by - in other words as numbers. FileMaker completely ignores any non-numeric character in the values and what you are left with is just the rowids which are numbers.

Why this is the case is a question for the Claris engineers.

Because this value list is being created purely for sorting purposes, and is not intended as a value list to be used for value selection, we really don't care about the fact it looks like gibberish - no one is ever going to see it. All we care about is the fact that it is a successful way for us to sort our records.

Time to build the value list

At this point we know it is possible to produce a list of values that can be used to sort records. That's only half the puzzle as we need to actually generate this value list.

How you do this is up to you but we found the best approach is to use a script to carry out the sorting and creation of the value list.

When a user chooses to sort a portals records, a script will run that will produce a found set of those records on a target layout (this can be done off-screen OR on server).

The script can then sort the found set of records by the order which the user desires.

Once sorted, a List Of summary field can be used to collate a list of values to be used in a value list.

We just need a calculation field on the table that can give us this value for each record. The calculation looks like this:

Let ( [ 
_PADDING = "000000000" ; 
~row_id = Get ( RecordID ) ; 
~record_number = Get( RecordNumber ); 
~prefix = Right( _PADDING & ~record_number ; 10 ); 
~prefix_encoded = Substitute( ~prefix ; 
                           [ "0" ; "a" ] ; 
                           [ "1" ; "b" ] ;
                           [ "2" ; "c" ] ;
                           [ "3" ; "d" ] ; 
                           [ "4" ; "e" ] ; 
                           [ "5" ; "f" ] ; 
                           [ "6" ; "g" ] ; 
                           [ "7" ; "h" ] ; 
                           [ "8" ; "i" ] ; 
                           [ "9" ; "j" ]
) 
] ; 
~prefix_encoded & ~row_id
)

We begin by getting the record's position in the found set padded with zeroes. It's position in the found set is the same as it's required position in the value list. This is then mapped to our alphabetical representation. Finally this string is prepended to the internal record ID.

As mentioned earlier, we summarise this value across all records for our final list. This value is then set into a field which serves as the basis of the sorting value list.

It is important to note this step. In order for a value list to work it has to be indexed, meaning it cannot be based on an unstored field such as a global. We want this value list to be user-specific and so you need to think carefully about this. The field you use has to be stored. We prefer to put this field on a record that is unique to the user, such as their own user record in a user table. That way the value list can be based on the same field but from a different record.

Putting it all together

Well, it was a long journey but we got there in the end, let's now recap the overall technique knowing what we now know:

Create a field in the table to store the internal record id - rowid.
Sort a portal by the rowid, choosing a custom order based on a value list, itself sorted by Unicode.
The value list is set up based on a field we'll call ordered_values.
The ordered_values are constructed from a found set of records that are sorted in the desired order.
Each record calculates a special string to be used in the value list. This is a combination of an alphabetical string representing a number, and the rowid.
To calculate the alphabetical string, take the position of the value in the list (it's record number), and map this number's digits to letters - being sure to pad with zeroes so that the length of the string is a constant length.

Clear as mud? Great!

Some advantages and drawbacks to this approach

The technique itself seems solid. It can also be made to be more performant than others as each time the portal records are sorted, there is no need to do intensive unstored calculations or conversions of values from their default format into strings.

Furthermore it avoids the unstored calculation issue concerning server-side sorting in FileMaker 19 as it is not based on a calculation. The sorting part is merely sorting a found set of records using a script, and so can easily be handed off to the server to carry out using Perform Script on Server. This can make it very fast to sort large sets of records dynamically.

Now for the disadvantages....

When a portal is sorted by a given order, it remains sorted in that order because it's sort is based on a stored value list. In order for a portals sort to be refreshed, the value list itself must be refreshed meaning the sort script has to be re-run. The implications are that new records added into a portal are not going to be properly sorted until this is done.

Sorting must also be triggered more often, such as when a layout loads or a portal is first displayed. It does add overhead in this respect.

For this reason, the technique has specific cases where it is really useful. These are portals where the records do not change often. This is most portals. It works great for larger sets of records. For smaller sets I'd be looking at the BOM technique as another viable approach.

In conclusion

We hope this article has not only given you some food for thought in terms of alternative approaches to dynamic portal sorting, but that you also learned a thing or two about BOMs, value lists, sorting, indexing, and many more things along the way - this was always our intention!

Dynamic portal sorting is a fascinating area because it is not something Claris has ever offered us as developers. How nice would it be if the Sort Records dialog could be dynamically programmed that would solve all our problems and remove all the need for this stupid hackery!

Example File

Don't forget to check out the example file if you haven't already. Download it here.

As always, please feel free to leave a comment, we appreciate all feedback.

FileMaker 2023 Is Here!

Thu, 27 Apr 2023 13:30:00 +1200

Yes, you read that right, Claris have released the next version of FileMaker and decided there will be no FileMaker 20 or 21 etc., and have headed straight to "FileMaker 2023".

Since the release of FileMaker 19 in 2020, Claris have made many very important improvements and released them in small doses as incremental “point” updates (19.4, 19.5 etc.)… So to help customers see that year-on-year the product moves forward quite substantially, they’ve decided to use this yearly based naming system. And it’s easy to see when you’re falling behind!

Confused yet? Don’t worry because what excites us most at Digital Fusion is that Claris are continuing the evolution and releases of the FileMaker platform that we use and love. Doubling down on this, we also get a cool new logo:

So What’s New In FileMaker 2023?

For end users there’s not a great deal of visible difference, and that’s not a bad thing in some ways because it means you will continue to work like you always have, without any major changes to disrupt your business operation.

Where it does get interesting, and in some cases relates to a better experience for you as an end user, is all the tweaks made in the “back end” of the platform. Here’re a few that’ve caught our eyes:

Performance and Stability: One thing that can be said about Claris, they like to keep a stable platform, born from having been around for so long. At the same time they’ve also been steadily improving performance and this release builds on that with some more improvements in key bottleneck areas.
500 Bugs: Yes, Claris has “squashed” over 500 bugs since 19.0! That is an astounding number… we’ve encountered a few and are very glad to see them fixed, but who knew there were that many issues, even in an exceptionally well sorted platform like FileMaker.
FileMaker WebDirect: A section of the FileMaker suite that doesn’t always get the attention, but now it’s been given some major lovin’ in this update: it’s now faster, easier on the server resources, and you can have to 1000 users!
Linux Hosting: A few years back Claris added Linux servers as one of the options to host your solution. The big gain with Linux Servers is that they are cheaper and leaner to run than Microsoft Windows-based servers. We’re gradually migrating many of our clients across but there are a few technical challenges when you’ve already been set up the Microsoft way.
Security: This is fundamental to any new release, and security is often number one on the list of things Claris FileMaker are working on. They have support for the newest security and authentication protocols shields your solutions from threats.

That’s really just the tip of the iceberg — you can’t even see some of the most important changes like improvements to how FileMaker manages it’s caches. Rest assured Claris are working very hard to keep FileMaker the best of the low-code, high-productivity platforms available.

Don't Get Duped When Duplicating Records

Tue, 28 Mar 2023 06:00:00 +1300

Introduction

On the surface, duplicating records in FileMaker is straightforward. We use the Duplicate Record script step to do this.

However much like everything in FileMaker, what appears simple on the surface can become rather technical and complex. There's always more than one way to skin a cat, as they say.

In this article we're going to explore some of the different approaches to duplicating multiple records and their relative performances.

We should note at this stage that these approaches were purely born out of experimenting and playing with different approaches in an attempt to find an optimal solution with regards to performance. Some of the approaches are certainly not recommended but are still mentioned for comparison and out of interest. You may find you learn something along the way!

Duplicating Parent and Child Records

Duplicating a single record is simple, but we will be duplicating many hundreds of records. In addition, not only will these records be duplicated but they have related child records that also need to be duplicated.

An important factor of parent/child duplication is the child must be reassigned to the new parent ID. This point becomes quite significant when deciding upon your approach to record duplication.

Example File!

As with all our articles, a lot of time and effort goes into our example files to help explain techniques used and to allow you to explore and try for yourself.

Please take time to download this as the article very closely follows the content of the example file — no email address required!

Click Here to Download

Trying some Different Approaches

The approaches taken to parent/child record duplication began with the first approach and subsequent approaches were born out of this by looking at ways to change it and potentially improve upon it by hunting out optimisations in the process.

In the end we came up with 7 different approaches. We must warn you not all approaches are great. We left in the bad ones because you can still learn something from them, and hey — you may just come up with a better solution yourself — we always love feedback!

Our Test Scenarios

We ran each duplication test a series of 5 times and took the average duration of each test to be our result. Taking the average means we can try to eliminate minor server performance fluctuations. Tests were performed on a Mac Mini M1 machine running FileMaker Server 19.6.3 with no connected users.

The tests were run using Perform Script on Server and before each test we cleared out any previously duplicated test data.

We ran ten variations per approach. We incremented the number of parent records being duplicated by 100, for a total of ten tests ranging from 100 to 1,000 parent records.

Finally each parent record duplicated had about 6 child records residing in two different child tables for a total of 12 child records overall. All child records were duplicated and assigned their new parent ID.

Approach 1: Loop From End

Our first approach is the simplest approach. It involves looping through parent records. Looping is itself an entire subject worth delving into (click here for an earlier article on this topic).

The above is the loop method being used in this approach. Important is to note the following aspects:

Looping begins at the end of the found set.
After we duplicate we omit both the new record (last record) and the parent record (one prior to that).
We proceed to duplicate any child records
The loop ends when we have no more records in the parent found set.

This approach is called looping from end because we start at the end of the found set, working backwards.

For each parent record duplicated in this fashion we repeat the exact same procedure for any child records.

Child records are found by first navigating to the child layout and performing a find for any child records that are related to the parent. If any records are found they are duplicated using looping from end.

Pros:

A benefit of this approach is that the script is very simple to follow and understand for other developers as well as easy to write. It is also easy to add in extra child tables for duplication if required in future.

Cons:

A downside to this approach is that the resulting duplicated records are in reverse creation order to that of the originals. When we loop from the end we are duplicating the newest record first and working back to the oldest.

This may not seem like an issue but if you are duplicating records where you expect them to be present to the user in their original creation order, then this will not work unless you sort them. Sometimes you simply don't wish to sort records and so if that is the case this approach may not be for you.

Another often overlooked issue with reverse looping is how FileMaker pre-fetches records from server. When you are looking at a layout that has at least one field on it, FileMaker will download from the server the next set of records in the found set. When on Form View this is the next 25 records. For List View it is the visible records plus 50 more, and the same rule applies for Table View.

FileMaker does this to allow for smooth scrolling through records as it makes the assumption you will be doing just that. This only works forwards however, not backwards.

Consider starting at the end of a found set. No pre-fetching occurs because there are no records ahead in the found set. Now when you navigate back 1 record FileMaker must query and download this from the server as it has not been pre-fetched. Repeating this backwards through a found set requires an individual query and download of each record to occur.

Approach 2: Loop From Start

To help combat the reverse creation order issue presented in the first approach as well as pre-fetching, a small change can be made to simply loop from the start of the found set rather than the end.

Pros:

That's it. The only real change from approach 1. The benefit now is we do get our duplicates in the same creation order as the originals. We also utilise pre-fetching as FileMaker will give us at least the next 25 records in the found set pre-fetched to reduce the number of server queries for record data required. This fact also means doing a loop from Start in list or table view is preferable as more records will be pre-fetched.

Cons:

Not necessarily a bad thing but it can be noted that we now require some extra record navigation to duplicate records. Duplicate records are added to the end of the found set, so after we omit the duplicate, we have to jump back to the first record to omit that. With Approach 1 this was not required.

In the grand scheme of things this record navigation is probably going to have a negligible impact.

Reducing Overhead

The first two looping approaches are simple to follow and robust. However keen eyes might have spotted in the example file that there is quite a lot of finding occurring as well as layout switching.

For each parent record we navigate to both child layouts and perform a find. We duplicate any found records before switching back to the parent layout and continuing.

That's a lot of layout switching! If duplicating 100 parent records, this means upwards of 300 layout switches and 200 finds!

With this in mind the next approaches aim to eliminate the need for these finds and switches as much as possible.

Approach 3: Go to Related Record - Per Record

Relationships can be created between parent & child and these relationships can be used to test whether any child records exist. By checking first we can eliminate the need to switch layout and search for child records.

Furthermore, the relationship itself can act as a means to navigate to the child records for duplication rather than doing a find.

This approach makes use of this fact by first testing child relationships for records and using the Go to Related Record script step to navigate to the child records for duplication.

Duplication of a found set is still achieved through looping using Approach 2.

Pros:

The significant benefit is that we eliminate needless layout switching and finding by testing the relationship instead and using Go to Related Record for navigating to the child records.

Cons:

Whether this is a con or not is all in the eye of the beholder. This method does require you to establish a relationship from your parent context to your child tables. If you've somehow managed to build a FileMaker database without relationships (shame on you!) then you could see this as being a nuisance but realistically most solutions benefit from having parent/child relationships.

Go to Related Record…

At this point we were pretty happy with Approach 3. However there was still some potential here for improvement. So what in the approaches could still be optimised?

We looked to the Go to Related Record script step. In the previous approach we used this step to duplicate child records for each parent record. If we were duplicating 1,000 parent records then at worst that means 1,000 Go to Related Record steps per child table.

What if we could do the same thing but just with a single Go to Related Record step?

Well the step does give us the ability to navigate to child records for all records in the found set - can we use this?

The plan was as follows:

Loop and duplicate parents (but keep the original found set - do not omit records)
Go to all related child records for all parent records in a single step
Loop and duplicate all children.

Sounds great! There is however just one problem...

Child records must be assigned the new parent ID. When using Approach 1-3 this is simple because we're just storing the new parent ID into a variable, and setting it onto the children.

However with this modifed approach we don't know what the new parent ID is for a given child record. In order to know this we have to create a mapping between the original parent ID, and it's duplicate ID.

If we can establish a mapping structure then when we duplicate children we can consult the mapping to derive the new parent ID by looking up the old one.

Approach 4: Go to Related Record Found Set - List

Approach 4 is the first mapping approach and uses lists to map original parent IDs to their new duplicate IDs. These lists are maintained in local variables.

When it comes time to duplicate child records, we take the existing parent ID on the child record, and use it to look up it's position in the list of original parent IDs. This position can then be used to look up the corresponding parent ID from the new duplicate list.

Pros:

A benefit of this is we only require a single Go to Related Record script step to find and duplicate children records rather than one per parent record.

Creating the mapping is pretty simple and we are just using the List function to compile lists of old and duplicate IDs as we go.

Cons:

Having to maintain the mapping is itself a negative - the reasons why will become apparent later when we discuss results.

The overhead required to generate the mapping and to retrieve the new parent ID from this mapping is quite expensive and at high record duplication numbers will just completely negate any performance gained by doing a single GTRR step.

It's an elegant approach overall and one that does work well for low record duplication counts - but once you hit a certain point the cost outweighs the benefit.

Approach 5: Go to Related Record Found Set - JSON

Because of the list methods failed performance due to it's creation, management and retrieval of parent IDs, we looked to instead use JSON as our mapping mechanism.

JSON is great at storing information and in this case we are going to use simple key/value pairs to be the mapping between old and new parent IDs.

We simply add a mapping to the JSON using the following:

JSONSetElement ( theJSON ; parentID ; duplicateID ; JSONSTRING )

When needing to retrieve the duplicate ID we simply use:

JSONGetElement ( thsJSON ; parentID )

Pros:

You could consider the use of JSON a more robust method of mapping parent/duplicate IDs but that's about it!

Cons:

JSON functions in FileMaker are terrible! Their performance at large sizes is just garbage. Again at low duplicate numbers it's acceptable but for anything over a couple hundred the performance of these functions just ruin any perfromance gain.

We failed?

The mapping approaches in 4 and 5 in theory should be faster than layout switching all the time but the cost of having to establish a mapping between parent and duplicate IDs is just far too great. Until a better and much more efficient method of mapping can be found, these approaches only work well at low duplicate counts.

So what else is there to try?

Approach 6: Export / Import

The Import Records script step is another way in which records can be created in a table. What if we exported all required records to disk and then imported them straight back in to the same table?

This approach negates the need for any looping necessary for record creation.

We export a found set and import it back in as the new set of duplicates.

However we do still suffer from the issue of having to establish a mapping and use this to assign new parent IDs to the child records. Once we establish a mapping then they can be assigned using the "Replace Field Contents" script step as opposed to a loop.

Pros:

There are no loops in this approach as the import is the process of creating duplicates.

Cons:

The Export Records script step is not very server friendly because it cannot be used to export a FileMaker file. Nor can you import from a FileMaker file on server.

This means if the process is to be run on server then things like container fields could not be duplicated (unless you did something like base64 encode them as text for the export but that would negate performance).

This technique is best suited for smaller text only record structures.

An Idea about Improving Mapping....

The key issue with our approaches is the performance of mapping old/new IDs when it comes to using GTRR or Export/Import.

Mapping performance seems to be slow at large duplication sizes for two reasons:

The cost of compiling the lists.
The cost of retrieval of duplicate IDs from the list.

In thinking about this we came up with a variation on Approach 4 which attempts to eliminate the need for using the List function at each step of duplication. Rather than add one item to the list during each iteration, we instead compile the list before and after duplication.

Approach 7: Go to Related Record Found Set - List ++

This final approach makes use of the List Of summary function type.

To obtain the original list of parent IDs we just store the summary fields value into a variable.

Next, we need to duplicate the parent records such that at the end of this process we are on a found set just of the new duplicate records.

This is fairly easily done by a small tweak to the looping process.

We do this in a new window to preserve our original found set for later. Next we store the very first duplicates ID into a variable - this will act as our stopping point in the loop.

As we duplicate we omit the parent only from the start of the found set, and we stop once we reach that very first duplicate record created.

Now we're on a found set of duplicates and we can again use the summary field to return the list of duplicate IDs.

Pros:

We do gain a little performance here using this method over the List function.

Cons:

Still at high record counts it's not great, most likely due to method of ID retrieval from the mapping.

We had to stop somewhere!

This article took so long to write because at every point in the process we kept finding new ways to optimise and tweak approaches. Tests had to be rewritten and re-run and so the whole thing would just keep going forever without drawing a line in the sand.

We invite any readers to attempt this approach and let us know in the comments how you go and how your performance compares to the other methods.

Some other ideas explored include:

Sorting found sets by parent ID before duplication. This way we know the order of mapping, and if we sort child records by the parent ID, we can be sure their order matches the mapping. The means of retrieval of the duplicate ID from the mapping can then be changed to look up a value based on tracking a position in the list as you loop rather than always looking up from the list (where the ID could be in any random position).
Combinations of techniques - can you use export/import for child duplication, and looping for parent generation?
Does Replace Field Contents work better for assigning new parent IDs to child records?

Also if you have any other ideas around optimisations we'd love to hear them.

Overall Results

So with all that said and done here are our final results for performance of tests (times are in milliseconds)

	Test 1	Test 2	Test 3	Test 4	Test 5	Test 6	Test 7
100	711	676	645	473	482	326	468
200	1423	1356	1260	1022	1058	671	966
300	2147	2080	1871	1640	1751	1098	1513
400	2756	2667	2495	2320	2537	1544	2154
500	3619	3431	3125	3115	4167	2046	2814
600	4121	4211	3740	4179	5536	2630	3518
700	4901	4883	4360	5298	6851	3293	4441
800	5559	5314	4981	6501	8242	4023	5482
900	6181	6100	5581	7792	9771	4737	6579
1000	7120	6728	6299	9204	11351	5531	7448

What Did We Learn?

What we learnt could be summarised as follows

Looping is simplest and easiest for developers to write and understand and works well at low duplicate counts.
GTRR and mappings is even better for lower record counts, but can suffer at higher duplicate counts.
Export/Import works great and is fast so long as your conditions for using it are correct.
The methods can always be optimised further.

In Conclusion

Realistically speaking the need for massive amounts of record duplication is low and infrequent. The intention of this article is more to give you an understanding of how different approaches can be employed to solve a single seemingly simple situation. Every step used can be considered and may have an impact on performance. Not all techniques are linear - some start off good but get progressively worse compared to others as record sizes increase. Never assume a technique is going to scale linearly.

Example File

A final word – please check out our example file :)

Click here to download the example file if you haven't already.

It's Time To Get Together…

Tue, 28 Mar 2023 00:00:00 +1300

It's been three long years since the Claris community got together in the APAC region to share ideas, inspire each other, and network.

We're rapt to announce that in 2023 we are getting back to the old ways, and have joined forces with a few of the other developers from the region to organise the first Claris/FileMaker themed conference in the region since 2019!

Reconnect.Sydney will run over Thursday the 20th and Friday the 21st of July — lock in the dates! In fact if you'd like to join us we highly recommend getting tickets asap.

As much as it says Sydney in it's name, this is a conference for the whole Asia Pacific region... in fact it's for the whole world as we would love to welcome all to come and share in this great occasion.

Details of the schedule are yet to be worked out but we're working on:

Two days of expert presentations
Speakers from Claris
Social events
Plenty of networking time
An event for Claris Partners

Tickets are now available to purchase so head over to the Reconnect.Sydney website and check it out.

My Crazy Trailwalk For Charity

Tue, 07 Mar 2023 16:08:00 +1300

So, sometime around July of last year, I heard from a friend of mine who lives up in Auckland... he sent me a link to a trail-walk taking place the following year and enquired if I'd be keen…

100km in less than 36 hours

The venue: Taranaki, on the west coast of the North Island of New Zealand.

Clearly an insane distance, but as I'd been doing a lot of hiking at that time (albeit nothing even approaching an echo of that distance) it seemed like a relatively accessible challenge.

There was another aspect to it, we were required to raise an amount in donations for Oxfam to take part...this was my main concern, but I was swiftly told "she'd be right". Problem solved then ;)

A Team Sport

I was in. The next thing was we needed a team of 4. And there were only 2 of us.

I have a friend down Southland (where I'm from) that I figured would be a 50/50 shot. I put it to him, he was interested but told me he needed to sleep on it, then I heard from him hilariously early the next morning telling me he was in.

So that made three, we still needed a fourth. Thankfully, my friend from the South conscripted his brother who I knew to be a good sort. We had our team.

And now July of 2022 has moved on into March 2023, the event itself is less than a week away. I've booked my leave from work, my flights, accommodation. No backing out now.

Our Fundraising Target

The training has been intense, though as I feared, we still haven't made our donation target. So please, if you're reading this, and you're inclined to give to a good cause every now and then – consider Oxfam. You could do a lot worse. Their mission is alleviating poverty across the globe. This can take several forms:

Emergency and climate change relief
Developing relationships with communities to empower them in escaping poverty
Fighting discrimination, and working with governments in exposing and changing unjust laws

To help me out here, head on over to my donation page, thanks!

Having said this, we would like to express unending gratitude for those who have already donated, you know who you are, and you're amazing!

'naki, Here We Come!

I've got no idea how the weekend itself will go, I had a training plan worked out but that got shunted aside due a bunch of things... covid, Christmas, complacency. That said, could you ever feel prepared for something this absurd?

We'll make it to the start line, and we'll see it through to the finish line if our bodies are able.

That's all for now. I'll check back in after the race and let you know how we got on. And I promise I'll take a whole heap of photos!

Claris Update - January 2023

Fri, 03 Feb 2023 00:00:00 +1300

Last week, Claris hosted a webinar to share what's been happening with the Claris Platform and Claris Studio, and also to tell us what is ahead in terms of the development plans.

Studio is coming on in leaps and bounds, with very frequent updates, some of which are very exciting. The puzzle is coming together, and more rapidly than we have ever seen another product come from Claris/FileMaker.

We already have the ability to create anonymous web form collection, the ability to chart this data, and something very exciting, the ability to create Kanban views of the data.

Along with this, they are releasing new versions of FileMaker Pro and Claris Pro (along with the other products in the suites) at a rapid pace.

One of the key changes coming soon is that the Claris platform will be able to be hosted in data centres other than the current US based servers, which has been a damper on performance from this part of the world.

2023 is shaping up to be a big year for Claris and we know the team at Digital Fusion are eagerly awaiting whats ahead.

For more info on Claris Studio go to https://www.claris.com/studio/

If you are interested in finding out more and watching the webinar, check it out below...

Navigation that Responds on Mouse-Over

Fri, 04 Nov 2022 10:32:00 +1300

Introduction

In this article, we're talking about building Navigational Controls which respond to the users Mouse when they are hovered over. We will call this a responsive navigation for the benefit of the article.

Currently, buttons and controls can be responsive to the user in a variety of ways such as:

Transitional Effects (switching layouts on iOS)
Animation (popovers and Panels)
State Changes of objects (onHover, onPress, onClick etc._
Formatting of an object (conditional formatting, hide conditions)

This article is going to focus on a different type of interaction a user can have with a button that will happen on the Hover state of an object. Typically a user will interact with a button or control by clicking on it. There is however a pretty simple way to turn almost any object on a layout into an object that will immediately respond to the users mouse when hovered over.

Example File Time

This is a very example-heavy article and as such we recommend downloading and looking through our example file which contains all the examples featured below.

Click here to download the example file.

Not Our First Time Around This Block!

This technique can be utilised in a number of ways and this is not the first time we have covered it on the Weetbicks blog.

In 2014 we wrote two articles that utilised the mouse-over technique.

The first article showed how you could utilise this to produce a sliding-drawer control that could automatically open and close just by the user hovering over it.

While the second article dealt with opening and closing pop-over menus by hovering the mouse over a pop-over button.

This time we're presenting three further examples of how it can be utilised in a navigational sense. Note this is not just some fancy trick. This is something we use in our client solutions to great effect. It does however have to be used carefully and only in circumstances that warrant it. Not all navigation controls benefit from having a mouse-over triggering them.

Making A Mouse-Over Trigger Possible

As a quick refresher on the technique covered in the two earlier articles, let's look at how we actually initiate a Mouse-Over event.

To achieve this we require a plugin that is capable of running a script. Our plugin of choice is always BaseElements from Goya.

We simply attach a tooltip to any object we wish to initiate a script.

Tooltip calculations evaluate immediately when the mouse is placed over them, even if they do not immediately appear. This is good because our script is run immediately giving very responsive feedback to the users input. Here is an example showing how frequently a tooltip is evaluated. We are running a script that is incrementing a counter:

We have written a custom function to accept the script name _scriptName and optional parameter _parameter for the script. It looks like this:

If ( not IsEmpty ( Get ( ScriptName ) ) ; "" ; Let ( ~run = BE_ScriptExecute ( _scriptName ; Get ( FileName ) ; _parameter ) ; "" ) )

You might be wondering what the first condition of the IF statement is for. Our tooltip calculation is checking whether a script is already running by looking to see if Get(ScriptName) is returning a script.

This is because tooltips can also respond to the user while a script is running. Every time the user moves their mouse over an object, a new call to the script would otherwise be called, thus creating a stack of hundreds or thousands of scripts to run.

To avoid this, our tooltip calculation will only ever run a script if no other script is running, thus avoiding this issue.

An example of Portal Navigation

So that's the basic technique, there really isn't much to it. Let's look at a few examples, all of which you'll find in the example files.

This is our example files main navigation. As the mouse moves over it, a script is initiated from within the portal to carry out navigation. This is the same control featured in our first navigation article about layout-level navigation. All we had to do was add a tooltip to the existing button.

An Example Of Button Bar Navigation

Here is an example of a button bar used to control navigation within a layout. Much like the portal example, we are using a hidden sliding panel as our sections of the layout, and the button segments control which panel is visible.

In addition to this, we also have two pop-over-based segments which themselves are opened via a tooltip.

How Do We Avoid Accidental Mouse-Over triggers?

The button bar above is a particularly nice use of this technique because the user tends to move their mouse horizontal across the button bars, and then when they have made a selection their next mouse movement is in a downward direction to either the pop-over or to the panel content.

This horizontal/vertical mouse movement lowers the risk of any potential "accidents" that may arise due to the user inadvertently putting their mouse over a navigation element they didn't wish to select.

This is a classic issue with this technique. We wish to try to eliminate accidental Mouse-Overs. In reality, this is quite hard to do, which is why using it with caution is advised, not all navigation benefits.

There are a few useful tips to adhere to.

Firstly, the larger the button area selectable the better, e.g. taller portal rows, and larger buttons. This gives more affordance when the user moves their mouse away from the object so that they will not touch another object.

Next, consider adding a "dead-zone" to the navigation, particularly if using a portal. In our example above we actually make the button not quite the full width of the portal, but rather have it cover the text instead. This is usually effective because users tend to Mouse-Over text (whether they realise it or not) and second when a user leaves the portal for the panel to the right, they may head off diagonally up or down. By creating this dead-zone patch we can ensure they leave safely. Here is a dead-zone in yellow:

A Final Example Of Multi-record Selection In Portals

This last example is not strictly navigation but rather has to do with selecting entries in a portal. Here we have a 3-tier portal structure where the user is to select from all 3 portals. The portals may contain fixed values, or they may be conditional in that the values in the second portal change depending on the first, and the values in the third change depending on the second.

Here the mouse movement is up/down, followed by a move to the right for the next portal. Again we run the risk of the user moving diagonally up/down from their selection and so a dead-zone could be used.

In Conclusion

So we've shown a few different use cases of mouse-over for navigation. As mentioned this is to be used with care – there are many situations where standard navigation involving a mouse click is preferable. However, this does have its own use-cases and you may find a good use for it. In our experience, we found the best application is menus that contain a lot of sub-item menus, be it via a panel or pop-over. The users end goal is to get to the sub-level navigation and so not having to click before they get there can often be a nice experience.

Example File

A lot of time and care goes into our example files and we appreciate you taking the time to explore and learn.

You can download the example file here.

Welcome Maddy and Andy

Wed, 02 Nov 2022 12:39:00 +1300

It seems like just yesterday that we posted that we had added to our team, and here we are again, adding to our team: this time we get to welcome two new comers, Madeleine Voice and Andrew Mills.

It’s worth noting that we felt we had maxed out in our "Paul" brigade, now totalling three, so have moved onto the name of Andrew, hence new-Andrew is being referred to as Andy.

Anyhow, onto welcoming Maddy and Andy to the team...

Maddy Voice

Maddy is like a lot of DF’ers, having had a previous life in a totally different career before seeing the light to become a FileMaker developer.

She has Bachelor of Plant Science degree from Lincoln University here in Canterbury, and pursued a career as a triticale breeder: for those who don’t know what that is (and in all honesty, that’s 99% of us), we’ve provided a very helpful link that explains.

While working in the seed breeding industry Maddy could see first hand the need for solutions that would give her a smarter way of working. There had to be a better way to work with data than pen, paper, and Excel…

We love it when people come to software development knowing what the “need” is because there is real understanding and purpose behind their motivation.

Keeping Maddy busy outside of work, is her two year old daughter, Juniper. The backstory to Juniper's name is that there’re four generations of women all named after botanicals, i.e. Ivy, Hazel, Rose, Daisy, and Daphne.

Also on the hit list of interests are yoga, maintaining her extensive house plant collection, and snowboarding.

The real claim to fame that only came out in passing conversation is that Maddy once competed in Muay Thai, including four official fights, plus a broken foot. She’s one person you don’t want to mess with.

Andy Mills

Like Maddy, Andy comes to us with an interesting career path, having spent 8 years in geotechnical instrumentation. Once again that takes some explaining, but after a quick search of what it actually means, we/you will be even more lost (inclinometers, piezometers, tilt meters, beam sensors etc etc). Let’s just say that Andy has a friend in Paul Hutton, who joined us with a previous career in geology (and now 20+ years as a FileMaker developer).

Andy made the switch to IT a few years ago because, in his own words, he "loves technology and achieving results that would otherwise be unobtainable." We like that too!

In his spare time Andy gets up to all sorts of mischief, but one of his passions in life is his role as a volunteer firefighter. He’s currently based at the New Brighton Volunteer Fire Brigade here in Christchurch.

Andy is also somewhat of a water baby, in what seems like every water pursuit. This has lead to his claim to fame, that being once chased by a humpback whale. We are pleased he survived, and gets to join the team.

Avoiding Multi Window Record Locking

Thu, 22 Sep 2022 00:00:00 +1200

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:

Use a Custom Menu Set on your layouts.
Attach a Custom Menu where its name contained a calculation.
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:

Select Old Window
Commit
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

Three (New) Amigos

Wed, 06 Jul 2022 06:48:00 +1200

Over the last year, Digital Fusion have taken on three new developers, to bring our wonderful team up to now total 19.

All three of the ‘newbies’ came to us with varying backgrounds, both in terms of their careers to date but also their previous exposure to FileMaker.

We are proud to have them on our team, and to follow is a little bit about each of them…

Reis Adamson

Reis is unique amongst the three of them, in that he’s joined as a ‘remotie’, but he also came to us with a huge amount of experience in FileMaker.

He’s based out of Lismore, which is in the northern section of NSW, around a three hour drive from Brisbane. This means he’s not too remote, and he gets to catch up with Morgan and Sam from time to time.

Although Reis was a promising orchestral percussionist in the Sydney Youth Orchestra, he went on to study and work in graphic design before eventually finding FileMaker as the ultimate creative platform.

Reis comes to us with a wealth of experience in FileMaker but one of the appeals of joining Digital Fusion was to extend his knowledge, and learn from our team, so we are stoked we can help him out there.

In his time away from work, Reis is active with his partner and two dogs, with the dogs taking a starring role in many a Zoom catchup. Reis is also into cross fit and running, so keeps an active life away. One of his life goals is to buy a property in the Northern Rivers region and have horses on it.

The claim to fame for Reis when he joined DF was that he had never seen or touched snow. In his recent trip over to Christchurch, he held great concerns that he would be very cold, so had to borrow ‘winter clothes’ from his brother in law. It was pointed out that he was a month or two away from our coldest days, and he was pleasantly surprised how mild it was. He has yet to see or touch snow.

Andrew Close

Andrew is the ‘young one’ of the three, but where he lacks in age, he makes up for in height, topping out at an impressive six foot six inches (1.98m). This has made him very handy as the architect who designed our offices, installed windows that nobody else can reach.

Coming to us with a Mechanical Engineering degree plus a number of years working for a company that designed and inspected ceilings, Andrew understands what makes FileMaker such a valuable asset to a business. Although not having used FileMaker previously, he’s taken to it quickly, and has already seen how we transform clients efficiency.

Andrew is very active in the church, playing in the band, and getting roped into all different sports teams. He’s also a regular bike rider, commuting to work each day is 30km plus round trip.

Andrew’s claim to fame, he is the first ever employee of DF that is younger than the company itself.

Glen Naysmith

Glen’s our ‘newbie’ in terms of his time with Digital Fusion, but he comes to us with a wealth of experience, both in terms of IT, but also understanding what makes businesses tick.

Having been in Auckland for the last few years, he’s relocated to the beautiful Cass Bay in Christchurch, and is loving the 15 minute commute to work each day. He’s also loved getting his teeth into FileMaker, and working with clients.

Having spent his early years studying and then being a builder, he now has a vast array of tools in his garage that are gathering dust.

Glen’s claim to fame is that he was once an avid reader (before having kids) but had never read a Jack Reacher novel before winning a competition to meet the author when he was touring NZ. Awkward.

And he may, or may not, have played THE starring role in a traditional fairy tale…

Claris Problem Solvers Circle

Fri, 27 May 2022 08:21:00 +1200

We recently had two big announcements from Claris that we'd like to share—

Firstly we had the release of a new product, Claris Studio. We will tackle this one in another blog post, but in short, it’s a product that will start to fill in the gaps of what Claris/FileMaker can offer.

The other announcement was of a new licensing promotion, the Problem Solvers Circle:

Claris are super aware that once FileMaker is embedded into businesses and organisations, it can lead to massive improvements. While you might start with one app, Claris want to encourage organisations to take advantage of the platform solve more problems and build multiple apps.

The Problem Solvers Circle allows you to embed FileMaker into all four corners of your organisation by giving you a license for 100% of your staff.

Before getting into the nitty gritty of how this works, it’s worth pointing out a few gotchas:

Clients who have Site Licenses (ASLA) are not eligible*
It’s not for new licensing, you need to be an existing FileMaker user
It’s only for annual license holders, if you hold perpetual licenses, you can’t join.

* A lot of our clients fall into this category already, and are using FileMaker extensively with an Annual Site License.

So what is it and what does it cost? The best way of describing this is to use an example company and actual license costs (based on an Australian business in AUD)…

Let's say ABC is a company of 50 staff, but only 10 staff currently use an app built with FileMaker. For the last few years they've purchased 10 User Licenses which costs them $2072.40 + GST per year.

Under the Problem Solvers Circle, you commit to two years of licensing based on the previous year of licensing (as above), add a 30% premium, and in return you get licensing for the whole company (i.e. 50 staff in our example).

So for ABC, to join the PSC for the next two years would cost them $5388.24 + GST (remember this is for two years, so that’s only $1300 extra for the 2 years)

To show the value of this, if they didn’t join the PSC, to license all 50 staff would normally cost $9050 + GST for the two years.

We think the Problem Solvers Club is a great option for a number of our clients and we will be discussing this with them over the coming weeks. It’s particulary useful if you want to expand FileMaker into all areas of your business, and potentially the cost of licensing has been a little high.

Do get in touch if this is of interest, we are always keen to walk you through what it might look like for you.

Navigate the DF Way - Solution Navigation Bar

Thu, 26 May 2022 06:46:00 +1200

Introduction

In Part One of our Navigation series we talked about how to implement navigation within a single screen by building a portal of Navigation records. This utilised a table called NavigationItems where each record was an element in the navigation portal - be it a screen, a header, or a separator.

In this article we extend this table further to build a Navigation Bar used for solution-wide navigation. We introduce a new NavigationSets table and talk about it's purpose for allowing multiple different types of Navigation Bars.

We also talk a bit about Dashboards and how these can be customised to suit each individual user within a Navigation Bar.

So, let's jump right in!

Example File

This is the type of article where it will really help if you follow along using the example file because a lot of the examples given have come direct from our example file.

Click here to download the example file.

What is a Navigation Bar?

A Navigation Bar is a horizontal (or vertical) object that contains buttons the user can interact with the navigate to different screens within a solution. Below is an example of the Navigation Bar you'll find in our example file:

They can be built in a number of ways using different FileMaker techniques.

Historically at Digital Fusion our Navigation Bar for years was a series of repeating fields placed across the top of each layout. We would have a repeating field for an icon, another for the label, and more for the buttons that the user interacts with.

One of the disadvantages we had with this approach was that our Navigation Bars were context dependent. Every time we wished to place it on a new layout of a different context we would have to re-point all the fields to the parent context. The fact that it was comprised of multiple fields and objects also made it a pain to work with.

A Button-Bar Based JSON Approach

These days we have abandoned repeating fields in favour of utilising button bars in conjunction with JSON. We construct a JSON object which is a complete representation of each Navigation Bar, and then load the JSON into a global variable for the user. This is used by the Navigation Bar for both its display, and for determining which action is to be carried out when a button is pressed.

With the information stored within a JSON object we have everything we need to build our Navigation Bar object. However that is only half the story. The basis of the JSON is a couple of navigation based tables. Think of these as our underlying navigational structure. We have already seen one of these tables in our first article - NavigationItems - and now we'll talk a bit more about the structure for our Navigation Bar.

The NavigationItems Table

The NavigationItems table stores information about each individual item in our navigation object. In part one we saw it used for items in a portal based control we built for navigation within a single screen. We are now going to use it as a store of information about each item represented in our Navigation Bar.

The majority of fields we utilised for the portal navigation will be reused for our navigation bar. The main exception however is the icon. Because we will be using a button bar object, we have no control over dynamic display. Any icons in a button bar would have to be hard-coded into each individual segment, and this defeats our goal of building a Navigation Bar that is entirely soft-coded. For this reason we will not be using icons.

We also won't be using separators or titles in our Navigation Bar - each item in the button bar will be clickable.

We have however introduced two new fields into our table:

The first is id_dashboard. This will serve as a foreign key, pointing to another special NavigationItem record. We'll talk more about how this works later.

The second is id_navigationSet. This is a foreign key also and links each NavigationItem record to a parent NavigationSet record.

The NavigationSets Table

Think of this as a parent table for a collection of NavigationItems. Each record in this table serves as a single Navigation Bar.

The table comprises of the fields:

flag_default: Indicates which Navigation Set is the system default for users.
id_dashboard: A calculation that determines the id of the special dashboard NavigationItem record. More on this later.
name: We give each set a name, obviously.
zzrec_id: The primary key.

That's about it, not much to it really.

If you want 10 different navigation bars in your solution then you would create 10 different records in this table each with its own set of NavigationItems. Once you have your Navigation Sets created with items, then it becomes a case of deciding which one to use for any given user.

Types of Navigation Items

In part one we saw 3 different types of NavigationItem records. We had one for a screen, a separator, or a header. These were defined using the type field.

However in our Navigation Bar implementation we won't be using types. All NavigationItem records will represent an item in the Navigation Bar that can be clicked upon to initiate an action.

We do however have one special type of NavigationItem record which we call the Dashboard record

Dealing with Dashboards

We always assign a value of "0" for the sort field on this special record, and this is how we identify the dashboard record from all other NavigationItem records. This is because our Dashboard navigation will always be the left-most button in our navigation bar - no exceptions.

The other difference between this record and other NavigationItem records is that on this record the only other field value we need provide is that of id_dashboard. As mentioned earlier this is a foreign key to a dashboard record. We are effectively telling the NavigationSet what the default dashboard screen will be for this navigation bar.

The key here is default. The Dashboard is able to be changed on any given navigation bar when initialised based on whatever criteria you wish. Some systems assign dashboards to specific users, while others assign based on the role a user might be undertaking.

We want our navigation to be flexible such that we can easily change what happens when this left-most button to access the dashboard is clicked.

How do we define Dashboards?

A dashboard record is just a NavigationItem record whose type field value is equal to "dashboard". They have no direct relationship to any specific NavigationSet.

You create one record for each different dashboard in your solution. These are configured in the same way as a normal NavigationItem record where you specify:

A name
A target layout
A script to run either immediately, or after layout navigation if a target was specified.

You don't need to define a sort order for these records - when they are linked up to a NavigationSet they'll always have a sort order of 0.

Assigning Dashboards to Navigation Sets

Recall earlier we created a special NavigationItem record in each NavigationSet to act as the dashboard position with a sort order of 0.

We said that each item only needs to be related to a dashboard record. Now that we have set up a number of dashboard records as shown above, we can now set the id_dashboard field value our dashboard NavigationItems records.

Setting up your Sets NavigationItems

Next step is to configure your regular NavigationItem records in your Navigation Set. These are set up in a very similar way to the NavigationItems we saw in part one for our portal based navigation.

One difference here from part one is that our target will be a layout name instead of layout object name. We also have introduced an Alternative layout name as an option. This is such that we can hold a modifier key while pressing a button in our Navigation Bar to access a secondary layout. It is useful where you may have both a form and list view version of a screen and wish for a quick and simple way for a user to choose which of the two varieties they want to navigate to.

Lastly we have an option to run a script as part of the button click. You can either use this on its own or in conjunction with a specified layout. If you specify both then the script will run after the layout is navigated to.

Building a JSON Representation of a Navigation Set

At this point if you're following along we should have the following records defined in order to build a Navigation Bar:

At least one NavigationSet record
At least one Dashboard NavigationItem record.
A special dashboard NavigationItem record for our NavigationSet (sort order 0) which is linked to a Dashboard NavigationItem record.
One or more additional NavigationItem records associated with the NavigationSet.

With all this information we have everything we need to now construct a JSON representation of a NavigationSet.

The JSON object will contain the following:

The ID of the NavigationSet
An array of NavigationItem objects, ordered by how they are to appear in the Navigation Bar (sort order).

Here is an example of a basic navigation Set with a dashboard and 2 screens:

The JSON is constructed using a script called "NAV: Initialise". This script is responsible for taking a NavigationSet record as its parameter and constructing the JSON representation.

Now, we won't go into fine detail about each line of code in this script because you'll find it well commented in our example file to dissect, however let's give a high level overview of what it does...

1. Determine Navigation Bar

While a NavigationSet id can be passed to this script, if the user does not specify one then there are some fall-backs. The first is trying to use the value in the global variable $$USER_NAVIGATION_ID.

Now, this is purely an arbitrary name and depends on your own solution, but effectively think of this as a NavigationSet that has been assigned to the logged in user. This can sometimes be done on startup of a solution or when a user defines their role, or some other criteria.

Whatever the case may be, it may transpire users have their own Navigation Bars, and in our example that ID gets stored in this global variable.

Now, failing there being one, the script will do a second fall-back to look for the system default Navigation Set. If no default has been defined, then we are unable to proceed.

2. Obtain NavigationItem data.

We next run an ExecuteSQL query to obtain the required information from each NavigationItem record associated with the NavigationSet. We then separate the left-most (dashboard) entry from the rest (regular items).

3. Determine Dashboard to use.

We handle the dashboard item differently because within this item is the id_dashboard value which we now need to look up to obtain the required information from this Dashboard NavigationItem.

There is also a part in the script here where you have the ability to determine a user-specific overriding dashboard. Remember we're dealing up to this point with the default Dashboard for the Navigation Set. However in your own implementation you may wish to define dashboards at the user level meaning dashboard records are actually assigned to individual users. If this is the case then this part of the script is where you would check if the user has a specified dashboard, and override the dashboard record to use with the user specified one.

We again run an executeSQL query to now obtain the required information from the chosen Dashboard NavigationItem.

4. Build the JSON

The last part is pretty simple, we now just construct the JSON and build the array of items. The first position in the array is always for that of the dashboard, with the remainder of the items going into the subsequent array positions.

Loading a Navigation Bar using a Set

The actual loading is a piece of cake and is a single line of code. We simply set the resulting JSON into the $$USER_NAVIGATION_DATA global variable. Everything else is now handled by the Navigation Bar object, and the script that runs when an item is clicked.

To change the navigation bar for a user, just simply re-run the Nav:Initialise script, passing it the id of a new NavigationSet.

The Navigation Bar Object

The Navigation Bar as previously mentioned is a button bar object. Each element is soft-coded based on the JSON in $$USER_NAVIGATION_DATA.

Taking an initial look we can learn the following:

First item is always called "Home" - it's hard coded.
Item names are defined via calculation
The number of possible items in the horizontal navigation bar is predefined to be 8
We have a special 9th item labelled "More…" - more on this later!

Firstly let's look at the calculation for each regular item in the nav bar:

@NAV_Get ( "name" ; 1 )

This is a custom function which we use in our implementation to help obscure some of the more lengthy calculations and simply allow us to query our JSON for a specific value based on item index. In this case we're asking for the name value for the item at array position 1. This is what we use to show the name of the second item in the navigation bar (remember arrays in JSON begin at index 0).

Each item has an action assigned which will run the Nav:Select script. This script accepts the following parameter:

JSONSetElement ( "" ; "target_number" ; 1 ; JSONNumber )

Which is just a JSON object containing the index of the item.

Highlighting the Current Navigation Item

We want to use the active button bar state to indicate which layout the user is currently on. To do this we first give each segment an object name containing its index, e.g.:

nav_0 (dashboard)
nav_1
nav_2
... and so on.

Next, we define the active segment to be:

"nav_" & @NAV_Get ( "Position" ; "" )

You'll see we have again utilised our custom function, but this time we are passing it a special parameter "position". We are requesting the function to tell us at which position in the list of items our current layout name resides. The function will check each navigation Item for both its primary layout and alternate layout name, returning the first index position in the array it finds.

In the example pictured above, if we were on the highlighted layout then this custom function call would return "2" and thus the active segment object name would be "nav_2".

The Nav:Select Script

Again there is nothing really technical here. This script accepts as parameter an index position. It then looks up our JSON objects array of Navigation Items for the corresponding position, from which it can then obtain the layout name, alternate layout name and script. It then is responsible for carrying out the correct navigation and execution of a nominated script.

Showing More Items in the Bar

Unlike portal based navigation that can be scrolled, we do not have that luxury with a horizontal Navigation Bar. Now, to be honest if you are building Navigation Bars where you want to employ horizontal scrolling then you're doing it wrong - you have too many items in your nav bar and need to rethink your solutions Navigation.

However being the hypocrites we are, we added into our Navigation Bar object the means to allow a small number of additional screens that will open in a vertical popover if there are more than can be displayed horizontally.

Here you'll see the last item in the bar is a special item labelled "More…" which is a popover, containing further Navigation Bar items. These additional items are basically set up in the same way as the horizontal items.

In our solution setup we first define a special global variable $$SOLUTION_NAV_SIZE. This is set to a number which is how many actual items we can display horizontally. In the case of our example file this number is 8 (we exclude the "more" segment).

In situations where our Navigation Bar has 8 or less items we will hide this "More…" popover, and simply show our 8 regular segments.

However if we have over 8 items in the Navigation Bar then we hide the last regular segment and instead replace it with the "More…" popover. Thus the last segment in the Navigation Bar will always either be the last normal item or the "More…" popover.

Inside the popover our segments will begin at position 8. This is because in order to show the "More…" popover, we hid the 8th segment in the horizontal view, and so we now require it to be the staring segment in the vertical view.

Because you cannot use the same layout object name twice, these vertical object names are suffixed with "_alt" to differentiate them from their horizontal counterparts. We just make a small adjustment to the active segment calculation here to accommodate.

Example File

As always we have crafted an example file to help you follow along with the article and so you can explore and implement this in your own solutions.

Click here to download the example file.

Navigate the DF Way - Layout Sections

Tue, 03 May 2022 07:59:00 +1200

Introduction

At Digital Fusion we have spent years implementing solutions using all manner of navigational techniques.

Over that time we have refined and settled on our own methods for managing navigation within a solution - be it solution-wide, within a layout, or within within parts of a layout.

In this and upcoming articles we will share some of these techniques and frameworks, beginning with a simple framework used for layout section navigation.

This portal-based approach allows us to produce a vertical navigation control that lets the user navigate to a nominated tab control, or panel control.

We use it in situations where a tab control would simply have too many tabs to be a usable means of navigation, or where other controls such as button bars would just end up with far too many segments.

our example file

What is a Layout Section?

Simply put, a section is a specific tab control section or panel section within their respective objects. A common layout structure we have is to create a hidden sliding panel object and make it the size of the content area of a layout. Each panel will contain a different set of fields or functionality for that layout.

In fact this is no different than simply putting a tab control/panel on a layout and using their built in navigational controls. What we are doing instead is hiding those controls and building our own portal based control to navigate them.

You may have come across other approaches such as using a button bar control to handle tab/panel navigation. While being a perfectly reasonable approach, it does suffer a few setbacks:

No icon customisation - they must be hard-coded into the bar.
The active button bar state must be handled & refreshed - this can be very annoying.
Hiding disabled items in the bar will result in the other segments becoming wider - can be jarring for a user and can make the UI look really bad.
Styling of button bars is a total PITA!

Based on these factors and our own desire to make a far more dynamic and reusable control that can cater to larger navigational structures we opted instead for a portal approach.

Note however that this does not mean other approaches are invalid - it all depends on your scenario. We still use tab controls all the time because they are perfect for smaller layout section navigation. Our portal approach is for times when a tab is not the best suited control for the job.

layout sections identified - it's a panel!

Taking a Portal Based Approach

By building a navigation control using a portal, each item in our navigation control is a record in a table. We call this the NavigationItems table (more on this later).

With this approach our records can be setup to contain any number of different properties to aid us in navigation and display such as:

A type (header, separator, navigation item etc).
An icon (either singular or one for selected vs non-selected).
A display name.
Target object on the layout to navigate to.
The name of a script to run post (or pre) navigation.
A prefix for the display name, e.g. bullet point.
Indenting of the display name using tabs.
... and whatever else you can think up.

The portal can then have a script run from within such that depending on the row you select the script can obtain the relevant information needed to navigate, and do so.

The NavigationItems Table

The underlying table that our Navigation control is based on is the NavigationItems table. As mentioned above it contains a number of useful bits of information such as display name, target object, a script to run, an icon and so forth. Two key pieces of information in this table are the type and item_type fields.

Think of the type field as a way to identify similar records belonging to a single navigation control. For example if you have two controls in your solution - one for the setup screen and another for contacts screen - then your records will have values of "setup" and "contacts" for this type field.

The other important field is item_type. This helps us categorise records into one of three sub-types.

The Three Types of Items

The three subtypes of records defined by the item_types field are:

header
separator
item

Header records act as titles for other items and are a way to help group similar items in the navigation. They can also be styled to appear different to navigation items.

Separators are usually blank records that act as separators between groupings of items. You don't necessarily have to have them as blank either - through putting objects in the portal and hiding them on rows that aren't separators, you can define any style of separator you want.

The last type is "item" and these are the actual clickable navigation items which will have a name, target object, and potentially a script to run.

The three navigation item types

Setting up your Navigation Items

Next it's time to create and configure your navigationItem records. This part is simple, just assign them all the same type, categorise them based on item_type, and then fill in all the other required fields.

Headers will at the very least require a display name, while separators require no additional information.

Items will require a name, target object, and possible post-script to run. In addition to this you can specify an icon, a prefix text, and some indentation if required.

One other important field in the setup is the order field. For simplicity sake all our records are sorted based on this numerical order. Make sure you set the correct order for which you want all your navigationItem records to appear in the control.

Information being set into NavigationItems

Building the Navigation Object

Right, now it's time to actually add a portal to the layout for this control.

First you'll need a relationship to the NavigationItems table from your layout context. This could be a relationship to all records where you will make use of Portal-Level filtering to restrict records to just those of a particular type. Alternatively you could program the type predicate into the relationship so you only find those specific records via your relationship. For simplicity sake we use portal filtering as our NavigationItems table often doesn't have many records,and so portal filtering performance issues are negligible.

With the relationship established, add the portal to the layout and add into it your display name field.

Make sure to sort the portal by the order field.

In addition to any display fields added, there are two additional objects that are important to add to the portal:

a button to run the navigation script.
a rectangle fill to act as a highlight to indicate the selected section.

For the button we want to only show this on the rows where item_type = "item", which we achieve through a hide conditions.

The highlight should only be shown on the row which is the selected row which is also done using a hide condition - more on this later.

Formatting Portal Rows

There are many ways to display your navigation control. You have control over how you format the items, the headers, separators etc.

Usually we would make use of layout styles and apply these to objects in the portal. We do this for the hover and navigation button.

For the display name we would usually also use styles but in the interests of simplicity for the example file conditional formatting has been utilised to format headers differently. To do this with styles we would have the display name field added twice into the portal - one styled for items and one for headers - and hide the relevant objects based on the item_type of that record.

Utilising styles allows you to achieve a system-wide consistency of design with your navigation controls.

the display field, button, and hover fill all highlighted.

Scripting of Navigation

We have a single script that carries out navigation to a desired layout section. This script accepts a JSON block as a parameter.

This JSON block contains information about the selected record, such as its id, name, type, item_type, target, and script name.

The information within the JSON is parsed out and used to navigate and run any required script.

In addition to carrying out the navigation, the JSON is then stored in a global variable so that we track what the currently selected item is. This selected item is how we determine back in the portal which row should be highlighted.

Storing of the selected item is done using a global variable. This global variable is dynamically generated in the script and it's name is constructed using the type of the navigation control being interacted with.

For example if you are selecting an item for the "contacts" navigation control, then the global variable name will be $$NAV.CONTACTS.

However it's not quite that simple! FileMaker is great at allowing users to create multiple windows - each with their own contexts, found sets, and states (such as selected tab or panel). For this reason, we need to actually track the selected item at the window level, meaning if a user had 5 windows open then we need to know what the selected section is for each of those five windows!

Turns out there's a rather nice and simple way to address this issue. We take the window name (which we assume to be unique) and turn it into an MD5 hash number using the following formula:

GetAsNumber ( GetContainerAttribute ( Get ( WindowName ) ; "MD5" ) )

Think of this as a way to map a text string - the window name - into a numerical equivalent. We then use this number as the repetition number of the global variable to store that windows state in - easy!

Storing the windows selected item in a Global Variable repetition

Specifying an Initial/Default Item

Standard layout section objects such as tab controls and sliding panels all have a default section. For tabs you can nominate it, and for panels it is the first panel. When the user first enters the layout, the default tab/panel is chosen.

Because we are overriding this behaviour with our own navigation control, we need a way to define what our controls default section should be. There are three potential candidates:

The first "item" record in our control based on order.
A predefined item
The last selected item if there is one.

All three are viable options and which option you choose depends upon your use case. In our example file and in our own solutions we have opted for the first option of just selecting the top-most item from the control, regardless of whether one was previously selected.

You can find this achieved in our example files navigation script. In a situation where the user is not actively determining the selected item - such as entering a layout - then we pass through just the type to the navigation script as JSON:

JSONSetElement ( "" ; "type" ; "contacts" ; JSONString )

The script detects that no item was selected when we only have a type passed, and will instead run an executeSQL query to retrieve the first record whose item_type is "item'. It will then select it and navigate to it in the usual manner.

Querying for the first item in the navigation control

Taking it Further…

This is just scratching the surface of what you could achieve with this simple framework. At the end of the day all we are doing here is showing records in a portal - something any developer can understand - and with a few extra bits of information to help navigate, we are using these as a means to navigate to a panel control - nothing complicated here at all.

Which is why there are so many ways you could build upon this to do more, such as:

A solution-wide navigation system where layouts are navigated to rather than layout sections
Building accordion style controls using more complex filtering
Different item_types for things such as popovers, scripts etc.
Or more!

In fact we're going to talk about taking this further and utilising NavigationItems for other purposes in future articles...

Coming Soon…

In this article we've covered a way in which we achieve navigation within a layout using a portal based navigation control. We do this because often layouts (such as a preferences screen) may have a large number of sections where a standard tab control may not work. However there are other forms of navigation that a solution needs.

One such control is a navigation bar that helps the user navigate to all the main screens in a solution. At Digital Fusion we call this the navigation bar and we favour a horizontal bar across the top of layouts.

In the next article in this series we talk about how we build this navigation bar to be completely contextless and able to be pasted and work on any layout. Not surprisingly we are utilising the NavigationItems table for this too - albeit with a couple more fields. We'll cover howe we handle situations where navigation bars might require a large number of screens, how we customise the look and feel, and how we manage dashboards - a situation where multiple users may actually require different dashboard screens. Finally we'll show how we can build multiple sets of navigation bars, and assign these to users based on their role or any other factor. It's a powerful control that gives a simple means to implement a custom navigation bar for your users.

Example File

All my articles come with an example file (which is where about 90% of my time goes when preparing articles these days!) I highly encourage you to check it out as you'll find everything in there to help you get started building your own navigation controls.

Click to download the example file here!

Easy to Generate Debugging Reports

Thu, 14 Apr 2022 09:39:00 +1200

Introduction

How many times do users let you know of a bug in their solution and yet are unable to provide any detail about what they were doing at the time? What layout were they on? What was the found count? Were any plugins installed? What record were they on?

These are very common questions the developer may ask and yet not receive a good answer to.

So how do we find the answers?

Well sometimes good users can provide us with the answers but more often than not they simply aren't paying attention to the state of the solution at the time a bug occurs - which is fair enough. As a developer maybe we can just build some tools to provide us with the answers the user cannot.

We did just that by building a debugging report script that will collate information into a JSON object that the developer can then do with whatever they please.

It combines three useful sets of data in JSON format:

All field values from the users current record (or any nominated record)
Results of every Get function
Any other developer specified data which may be of use (e.g. globals, variables, session state..)

This is a single script that can be initiated from anywhere. The JSON is returned as the script result.

Getting record values

To get all record values, one might use the Execute FileMaker data API script step, combined with a pre-build layout in order to return this information, but who has time to manage layouts! We wanted a way to do this all within a script and so we utilise FileMakers internal SQL tables FileMaker_Tables and FileMaker_Fields to give us all the information we need.

Andrew Duncan from Databuzz has an awesome article on these tables which I refer back to constantly, I strongly encourage you to check out his article here.

In fact we actually featured this technique in our top 5 of 2021 article just recently - check out that article for more detail here!

In short, the process for obtaining the record data is as follows:

Obtain a reference to the records primary key field
Extract the table occurrence name, and field name
Use the FileMaker_Fields table to obtain every field name, class and type from that table
Loop through the field data, excluding items you do not wish to debug
Build a query to obtain just the field values you do wish to debug
Loop through the results, generating JSON

This is clearly documented and laid out in the script in the example file.

Getting Get Values

The Get functions (e.g. Get ( FoundCount )) are invaluable in the information they can provide the developer about the state the solution was in when an issue occurred for the user. Some of the more useful functions include:

Layout Name
Window Mode
Installed Plugins
Found count
Record lock states
Window Names
and more..

They are very quick to calculate and so why pick and choose - just evaluate the whole lot!

The script stores a list of every get function in a variable. We then simply loop through, and build up JSON using ithe function name as the key. The value is simply determined by running the function through the Evaluate function - so simple!

Getting other data

Get values, and record values are all fine and good but often the important information about the users session is kept in things such as global variables and fields. Structures that help store information about the user and what they are doing. For example some systems maintain session information in a table, and so it would be useful to know the ID of that session record. Others maintain a user table and so knowing the user ID could be beneficial. Other things too such as the users current position in a wizard, or tab in a layout can be logged providing that information is being tracked by the developer.

Our debugging script has a section just for this type of information and given the custom nature of the data, needs to be set up by the developer for each specific solution it is used in.

Putting it all together

Our debug report script takes two parameters:

A reference to the primary key field (for record value collection)
A type of data to collate - record, function, other (or all/blank for everything)

JSON is simply outputted from the script.

That's obviously not the end of the story. It's then up to the developer to make use of the reports and obtain them. One option may be to email the developer the report, another might be to store the report within the solution in a debug table. Our preference is both of these! We both store the reports and email them to the developer each time one is submitted. Often times the debug report is a prompt to follow up with the user about the issue more.

In our example file we opt for the storage mechanism only to illustrate how it can work - you kind of get the idea about what would happen with email!

The Benefits

This tool has already paid for itself for the time it took to develop. It has been used at least a dozen times and every time has really helped narrow down circumstances around a bug and has helped me as a developer replicate the same conditions the user would have experienced at the time.

Example File

No FileMaker Weetbicks article is complete without an example file and so here it is - click here to download the example file!

Solving Circular References in Auto Enter Calculations

Thu, 31 Mar 2022 10:11:00 +1300

Introduction

In this article we're going to talk about circular references - what they are and how they can happen in FileMaker solutions, specifically with two Auto-Enter Calculation fields. We'll cover what actually happens in this situation in regards to the order of Auto-Enter execution and why this does not work with a typical use case.

Often when a circular reference occurs, the developer is actually trying to achieve something that should in theory be possible, and so we'll talk about this situation and offer a solution that will provide some really useful outcomes.

In order to help make all this much clearer, let's jump right in and talk a bit about what a circular reference actually is...

Example file time!

As always we include an example file (packed with info and explanation). We recommend downloading and trying it out for yourself while you read.

Click here to download the example file!

What is a Circular Reference?

In programming, a circular reference is defined as a situation in which two values reference each other. This situation has the potential to be rather problematic if two functions or values depend on another for definition.

In FileMaker, circular references can occur in the Auto-Enter calculation definition of fields. A scenario can arise where two calculations are dependent upon one another.

When this happens, FileMaker evaluates them in such a way that the resulting value for both fields is neither one that is desirable or usable.

Below is an example of two Auto-Enter calculation fields that reference one another. The outcome the developer is trying to achieve is that when the value of one field is 1 the other field should be 0 and vice versa.

What happens in Auto-Enters?

As mentioned, the outcome of circular referencing in FileMaker is one you may not expect and this is due to the order in which FileMaker evaluates both Auto-Enter Calculations.

Taking our example from before, let's see what the order of execution looks like:

The value in field1 is modified by the user.
The Auto-Enter for field2 is triggered, which immediately triggers the Auto-Enter for field1.
The Auto-Enter for field1 is evaluated, and it's current value is overwritten with the result.
Now the Auto-Enter for field2 finally evaluates.

It's confusing for sure and is best illustrated with an example

An example of the issue

Again we have 2 fields we wish to toggle the values in between 1 and 0.

Let's start by changing the value in field1 from blank to "1":

Value of field1 is set to "1" by the user.
Auto-Enter for field2 triggered, and immediately triggers the Auto-Enter in field1.
Auto-Enter for field1 evaluates (not "" = 1) and value is set to "1".
Auto-Enter for field2 evaluates (not 1) and value set to "0".

While upon initial inspection it may look like we got the intended result, let's now try setting field1 to 0. We would hope that field2 is set to 1:

value of field1 is set to "0" by the user.
Auto-Enter for field2 triggered, and immediately triggers the Auto-Enter in field1.
Auto-Enter for field1 evaluates (not 0 = 1) and value remains at "1".
Auto-Enter for field2 evaluates (not 1 = 0) and value remains at "0".

Hmm, that's not quite what we want is it? In fact, once the first values are defined in these fields, they cannot be changed thereafter because the Auto-Enter firing on field1 prevents this by overwriting the new value the user just entered.

What do we actually want?

So that sucks for sure - but can we bend the laws of FileMaker into our favour to provide a beneficial outcome? Turns out we can!

First let's look at what as a developer we might actually want that outcome to look like:

If the value in field1 is modified by the user, then evaluate the Auto-Enter of field2 ONLY.
If the value in field2 is modified by the user, then evaluate the Auto-Enter of field1 ONLY.

The key here is ONLY. We want the fields to reference one another but to not result in a circular reference by way of only one of the Auto-Enter calculations being evaluated - dependent upon the field being actively modified.

Can we do this? Yes we can!

A proposed solution example

Going back to our earlier example, here is what the new behaviour will be.

Let's start by changing the value in field1 from blank to "1":

Value of field1 set to "1" by user.
Auto-Enter for field2 triggered and evaluated (not 1 = 0) and value set to "0".

Now change the value in field2 from 0 to 1:

Value of field2 set to "1" by user.
Auto-Enter for field1 triggered and evaluated (not 1 = 0) and value set to "0".

The @AE_switch custom function

The solution is achieved through creating a Custom Function (to make life easier) called @AE_switch. Now, the code is obviously the most interesting part but let's establish what information is passed to the function first to help set the scene:

@AE_switch ( _f1 ; _f2 ; _self ; _expressionTrigger ; _expressionSelf )

The parameters are:

_f1: A reference to the first field in the circular reference.
_f2: A reference to the second field in the circular reference.
_self: A reference to the current field this function is defined in.
_expressionTrigger: An expression to evaluate upon this field being triggered by the other field.
_expressionSelf: An expression to evaluate upon this field being triggered by itself changing.

A couple of important things to note:

The references to _f1 and _f2 can just be direct references (not hard-coded). However it's important that in both Auto-Enter calculations where you define this function that the fields you define for _f1 and _f2 remain consistent.
_self is simply a reference to the function "self".

Another interesting thing is the usage of _expressionSelf. This is actually optional, but what this allows you to do is define an expression to evaluate upon the field being triggered by the user. This occurs before the Auto-Enter calculation on the other field is executed. Think of this is a way you can still pre-format a fields value, such as ensuring it is a positive number, or filtering out certain unwanted characters.

If you don't wish to use an _expressionSelf then just set this to Self.

How it works

Right so we're finally getting to the good stuff. We want to control the order of execution of Auto-Enter calculations and we do this through two special local variables. Firstly let's take a look at the function code (you can scroll the code sideways..)

Let ( [
  ~self = GetFieldName ( _self ) ;
  ~me = Case ( ~self = GetFieldName ( _f1 ) ; 1 ; ~self = GetFieldName ( _f2 ) ; 2 ; "" )
] ;
  Case (
    IsEmpty ( ~me ) ; _expressionTrigger ;
    ~me = 1 ; If ( $AE_switch2 ; _expressionTrigger & Let ( $AE_switch2 = "" ; "" ) ; Let ( $AE_switch1 = True ; _expressionSelf ) ) ;
    ~me = 2 ; If ( $AE_switch1 ; _expressionTrigger & Let ( $AE_switch1 = "" ; "" ) ; Let ( $AE_switch2 = True ; _expressionSelf ) ) ; 
    ""
  )
)

Note that this function is called in the Auto-Enter calculations of two fields.

We start by getting the field names of the two fields, and then compare them to the name of the field that this current function is defined in.

This tells us the context in which the current function is being evaluated (field1 or field2).

If for any reason the field is not one of the two defined to be in the circular reference (unlikely) then we just run the expression passed. Think of this as a fallback.

However almost certainly the field will be either that defined in _f1 or _f2.

We use two switch variables called $AE_switch1 and $AE_switch2. When a switch variable is enabled, it is telling both Auto-Enter calculations which field is currently actively being evaluated, and thus suppresses the other field from evaluating its expression at that particular time.

For example if $AE_switch1 is enabled, this means that the user modified _f1. In this case we only wish _f1 to evaluate its defined _expressionSelf.

When _f2 is triggered, it sees that $AE_switch1 is enabled, thus it knows the user modified _f1 first, and so it is to evaluate its defined _expressionTrigger.

Again, these types of things are best illustrated with an example...

An Example

Let's return to our toggle example, but this we'll define each fields Auto-Enter calculations as follows:

for field1:

@AE_switch ( field1 ; field2 ; Self ; not field2 ; If ( Self < 0 ; 0 ; Min ( Self ; 1 ) ) )

and for field2:

@AE_switch ( field1 ; field2 ; Self ; not field1 ; If ( Self < 0 ; 0 ; Min ( Self ; 1 ) ) )

The only thing different in both definitions is the value of _expressionTrigger which is actually our initial calculation definitions.

You'll note an interesting expression for _expressionSelf. This is an expression to pre-format a number entered such that it set to 0 for values less than 0, and 1 for values greater than 1.

Putting it all together now, let's change the value of field1 to 5:

field1 changed to 5 by user.
Auto-Enter for field2 triggered, and immediately triggers the Auto-Enter in field1.
Auto-Enter of field1 evaluates:

Case ~me = 1 (Yes):
If $AE_switch2 on? (No):
Turn $AE_switch1 on, and evaluate _expressionSelf: Min ( 5 ; 1 ) = 1.

Value of field1 is set to 1.
Auto-Enter of field2 evaluates:

Case ~me = 2 (Yes):
If $AE_switch1 on? (Yes):
Turn $AE_switch1 off, and evaluate _expressionTrigger: not 1 = 0.

Value of field2 is set to 0.

Finally how about setting the value of field2 to -1000?

field2 changed to -1000 by user.
Auto-Enter for field1 triggered, and immediately triggers the Auto-Enter in field2.
Auto-Enter of field2 evaluates:

Case ~me = 2 (Yes):
If $AE_switch1 on? (No):
Turn $AE_switch2 on, and evaluate _expressionSelf: Self < 0, so result = 0.

Value of field2 is set to 0.
Auto-Enter of field1 evaluates:

Case ~me = 1 (Yes):
If $AE_switch2 on? (Yes):
Turn $AE_switch2 off, and evaluate _expressionTrigger: not 0 = 1.

Value of field1 is set to 1.

Brilliant! We have now hijacked the normal circular reference execution in order to achieve our desired outcome!

Other Uses

This technique was originally borne out of the challenge of solving this circular reference issue. We have however utilised this in real world solutions for things other than toggles.

The most common scenario is one where events are being entered. An event generally has a start and finish date. We can calculate the duration of an event based on subtracting the start date from the finish date.

But what if the user wants to provide ability to specify either duration or finish date? Here we have a circular reference:

End date is Auto-Entered based on Start Date + Duration
Duration is Auto-Entered based on Finish Date - Start Date.

Both End Date and Duration reference each other. We however only wish for one to Auto-Enter when the other is changed by the user.

We can apply our function very easily to this scenario to allow a user to specify an event either by duration, or by a finish date.

Furthermore, we can use the _expressionSelf parameter to ensure both duration and finish date are safely entered with valid values before proceeding.

Conclusion

We hope you enjoyed this article and learned something about the weird nature of Auto-Enter calculations and circular references. Once you understand how a circular reference is executed, the solution becomes apparent that we need to control execution through some control variables otherwise we can never achieve a desired outcome.

For a while now I've been writing design based articles but I really enjoyed getting back into some more technical stuff. If you like this article and wish to see more technical oriented content in future please let me know

Example File

Please have a look at our example file if not already. This has everything you need to implement the @AE_switch custom function as well as a large amount of background info and explanation (which you can also find int his article).

Click here to download the example file!

A Clever CSS Chat Display.

Tue, 22 Mar 2022 08:13:00 +1300

Introduction

In this article we're going to take a look at a very simple approach to displaying an internal chat conversation in FileMaker. The premise is simple - we have a series of messages that need displaying and we want it to look like your standard messaging app (think Messenger, Slack or WhatsApp).

The underlying chat framework is all FileMaker, this is purely an exercise in display, and trying to make it as simple as possible to implement for developers.

What's the Issue?

If we just want to display messages - which are themselves records in a table - then you may think "why not just use a portal, or list view". Well there are a couple of reasons why these are not that suitable.

The first is a question of size. We have no way of knowing how large a chat message will be and thus how big to make a field that needs to display it. FileMaker portals have to be of a fixed height, and so while we can simulate a messaging display, the crucial thing we cannot do is dynamically determine a portal rows height.

Similarly with list-view, unless we are viewing a chat in preview mode (not very useful) then we cannot dynamically determine size of a row.

Why Not Javascript?

In searching for a suitable way to solve this issue, we obviously approached Javascript given its reputation as being a problem solver for things that cannot be solved with out of the box FileMaker tools.

Javascript does offer a number of chat implementations however these are primarily focussed on website chat, such as end user / customer interaction. They also focus heavily on the communication protocol and delve into the need to set up web servers, listeners etc - all well beyond the scope of our requirement.

Wait, set up what now?

Example File

This is a good time to mention that as always we include an example file for this article. It pays to check it out as it will help make sense of what we discuss below, as well as showing you what we're implementing.

Click here to download the Example File.

HTML to the Rescue!

The question was asked - why not just build a display using some basic HTML and CSS? If we could generate some HTML code - styled with CSS - then perhaps that's all we need. That is exactly what we did!

Consider a <div> tag. W3 Schools defines a <div> tag as:

The <div> tag defines a division or a section in an HTML document.

The <div> tag is used as a container for HTML elements - which is styled with CSS or manipulated with JavaScript.

The <div> tag is easily styled by using the class or id attribute.

All we need to do is generate a <div> tag for each message and have it render within. We can then also use CSS to style the contents of that div however we choose.

What a simple <div> tag looks like.

And CSS to the Rescue!

As mentioned, the real power here is in the CSS. With CSS we can apply virtually any kind of formatting to the contents inside our <div> tag. In this case we're going to format it to look like a chat bubble.

Consider a standard chat display. There is a left side (message sent by you, the person viewing the chat), and a right side (message sent by everyone else).

We also want to display in this way, and so what we need is 2 different styles - one to format a message on the left hand side, and one to format a message on the right hand side.

Example: A Basic Chat framework

In order to talk through how we build our HTML, let's first consider a very basic chat framework. This has been implemented in our example file just enough to show a chat conversation being displayed.

The basic structure is:

Chat: 1 record per chat (in our example we restrict it to 1 record)
ChatMessages: 1 record per individual message sent for a given chat.
Users: This has 1 record per user of your solution. Note some solutions don't have a User table, in which case you can just use your FileMaker account names as a substitute.
ChatUsers: Defines who is participating in the chat. 1 record per user (or account) per chat. This is simply a join table between Users and Chat.

So pretty straightforward. With the above framework there is potential to have multiple different chats going on in your solution, involving different people for different purposes.

Formatting a Message Display

First we're going to focus on the ChatMessages table because this is where we need to take our message and turn it into some HTML code for viewing.

In this table you'll find a field called message_json. This is a JSON representation of the chat message for display. It contains 2 pieces of information:

The first is "owner". The owner of a message is a unique identifier of who created it. If you are using the framework above, then this is going to be the ChatUser ID of the person who created the message.

The second value "message" is a reference to a custom function called @CHAT_messageFormat. We have abstracted the code into a custom function because it is easier to digest, and reusable.

This function takes 3 parameters:

_owner: in this case it is a display name for the owner, such as user name or account name.
_message: The actual chat message.
_timestamp: A timestamp of when the message was created.

Now, this function is purely for constructing some HTML in whatever format you desire. In our case we have utilised another custom function @DATE_format (which we love!) to make our timestamp into a nicer format.

The HTML part comprises of a single <div> and two <p> tags. In our <p> tags we place the message along with the owner & timestamp.

You will note that our second line with the owner & timestamp is assigned a class owner. This is so we can use CSS to style this line separately by defining a class of the same name.

Our main <div> actually has two classes defined for it:

chat-message
chat-message-[SIDE]

The first class is for general formatting of the message, things like font, sizes etc. The second is for positioning a message either left/right, and for colouring accordingly. Note that [SIDE] is actually a placeholder that we are going to replace when the time comes with either the word "left" or "right".

So in actuality there are two classes for this called chat-message-left and chat-message-right.

Styling the Message

If we take a look at the CSS, it's pretty easy to follow and see how messages are formatted. We won't go into the technicalities of CSS, suffice to say you'll find it easy to locate the above classes and make formatting changes. The key classes defined are:

.chat-container .chat-message: Padding and font properties of a message box
.chat-container .chat-message p: Formatting of the main message content
.chat-container .chat-message p.owner: Formatting of the second line of owner name & timestamp
.chat-container .chat-message-left/right: Coloring of the left/right hand message box accordingly.

There are others but we won't get into these but you can't go wrong having a play and seeing what they do.

Constructing the HTML

Okay so now we have a bunch of messages with a representation in HTML. We now need to generate the overall HTML to be rendered in the web viewer which will comprise multiple <div> tags - 1 per message.

This is simply an exercise of finding our set of messages and looping through them to build up the HTML.

To make this as simple as possible, we'll take our JSON payload from earlier, and collate a list of these which we feed to a special custom function @CHAT_buildMessages.

It is important to collate the jSON from your records in chronological order because the order in which we build is the order in which they will be displayed.

Our custom function takes 2 parameters:

_owner: the unique identifier representing who is currently viewing the chat
_messageList: A return delimited list of JSON objects, one per message.

We use a simple While function to loop through each JSON message. From within each message we check the value of the "owner" key, and compare this to the "owner" passed through in the function parameter. This tells us whether the message belongs to the owner and thus should be formatted with the left class, or whether we instead format it with the right class.

The End Result

Put it all together and you get something this:

Here you can see that Daniel is selected as the owner, and thus all of Daniels messages are displayed on the left side. If we switch perspective instead to Cath, we now see all her messages on the left.

The main content of the HTML looks like this:

<body  = 'footer'">
<div class="chat-container chat-push">
<div class="chat-message chat-message-right">
<p><span style="" >Hi all. Just wanted to let you all know that we will be heading out for lunch on Friday next week</span></p>
<p class="owner">Daniel Sun 27/2/22 10:20 am</p>
</div>
<div class="chat-message chat-message-left">
<p><span style="" >Cool, can't wait!</span></p>
<p class="owner">Cath Sun 27/2/22 10:25 am</p>
</div>
<div class="chat-message chat-message-right">
<p><span style="" >????</span></p>
<p class="owner">James Sun 27/2/22 10:39 am</p>
</div>
<div class="chat-message chat-message-right">
<p><span style="" >I can't make it sorry, thanks for the invite though.</span></p>
<p class="owner">Mary Sun 27/2/22 10:45 am</p>
</div>
<div class="chat-message chat-message-right">
<p><span style="" >All good Mary, thanks for letting me know.</span></p>
<p class="owner">Daniel Sun 27/2/22 2:49 pm</p>
</div>
<div class="chat-message chat-message-left">
<p><span style="" >Hey Daniel, will there be vegetarian options available?</span></p>
<p class="owner">Cath Mon 28/2/22 8:58 am</p>
</div>
<div class="chat-message chat-message-right">
<p><span style="" >Yes they cater to vegetarians and vegans. There is a menu online, I'll email you further details</span></p>
<p class="owner">Daniel Mon 28/2/22 9:05 am</p>
</div>
<div class="chat-message chat-message-left">
<p><span style="" >Thanks!</span></p>
<p class="owner">Cath Mon 28/2/22 10:41 am</p>
</div>
<div class="chat-message chat-message-right">
<p><span style="" >I'm off for a run</span></p>
<p class="owner">James Mon 28/2/22 12:30 pm</p>
</div>
</div>
</body>

Nothing more than a series of <div> tags, with the appropriate style applied - so simple!

Taking it Further

Now, this is meant to illustrate a very basic approach to a chat display and we think we achieved this satisfactorily. However there are some things to consider:

This is not live. You need to refresh the entire chat if a message is added
Given the entire message is refreshed, incredibly long chats might take longer to build

The intention of this is for relatively small chats within a solution, that aren't "live" chats. However we see potential to extend this in a number of ways, one of which is actually utilising Javascript to dynamically add <div> tags to the HTML when a message is received. We could utilise the Javascript functionality in FileMaker 19 to push new messages to a web viewer, or have the chat be entirely loaded by javascript functions.

We'd love to see what you'd come up with!

Other cool potential things that could be done with this include:

Adding an avatar image to the display for a user
Customising message colors per user
Clickable links in messages that run scripts, or open URLs
Hover states on messages

W3 Schools has an example of an Avatar chat display

Example File

Here again is a download link to our example file. We hope you find it useful:

Click here to download the example file

A Cooler Color Picker

Fri, 11 Mar 2022 06:42:00 +1300

Introduction

Allowing a user to easily select a color in your FileMaker solution is hugely beneficial. Often times we need a user to pick a color for something such as a status, a way to identify a record, or a color for a chart.

We want to provide a simple approach for the user in which they can visually select a color instead of entering it as hexadecimal or RGB values.

Currently in the FileMaker world there are 2 approaches, both of which utilise a web viewer. One is to use HTML5 to use the native OS color picker and the other is to use a javascript based color picker library.

The native OS picker is visually very nice. Its major benefit is that it is not limited to the confines of the web viewer, and so the web viewer object itself merely acts as a color swatch displaying the selected color. You can find examples of an OS color picker approach in my elemental_ux solution.

However one of the big drawbacks I see with the OS picker is its cross-platform differences. You will get a different experience on a Mac versus on Windows. The picker also doesn't work at all on FileMaker Go, and is flaky on WebDirect.

For these reasons we went with a javascript based approach.

Example File

Example files sit at the core of all our articles and much time and love goes into them, not only to present a particular technique but also as a way for us to help refine the technique. We always encourage you to download and try out the example file for yourself as the best way to read and understand the article is by having the example file open at the same time and exploring both.

Click here to download the Color Picker example file

The Javascript Approach

By using a javascript based color picker we achieve the following benefits:

Cross-platform consistency - it works the same on all platforms.
Additional configuration options - you have more control over the pickers setup, look and feel.
Simple reusable code
Utilises FileMaker.PerformScript javascript call to pass color back to FileMaker.

In looking for a suitable javascript library for a color picker our main requirement was that the picker be large enough in size to be presentable in a card window as well as a popover. We also wanted it to be simple to implement and customisable for developers.

We went with the Pickr library which you can find here.

Two different implementations

We mentioned before the requirement to have the picker work in both a card window and a popover. The reason for this is that web viewers do not work when placed inside a portal and so if you wanted to select a color from within one you would need to find an approach where the color was selected outside of the portal.

We found building a simple card window layout containing the web viewer for the color picker was ideal. When a color needs to be selected, the picker is invoked, a color is chosen, and the card closes. Upon closing the requested field is populated with the chosen color (more on how this works later).

We still wanted to offer an approach where the color picker is able to placed within an existing layout for times when a color is chosen outside of a portal. For this approach we utilise a popover. This allows you to have multiple pickers on the same layout.

The Card Window Approach

The card window picker can be utilised anywhere by any button, to set any field. The basic workflow is as follows:

The user has a field to set a color into - let's call this Home::color
The user invokes the ColorPicker_Open script, passing it the name of the field to be set, and the type of picker being used "card".
The card window opens, and the color picker is rendered in the web viewer
The user makes their choice of color and presses "save" (or alternatively presses "clear" to remove the color, or cancel to discard selection)
The javascript calls the ColorPicker_Set script, passing it the chosen color
The ColorPicker_Set script will tidy up and close the picker, and then set the Home::color field.

We pass the parameters through to the open script in JSON format, and they look like this:

There really is nothing overly complicated here, it's about as basic a Javascript/FM integration as you can get!

In addition to the open and set scripts, there is a third script ColorPicker_Close which is responsible for the tidy-up of the picker after a selection is made. More on this later for the geeks who like to know the technicalities!

The Popover Approach

The popover approach is almost identical to the card approach however instead of explicitly calling the ColorPicker_Open script, we instead set it as the OnObjectEnter trigger for the popover. Similarly the onObjectExit trigger for the popover is set to the ColorPicker_Close script.

These two scripts will initialise the picker in the popover, and tidy-up and close the picker when done.

The parameters passed to the open script are the same with one exception. For popovers we also pass through the name of the web viewer object that is in this particular popover. Because you can have more than one popover picker on a layout, we need to differentiate between them.

Managing Many Pickers

We are potentially dealing with multiple color pickers here, and each picker needs to be aware of the field that it needs to set when a selection is made.

We saw 2 ways to achieve this - one would be to pass it through to the javascript code and store it there. The other is to store the field to set within FileMaker in global variables. We went with the latter approach because while not as elegant, it allowed us to illustrate some cool techniques for this article! (We will likely change it to store it within each web viewer as this is much nicer.)

Anyways, let's delve into what's going on here. This is for the FM geeks who like the nitty gritty.

We can have multiple pickers in a few ways:

Multiple windows, each with a card window picker open
Multiple windows, each with a popover picker open
Multiple popovers on a layout (albeit one open at any given time).

When a picker opens, we need to know the field that needs to be set with a color, and we need to store this field name so that when the time comes we can retrieve it for setting. We also need to tidy up after ourselves and clear this variable when complete.

The Open Script

The open script kicks things off by gathering the passed parameters, and loading the html javascript and css code into the web viewer - all stock standard stuff.

When it comes to storing the field name to be set, we want to associate that field name to this specific card picker instance. We do this by assigning the card a unique window name, using Get ( UUID ). We then define a variable called $ident to store this value.

In the case of a popover, because only one popover can be active on any given layout at any given time, our $identifier value just needs to represent the current window name. For this, we assign a value to $ident of

"colorpicker_" & Get ( WindowName )

Right, so we now have a variable that is a unique identifier of the specific card picker, or popover picker being instantiated. This will be different for situations where multiple windows are open - each with their own active picker.

Next, we take this value, and hash it into an MD5 hash. This returns us a large numerical string. We do this as follows:

GetAsNumber ( GetContainerAttribute ( $ident ; "MD5") )

We are utilising a container function on a text string which can give us an MD5 hash of that text.

The final step is to take this number, and treat it as a repetition value for a global variable. Into this repetition we set our field name for the color field to be set:

Set Variable [ $$COLORPICKER.FIELD[$hash] ; Value: Home::Color ]

The beauty of this technique is you can effectively take a string, and turn it into a repetition into which you can place a value. You can then easily regenerate that same hash number later to retrieve and clear this repetition.

The Close and Set Scripts

Now that we know how this part works, setting the field to the chosen color, and clearing the global variable value when done is easy. We simply regenerate our hash by evaluating the window name, and retrieve or clear the variable as needed. The Set Field by Name step is used to set the color into the chosen field.

Displaying your Chosen Color

So we have a color chosen - in this case hexadecimal. So what? What good is a hexadecimal color as a text string, if we can't actually turn it into a physical color? Fortunately we can and it's really easy!

There is a neat little trick you can use to generate a 1x1 pixel gif image of a chosen hexadecimal color. This is done by producing it as base64 encoded text, which is then decoded back into a gif file for rendering in a container. The code is as follows and we have wrapped it up into a custom function called @COLOR_swatch in the example file:

If ( IsEmpty ( _hex ) ; "" ; HexDecode ( "47494638376101000100910000000000" & Substitute ( _hex ; "#" ; "" ) & "FFFFFF00000021F90409000003002C00000000010001000002024C01003B" ; "red.gif" ) )

By calculating/inserting this result into a container, you can create a color swatch of any size. Just set your container properties to "Reduce or Enlarge Image to Fit" and remove the option to Maintain Original proportions.

Taking things further with Customisation

We decided on a simple implementation of Pickr for our Color Picker, but the reality is Pickr is quite powerful and you can produce some cool pickers simply by altering the configuration parameters in the javascript setup.

If you wish to investigate this further, the documentation will provide you with all necessary configuration options.

You can find this code in the example file in the ColorPicker_Open script. Here are just a few examples of what you can do:

3 Different varieties of picker - Classic (what we use), Monolith and Nano
Show/Hide predefined swatches for quick selection
Determine primary color mode (Hex, RGB etc)
Show preview of currently selected color
Enable/Disable ability to select transparency
Relabel buttons
Restyle elements via CSS
Bind events to almost any action, allowing you to run Javascript or FileMaker scripts when events occur.

and more.

In Conclusion

Pickr is by far the simplest and best javascript based pickr we have come across, and implementing it was really easy. We hope that we have done a good enough job that you can take the example file and easily incorporate the picker into your own solutions and improve upon what we have done.

We'd love to see folks take this and improve upon it by optimising how the picker manages the storage of the field it is required to set the color into - perhaps storing it in the Javascript? If anyone would like to take up the challenge we'd love to see what you come up with.

Even if you don't use the picker, consider the technique for generating color swatches, this is a really powerful and awesome function. You'll also find on briandunning.com a number of custom functions that can convert an RGB value into a hexadecimal value which would allow you to utilise this swatch technique with the standard FileMaker RGB function.

Example File

Click here to download the Color Picker example file

Why Upgrade?

Wed, 09 Mar 2022 13:49:00 +1300

We've been building custom FileMaker solutions for 26 years now. As you’d expect, we’ve seen a lot of versions come and go in that time. Claris continuously invest in and enhance the platform which keeps it not just current and viable, but leading the way as a low-code, rapid development platform.

That said though, it’s incredibly stable and we’ve seen plenty of our clients running their apps for decades on the same version we worked on with them.

Recently we’ve had some discussions with a client who was still running their solution on FileMaker 16 and we advised them to upgrade to the latest version (FileMaker 19 as of writing). But why? I mean their solution was working fine, stable and everyone was happy. Why rock the boat? They hadn’t had any issues and in fact we hadn’t heard from them for some time…

Let’s explore some pros and cons of upgrading and why we think it’s a good idea, even if your FileMaker application is working “fine”:

Either by choice or omission, it’s easy to understand why you might not keep up-to-date with the latest FileMaker versions:

If it ain't broke, Don't fix it - As I mentioned, FileMaker is inherently stable and we’ve seen solutions we built decades ago ticking along, quietly doing their thing.
New License Costs - If you’ve got a perpetual (permanent) license then you’ll be looking at an upgrade or if it’s more than a couple of versions old, purchasing anew. And these days most lisenses are now annual (albeit lower than the older perptual licenses). But if it’s working why would you want this cost?
Cost of Upgrading - It takes time to upgrade a server, and it means that every user’s software will need to be updated too.
Plugins and Other Dependencies - Updating the FileMaker software — or in fact your hardware or Operating System — may break these, particularly older plugins. That could mean work and/or cost finding updated versions or replacing them in some form if they’re no longer supported.
Logistics and Disruption - It can require some planning and coordination to ensure a smooth transition for your team. Users may need to upgrade their own FileMaker Pro versions and this can occasionally require support. There may be some downtime as the upgrade is performed.
Hardware, Operating System and Compatibility - Depending on how old things are, it may be necessary to upgrade some users’ machines or business hardware and software to support the upgrade and keep everything working.

We Get It

Nobody wants to "burn money", but...

We would argue that those factors are all positive in the short term, and sooner or later they will catch up with you because you’ll be forced to upgrade for compatibility. And along the way you’re missing out on some important benefits.

1 Device Support - Currently, Claris offer support for the latest two versions of FileMaker (19 and 18). This means we have access to their technical teams for any issues associated with the platform itself and they actively invest in keeping these versions current and compatible with the prevailing operating systems and devices.

2 Protection from Hacking - Claris rank Security as the number one priority for the platform and have taken some major steps in recent years to make FileMaker much more secure. With hacking and data breaches a common target, and now that most FileMaker databases are on the cloud or exposed to the internet, it is vital to stay right on top of the security measures Claris are putting in and constantly updating to the latest standards.

A good example here is the recent Log4J and Heartbleed type vulnerabilities. These were serious deficits that malicious actors or code could exploit to basically hijack a business’s systems. Patches were available quickly once they were exposed but only for currently supported operating systems. Out of date, un-updated and unsupported older systems are basically left exposed.

3 Avoid Incompatibility with Windows or macOS - by staying current with FileMaker you’ll be able to stay up to date with your Windows, Mac or iOS systems, which means not only getting all the advantages of new features they bring but also the all important security of those. Apple and Microsoft address weakness in their platforms every month, but only the most recent versions. Plus if you get new gear it will come with the latest OS whether you like it or not.

4 Avoid Costly Support Issues - the older your gear the more risk you have that something like a hard drive might fail and you’ll be unable to quickly get the system back up and running. If something does fail you may be forced to update everything at once just to get everything working again. This could well happen at a time not of your choosing and may take longer to sort out than it would if it was planned and managed. We have seen some situations like this take days to resolve as each unplanned replacement and upgrade forced other changes throughout the business. The costs of resolving these unplanned outages can be much higher than a managed upgrade. See the comment below from Paul Hutton, one of our developers on the front line of this kind of issue.*

5 Faster, Stronger, Better - FileMaker 19 (the current version as of writing) is faster, more stable and easier for us to support and work on. In short, it’s better for users and also for us as developers. That means our work supporting you is more efficient. Also, within the latest version is an important tranche of new updating technology which means from this version on we can update and upgrade much faster and easier, with less disruption. The grass is greener on the FM 19 side and that means its even less costly to maintain currency of your systems once you get up to this version.

6 The Longer You Leave It, The Worse It Gets - there is a term in the IT industry called “technical debt” which refers to the future cost you incur as a result of short term cost saving measures such as shortcuts in code, lack of equipment maintenance and lack of software updates.

Consider that the more out of date your system versions are, the more careful planning, testing and steps we have to take to bring you back to currency. It’s actually much more complicated to bring you up from say FileMaker 12 than FileMaker 17 for example. We basically need to implement a program of leapfrogging through versions and may or may not need to perform file conversions along the way. This costs more, will probably incur longer disruptions and could involve more issues such as functional incompatibilities (if for example your solution is using deprecated functions or script steps from older versions).

Final Thoughts

“I’m seeing this quite a bit with a certain group of clients: old machines, old FM Pro, old FM Server. Then a staff member gets a new machine and it goes like this: they can’t install old FM Pro because it’s incompatible, so they install the newest version, but then the new FM Pro doesn’t work an old server version, so they call us to update server, now all the other users have to update FM Pro, and it’s all done in a rush, without planning, usually with some loss of access and loss of productivity. Worst case they have a mix of machines that can’t all handle the update and end up with some people unable to access the system until their computers are updated!

Better to schedule the upgrade, do it in a planned and measured way.”

— Paul Hutton, Senior Developer, 20 Years!

Why Build Custom Software?

Tue, 22 Feb 2022 00:00:00 +1300

There are many reasons why some organisations and businesses really benefit from building their own custom operational software…

Here's one. I think it's interesting and if you’re considering your business software options this is definitely worth exploring.

One of our clients runs an educational accommodation facility, sort of like a hotel for teaching and research groups. They have a commercial kitchen used to feed large groups of people at a time, sometimes multiple groups over many days. They have catering companies on contracts to do this and the contracts come up every few years and sometimes change hands.

Things Change

They've recently got a contract with a new catering firm and decided to dramatically change the way they quote, invoice and book catering for clients.

They asked us to make changes in the system to make this work.

Luckily we had designed the system to be fairly flexible and also... it's built with FileMaker. With the flexibility of this platform, and being a custom solution built solely for them, it took us around two days to make the changes once we got cracking.

As soon as we deployed it we asked for their latest prices on catering as that was the final piece of the puzzle to make it work for them.

And Change…

At this point, the manager called and said, "Actually, the bosses in our organisation have decided to make another change and we won't be doing catering quotes, invoicing or booking like that at all any more.”

Lucky for them they have a system that rolls with those punches and doesn’t cost 10's or 100's of thousands of dollars every time they reinvent the wheel, which they do all the time all over the place.

Flexibility

Commercial Off The Shelf (COTS) software and products including SaaS options are an excellent choice in many firms but may not be especially flexible or responsive when your needs change.

Whereas, low code software platforms such as Claris FileMaker can offer a huge degree of agility and responsiveness without being monstrously expensive or time consuming to implement.

The big takeaway from this type of story is that it’s important to think about the decision making and operational environment when assessing software options for your business. Are you fluid and dynamic? Do your processes change and respond to the market? Will you need flexibility?

There may well also be external forces at play: Are there other departments, clients, suppliers or governmental compliance causes that could impose changes on you next year (or even next week)? How quickly do you need to adapt and accommodate?

There’s more to the ‘cost’ of your software choices than the immediate bottom line. Make sure you consider any potential for changes in the way you work as you’re exploring your software options.

Best of 2021: Idle Record Release

Thu, 23 Dec 2021 09:13:00 +1300

When Users Hold Records

The last of my 2021 Best Ofs is a couple of scripts to help with those pesky users who leave records uncommitted and then bugger off for a coffee or take a long lunch break. Super annoying for other users and for you as a developer if you wish to make a field definition change on a production version — hey, it happens, deal with it!

We facilitate the commit of an iDLE user through an OnTimer installed for each individual user. The OnTimer is running a script that will monitor the users active field (if there is one) and determine if they are idle in that field.

This is done by storing information about the users last active field in a global variable repetition. We use different repetitions for multiple windows the user may have open to track states of multiple windows.

Information we capture about the users field include:

Active field name
Active field contents
Record Modification Count
Record Open Count
Record Open State

All of this information is stored in the variable. If the next time the OnTimer runs none of this information has changed then the record is committed.

For example we might wish to set our onTimer to 30 seconds. By doing so will allow a user to sit idle in a field making no modifications for no more than 30 seconds. If they are typing in the field then the stored information will differ from the previous time it was run and so the user is free to continue without the threat of a commit happening.

The technique uses a script to enable the idle release timer, one to disable, and one to carry out the commit.

The enable script allows you to define your own terms for when the IDLE release process is to be installed. This is useful because as a developer having this OnTimer run can be painful as it will jump the developer out of active script steps you may be writing in. So we disable this for full access users. There is also little need to run this if executing on server. Certain windows are only spawned for temporary purposes such as carrying out actions in a script. In this case you may wish to not use idle release for these types of windows.

Example File Download

Best of 2021: PSOS Helper

Thu, 16 Dec 2021 11:30:00 +1300

Introduction

When developing and maintaining client solutions a really common task is to write a script to either add, modify or delete data for the user. This is usually a time consuming batch style operation that is often faster to run on the server rather than the client.

To run a script on FileMaker Server you have the option of either setting up a scheduled script via the admin console, or running it using the Perform Script on Server (PSOS) script step.

The latter option is the fastest option when needing to quickly run a one-off script.

The Catch…

There's always a catch. To run a script on server via PSOS, you first need to run a local script that can itself run the Perform Script on Server step to call your server-side script – what a drama!

For a long time I used a piece of code that I would always write out at the top of these scripts to achieve this:

Technically speaking there is nothing wrong with this code, I just got tired of writing this all the time. I wanted to abstract this out to a single reusable script. One that could be placed at the top of any other script to force that script to run on the server.

A Better, Reusable Option

This is what I came up with:

Here we are passing the name of the script to execute on server as a parameter.

This helper script will terminate if already running on server (to prevent repeat recursive PSOS calls).

If it is being initiated by the client, it will perform script on server by name, using the name passed as a parameter.

The halt is to terminate the script that initiated the call. The initiating script is actually the one that is going to be run on server, so we don't need to also continue to run it on client.

Thus, in order to run a script on server, it just requires the below step as its first script step. The rest of the script can be written as if it is to be run on server.

A single step at the top of any script to have it run on server.

Synchronous Execution

The PSOS helper is really optimised here to be run for one-off scripts. It is Asynchronous in that it does not wait for the currently running script.

To run this as part of a solution where certain scripts are run PSOS, then first thing you'll need to do is remove the Halt script step on line 23. This will allow further execution of other scripts to occur. If you wish this to be Synchronous, then change the PSOS call on line 22 to wait for completion. Usually a PSOS that waits for completion expects to get a result back, so in order to achieve this you can exit here and return Get ( ScriptResult ).

Example File

As always an example is included. This file doesn't really do much other than contain some. further information around the script, as well as the helper script itself so that you can put it in your own solutions.

Download the Example File

Best of 2021: Keystroke Tester

Fri, 10 Dec 2021 11:16:00 +1300

Keystroke Tester

Less a piece of code and more of a utility (and could easily be made into a FileMaker Add-on). I built this keystroke tester for our own internal frameworks to help developers quickly and easily derive modifier key numbers as well as codes for various keystrokes pressed.

This is invaluable as a time saver when needing to work with the various keystroke triggers.

The tester opens in a card window and will respond to your keystrokes or modifier keys pressed, providing you with real time feedback:

The keystroke tester will likely feature in a future elemental release as an Add-on, but if anyone would like to build this as an Add-on sooner feel free to do so and let us know in the comments here.

Download the example file

Best of 2021: Get Record as JSON

Mon, 29 Nov 2021 10:16:00 +1300

Get Record as JSON

This is my personal favourite in this "Best of 2021" series — I guess that makes it the Best Of The Best! This is a really simple and reusable script for obtaining an entire record represented in JSON format.

I built this initially for a debugging tool used in a client solution (see an upcoming article for this). The user could press a button to submit a debug report to the developer. Part of that debug report is a JSON representation of the record they are currently viewing. This was really useful in helping to diagnose issues because I was able to see all field values at the time of the issue.

As usual I've prepared a sample file to show you how this works which you can download here.

Download Get Record As JSON example

The JSON is built using 2 key features. The first is using FileMaker's underlying internal SQL functions to obtain a list of all fields within a desired table. Using this list of fields it becomes rather easy to then formulate an executeSQL query to return all these field values from a nominated record.

This script needs a single parameter which is a reference to the primary key field of the record you wish to return a JSON representation of. We use the GetFieldName function to achieve this.

From this single reference the script can derive the table occurrence name. Using the underlying FileMaker_Tables table, an executeSQL query can obtain the base table name. Using this, we can then query the FileMaker_Fields table to obtain a list of all the fields within this table.

Finally we can formulate a query to get all fields values from the desired record in that table by using the known primary key name, and value (obtained through the Evaluate function).

This is easiest to be seen just by looking at the script yourself in the example file.

You may wonder why we don't just obtain "*" from the table to get all field values, in favour of explicitly asking for every field by name. The reason for this lies in the fact the FileMaker_Fields internal table allows us to also obtain information such as field type, and storage type (e.g. calculation, stored, global).

This is useful because it allows you in the script to set some criteria as to what types of fields you wish to return for your JSON representation. You may wish for example to omit summary fields, unstored calculations, global fields, containers etc.

This loop to extract certain fields has been left in the script and is well commented but for the sake for the example I have left every field included.

NOTE: Because the field values are obtained through an executeSQL query this technique does not cater for repeating fields or container fields. A container field will return the file name but not the field contents per se; repeating fields will return the first repetition value only. You can always represent a container by create a calculation for it which is the base64 encoded representation.

Example File

What FileMaker Weetbicks article wouldn't be complete without an example file? In this you'll find everything discussed in the article. I think the best way to learn is to jump in and explore.

Click here to download the example file

We love feedback so please leave a comment if you have anything to say - even if you don't it would be nice to hear from you :)

Best of 2021: Multi-Row Portal Selection

Thu, 18 Nov 2021 09:34:00 +1300

This is a great UI technique I use all the time when I wish for a user to be able to select multiple rows from a portal. Rather than laboriously single-clicking rows it is much more intuitive to give the user an operating system like experience for file selection. By this I mean the use of modifier keys to select multiple rows:

Single-click for single row selection only
Cmd / Ctrl click for arbitrary multiple row selections
Shift-click for selecting a nominated range of rows.

Further to the above, functionality can be extended through the use of buttons (or my preference of custom menus) to carry out select all/no rows.

To start with, grab my example file here so you can follow along and explore the technique for yourself.

What you'll see in the demo is a portal like this in which selecting rows by Shift-clicking or Command-clicking lets you create an ad hoc selection of items from the list:

In the picture above we have a simple portal with 3 rows selected. The primary key values of the selected rows are stored in a field/variable of your choosing for use however you see fit.

This is achieved with the following components:

A portal of records (obviously!)
A script run from within the portal context
A field to store the selected Primary Keys
A secondary helper field to store the last selected Primary Key
A custom function to help identify the pressed modifier keys (in english)
A field on the child table to obtain the found count of portal rows.

The last item on this list is purely for the script to know how many records it is dealing with for certain scenarios. The easiest way to achieve this is through an unstored calculation on the table set to the Get ( FoundCount ) function. For more on this technique refer to my earlier article here.

The script accepts the following parameters in JSON:

id - The id the user has selected.
force - 1 if you wish to force selection of the id, rather than toggle it.
all - 1 if you wish to select every portal row.
clear - 1 if you wish to clear every portal row.

The script has been mostly abstracted, there are just 4 components to set up as shown below (These could very easily just be added as script parameters as well if you wish making the script 100% abstracted for use throughout your solution).

We simply need to specify, in the script, the fields for storing selected ids, the last selected id, the portal primary key, and a field to tell us how many records there are.

The script takes care of the rest and handles the various modifier key situations.

NOTE: This technique only works right now for portals that do not use portal-level filtering and sorting – it is for relationship level sorting and filtering only. This is because our script does not do any recursive looping through portal rows to achieve selection (something that would be required if portal level filtering/sorting were to be used).

Example File

What FileMaker Weetbicks article wouldn't be complete without an example file? In this you'll find everything discussed in the article. I think the best way to learn is to jump in and explore.

Click here to download the example file

We love feedback so please leave a comment if you have anything to say - even if you don't it would be nice to hear from you :)

Weetbicks Best Of 2021

Thu, 18 Nov 2021 09:34:00 +1300

Intro

I’ve been a FileMaker developer now for 15 years. In that time I have come up with some really cool stuff - a lot of which I’ve shared here over the years and can be found in the older articles. But as time goes on it gets harder and harder to come up with unique stuff, especially with the community so strong and thriving with awesome developers. Gone are the days where the opportunity to push FileMaker to new limits was quite within reach (Javascript/APIs excluded!).

With that said I still do things from time-to-time that make me sit back and think "hey that's pretty cool". They may not be flashy, ground breaking or overly complex, but they solve the problem at hand and end up becoming staples in my development toolkit.

So without further ado I'd like to share with you several of these from the year-to-date, starting with:

Multi-Row Portal Selection

There are plenty more in the old toolkit but these are the ones that I have used with much success in the solutions I develop.

I hope you enjoy
- Daniel (aka Weetbicks)

DF Con 2021

Mon, 01 Nov 2021 15:57:00 +1300

Some say the way to a man’s heart is through his stomach, well the way to a FileMaker Developer's heart is locking them in a room for a couple of days so they can over indulge in all things technical.

So it began, for 2021, Digital Fusion decided we would hold our own conference. As we grow in size, with a team of 18 now, we thought we could go it alone, and create our own content, events and social gatherings.

Trans-Tasman Limitations

Planning for the event took a bit of a turn for the worse when the Australia and New Zealand borders were slammed shut with outbreaks of Covid in NSW. The intention was to get our Aussie team over to Christchurch so we could all be in one place, something that has been hard to achieve since the pandemic took hold.

We swapped our dates from August to October and started planning, even getting flights booked from Brisbane to Christchurch. Sadly, the border remained closed, so we swiftly moved to Plan B, organising a conference where we'd remote-in three of our team.

A Resort Close To Home

October came around, and we all headed out to the beautiful Clearwater Resort on the outskirts of Christchurch. We were blessed with some stunning weather, which helped enhance what is a stunning location — think lakes, golf courses and swanky accommodation.

Kicking things off on Wednesday afternoon, we went straight into the keynote presentation by our illustrious CEO, Craig Saunders. This was kept short and sweet as his main speaking spot was the following day, and he didn’t want to let too many cats out of the bag.

Team Building Stuff

We then moved onto learning a little about ourselves and those around us! We brought in Ramon Utting to take us through Clifton Strengths which is a world-renown way of understanding your "strengths" or motivators. If you have never heard or read about this, in essence the process finds key words that describe you, and then learn how these words fit into you as a person and how they affect your interactions with others. More importantly perhaps, you gain insight into others motivators and what they mean.

As you can imagine, with 16 developers/technical folk, we have a lot of very similar traits throughout our team. That said, we learned a lot about how we fit together as a wider group, and through understanding ourselves a bit beter, gained insight into how we interact with clients and others outside DF.

Wednesday evening was a mixture of pizza and quizzes. The ever wonderful Jo and her trusty sidekick Greig, had setup a great quiz, asking questions about Digital Fusion, FileMaker and us as individuals. The victor on the evening was Daniel, followed by Steve and Paul H. Lots of fun was had by all.

View from Clearwater, Christchurch

View from our Australian team

Content Day

Thursday was "D-Day" and we certainly had a full one planned, made up mostly of presentations by our team. This is not always easy, speaking in front of your peers, but without exception they all did a stellar job and the feedback was extremely positive. Here's how the programme stacked up:

Sessions – Morning

Sessions – Afternoon

Guest Stars

We were also graced by Joel Katz and John Matthews from Claris, who joined us to take us through and update on whats happening in their world.

Wrapping Up In Style

Following a long day in the conference room, we retreated to celebrating a great event and an awesome team. We brought in a company called The Cocktail People to show us all how to make some splendid drinks. To our surprise, we were all asked to make a couple of our own, which had differing levels of skills. Let’s just say none of our team would be cast in the remake of Cocktail.

And that was a wrap, a wonderful two days spent together as a team. We are not sure if this will be a one off, Claris Engage might be back to face-to-face in the US next year... both formats are incredibly valuable so perhaps we'll be able to do both in the future?

Powerful Pivot Table Presetting

Thu, 30 Sep 2021 21:59:00 +1300

Introduction

When it comes to reporting in FileMaker, there are a few options available to developers

Visual reports, using sub-summary parts, table view etc
Exporting data
Charting (ugh!)
Tableau Connector

While it may seem like there is a plethora of options, with the exception of Tableau all these other methods require the developer to have a fair amount of input in producing a desired report output for the end user. FileMaker does not have very good end-user level tools available to help construct your own reports and interrogate your own data.

Sure, you can open up table view to your users and let them add sub-summary parts and summary fields, but do you really want them to do this? Do you want them to add new fields? Do you want to be restricted to making sure your field names are nice and friendly in order for export fields to make sense?

No? Neither do I. There must be a better solution. One where we can give the user far greater control over constructing their own meaningful reports and obtaining useful information about the data in their solutions.

This is where Pivot Tables come in.

What is a Pivot Table?

Microsoft gives the following succinct definition of a pivot table:

A PivotTable is a powerful tool to calculate, summarize, and analyze data that lets you see comparisons, patterns, and trends in your data.

To me, a pivot table is very much like a chart, but rather than a visual summarization of an X and Y axis, they are instead a table-based summarization of a row and column.

Consider this example...

Let's say our solution has invoices. Invoices are for customers, and are for selling products.

What kind of useful information might someone want to learn from their invoices that could help make better business decisions?

Well, one such thing could be how much each customer has been invoiced for each type of product. This could help the business know which products are popular with which customers.

In FileMaker, we could provide this information as a sub-summary report. However these reports are restricted to vertical display. Layout parts are vertically stacked and so while we could produce these using simple sub-summary parts and summary fields, we might end up with pages of data to display this information.

Pivot tables on the other hand are just that - tables - and display this same information in a tabular format using rows and columns:

The information presented above is much cleaner to read.

Using PivotTable.js

So we're going to use a pivot table in FileMaker, exciting times! For this we choose PivotTable.js because it is open source, highly flexible and easy to use (and has been previously integrated as we'll see below).

PivotTable.js is loaded with cool features that you get right out of the box, some which come to mind are:

Multiple fields defined for rows and columns, think of this as akin to live sub-summary part groupings
Filtering of rows and columns to specific values
Sorting rows and columns
Over a dozen ways to visualise your data, from tables, heatmaps, charts and exports!
Multiple aggregators (like summary fields) - show counts, sums, averages, std deviations, max/min and more!

There are so many more cool things but these should give you a good idea of what to expect.

How NOT to Reinvent the Wheel!

Now, we're not the first to talk about PivotTable.js by any stretch of the imagination, this has been well covered before, with great articles and demo files which we ourselves have utilised for this article.

The main one is a great article from that javascript wizard Jeremy Brown. You can check it out here. In it he goes into more detail about the integration of PivotTable.js and provides a really cool demo file too. We encourage you to check this out, as it will help you get up to speed with integration - something we aren't going to cover here, as our integration is based on Jeremy's.

PivotTable.js has also been featured in Carafe.FM as an add-on which you can check out here.

So What's Missing?

We used PivotTable.js in our solutions and our clients loved it. But there was something missing. Clients were not able to save the pivots they constructed. Each time they logged back in they would have to rebuild their previous configurations.

Hmm, wouldn't it be great to be able to easily save and load configurations of the Pivot Table so that users can easily recall their favourites. Each construction of a pivot table is really like a report in and of itself. With save capabilities users can basically build their own reports !

And so that is exactly what we did. Turns out it wasn't too difficult. Thanks to FileMaker 19's new web viewer integrations, we can utilise the following two powerful actions:

Perform Javascript in Web Viewer script step
FileMaker.PerformScriptWithOption javascript function

In the following sections we'll see these in action.

Saving Presets

The first step is to get the users current configuration of the pivot table out of the web viewer and stored in FileMaker. We achieve this through a very simple process:

A FileMaker Script calls the getPreset javascript function
This javascript function in turn runs a FileMaker script using the FileMaker.PerformScriptWithOption function and passes it the current configuration as a parameter.
This script in turn sets the configuration into a global variable.
The original script continues to run, and stores that global variable contents into a preset record.

Note that we use the FileMaker.PerfromScriptWithOption rather than the FileMaker.PerformScript function.

in FileMaker 19.0 release, the default behaviour was to run the initiated script after any currently running scripts are finished.

Instead what we want is to have the script run immediately, returning it's configuration data for use in the earlier script, in order to be saved as a preset. To do this, we make use of the new FileMaker.PerformScriptWithOption call which allows you to specify how the currently running script is handled when the new script is run.

You can learn about these options here in this Claris Article. We want to use option "5" which is suspend & resume, meaning the initiating script is suspended, the new script run, and then the initial script is resumed - exactly the same as if you were running a sub script.

So that's the FileMaker side of the equation, we just need to write a javascript function to return the current config. This is really easy. in PivotTable.js there is a variable "currentConfig" that contains just that. We simply return this to FileMaker as shown below:

var currentConfig;

function getPreset(parameters) {

FileMaker.PerformScriptWithOption ( "PIVOT: Get Preset", JSON.stringify ( currentConfig ) , "5" ) ;

};

Loading Presets

Loading a preset is basically the reverse. We have the preset code stored in FileMaker and we want to pass this into the web viewer and have PivotTable.js load it in for us.

This is done by calling a second javascript function - updatePreset - and passing it the configuration code.

This function will in turn parse the JSON configuration sent to it, and load it into PivotTable.js

function updatePreset(config) {

let configjs = JSON.parse(config);

configjs.onRefresh = function(config) {

//delete some values which will not serialize to JSON

delete config["aggregators"];

delete config["renderers"];

delete config["rendererOptions"];

delete config["localeStrings"];

currentConfig = config;

};

$("#output").pivotUI($.pivotUtilities.tipsData, configjs, true);

}

If you don't understand how it works, don't worry - you don't need to. The end result is the ability for end users to save their own presets!

FileMaker.PerformScriptWithOption

Just a quick note on the usage of FileMaker.PerformScriptWithOption for the saving of presets. We use Option 5 of suspend/resume. This was only introduced in version 19.1.2 and above, so those of you still on an original release version of 19 will not see this working as expected - you should upgrade to the latest release of 19.

If you choose not to, then you can still achieve saving of presets without issue, you just need to be a little more creative in your scripting. Given the javascript initiated script will be queued to run, you need to have this script carry out the preset saving.

Example File

What FileMaker Weetbicks article wouldn't be complete without an example file? In this you'll find everything discussed in the article, along with a simple pivot table example, and a preset example. You'll also find links to resources we have used to create this file and write this article.

Click here to download the example file

We love feedback so please leave a comment if you have anything to say - even if you don't it would be nice to hear from you :)

Lovely Logos & Pretty Profile Pics

Mon, 30 Aug 2021 22:25:00 +1200

Introduction

Contacts. Almost every FileMaker solution has them. Contacts can be people, companies, suppliers, friends or colleagues, and the list goes on. Almost every Claris FileMaker developer who has been in the game for more than 5 minutes has most likely built a solution that contains contacts.

In terms of database sexiness, contacts can be pretty boring. They usually have a name, phone number, email address, website for starters. Where's the pizzaz, the bounce, the pop?

Contacts can be spiced up by adding a bit of imagery to help represent them. This can come in the form of a company logo, or a profile picture (if our contact is a person).

In fact, a lot of CRM solutions will have the ability to upload a picture of the contact, but let's be honest, how many people actually do this? All too often you see a silhouette where a picture should be.

What can we do about this?

Fortunately we live in the age of the API. A lot of the time API's are thought of as boring text input/output tools: pass an API a request, and get a bunch of JSON data back. But not all API's are so textual. There are hundreds of awesome design based API's out there for image manipulation and retrieval.

We're going to pick a select bunch for this article that specialise in returning either a company logo from a website URL, or a user profile picture using a supplied email address.

Note that for specific code examples and content, we encourage you to download the example file at the end of this article - there you will find everything we discuss in the article and it is completely unlocked for you to explore and learn.

Company Logo Retrieval using Clearbit

For company logo retrieval we use the ClearBit Company Logo API. This is a free API and will return the logo for any website, providing that website has used the Open Graph meta-tags og:image or og:logo as part of their page metadata. ClearBit will cache these images and serve them up super-fast to you via CDN.

Making the API call couldn't be simpler as it is a straightforward get request:

https://logo.clearbit.com/DOMAIN

where DOMAIN is the websites domain name. That's it! You can also specify the size or format you wish to have returned by using some additional parameters, or specify whether you wish the image to be greyscale, e.g.

https://logo.clearbit.com/filemakerhacks.com?size=512&format=png&greyscale=false

Most websites you'll find have this meta-tag provided because it is the image that is used by various social media networks when a post is made linking to that website.

ClearBit also has other APIs that they offer (both free and paid) to retrieve even more information about a company or person using their website URL or email address. If you wanted to supercharge your CRM you could utilise these APIs to attempt to auto-complete a bunch of information about your contacts - how cool would that be!

Profile Picture Retrieval using Gravatar (and others)

Profile pictures of people - while likely far more common than company logos online - are actually a little harder to obtain. You'd think with everybody having profiles in facebook, linkedin, instagram, twitter etc, that these would be easy to get. But these images are largely protected from API's gaining access and unless you know specific profile usernames, they cannot be readily retrieved using information such as an email address.

This is where Gravatar comes in handy. Gravatar is a service created by wordpress where users can sign up for an account and create a globally recognised avatar and profile. These can then be used on sites that support gravatar, without the need for recreating your profile across multiple sites.

While Gravatar is getting more popular, it has not had huge uptake and for that reason it can be a little hit and miss getting a profile picture from it.

Fortunately for us though the Gravatar API is free to use, and so use it we shall.

https://www.gravatar.com/avatar/HASH

This is the basic GET request to obtain a profile picture. HASH is actually the MD5 hash of an email address. We can easily calculate the MD5 hash in Claris FileMaker using the GetContainerAttribute function. Here is how I would get my email address as MD5:

GetContainerAttribute ( Lower ( "daniel@teamdf.com" ) ; "MD5" )

Somewhat odd that we use a container function, but this works fine on text also.

Gravatar can accept size parameters also. It can even generate for you a unique avatar using one of 8 different generators if a profile picture cannot be found.

Gravatar is also able to retrieve profile information for an email address, and we have utilised this in our example file to extract usernames of profiles also as a nice added bonus.

Additional APIs for Retrieval

If Gravatar or ClearBit cannot retrieve the correct image, there is a possibility one of these two other APIs can do it: AvatarAPI and Libravatar.

AvatarAPI queries google profiles to retrieve a profile picture based on email address. It works best with gmail addresses but can work for others if the user has established a google profile using a non-gmail address.

Libravatar is a similar service to Gravatar in that you sign up for an account and add your avatar & profile, which can then be served up to other websites that wish to utilise the service to populate profile information.

Both of these APIs have been integrated into our example as fallbacks in the event Gravatar is unable to successfully retrieve a profile picture.

Removing Backgrounds from Images

Just cos APIs are so cool we thought we would throw in this little gem. Let's say you receive a company logo or profile picture which has an annoying, distracting or otherwise offensive background? Wouldn't it be nice to get rid of that?

Well, there are APIs for that too! In fact there are quite a number of APIs providing this service. Out of all of them, most will cost you per removal (around 1-4 cents on average).

In order to illustrate the removal however we have used in our example file two free APIs - each come with restrictions on using the free service but the point here is to show that this is achievable and what the results can look like.

The two free APIs we have explored are Imagezerow and PixMiller.

The APIs' use machine learning and are pretty darn good at knowing what to remove, as demonstrated by Mini-Weet above. Images are returned with transparent background which is perfect for you to then provide your own desired background colors. (perhaps you could combine this with some techniques in our previous article for background colors!).

Still Can't Find an Image for Your Contact?

Fear not. Just because API's may not be able to locate an actual logo or profile picture, this doesn't mean you need to present the contact with bland text. There are heaps of other Avatar generating APIs out there that can produce a nice unique image for your contacts.

In our elemental_ux solution we have over 20 different avatar generating APIs, all with working examples - you just need to copy/paste the script you want and specify your parameters.

Here at Digital Fusion we utilise avatars along with profile pictures and logos to produce a rich contact experience:

All contacts are generated an avatar via API. We use the UI-Avatars.com API (which can also be found in elemental_ux) to achieve this. In addition we also utilise the above APIs for logo and profile picture retrieval.

Logos and profile pictures can often be inconsistent in their size and ratio and so aren't suitable for display in portals and lists. This is where the consistently sized avatar is perfect.

The logos are used only in a large container space where ratio is not an issue. For years we struggled trying to display logos beside a company name nicely, before biting the bullet and going with avatars instead - and we have never looked back!

Example File

What FileMaker Weetbicks article wouldn't be complete without an example file? All the main APIs featured in this article have been integrated into our example file so you can copy and use in your own solutions. We hope you enjoy it.

Click here to download the example file

We love feedback so please leave a comment if you have anything to say - even if you don't it would be nice to hear from you :)

Prominent Color Coolness

Wed, 18 Aug 2021 23:04:00 +1200

Introduction

In this article we're going to show a simple web viewer based approach to achieve beautiful dynamic background gradients and fills that are based upon an images most prominent colors. Further to this we'll show a way to render those solid fills in a container field. Finally, we'll demonstrate how to choose the optimal color for text that is to be placed on top of these fills for maximum readability.

Note that for specific code examples and content, we encourage you to download the example file at the end of this article.

What Are We Talking About?

If you have used Spotify before, you may nave noticed that album pages contain a nice gradient background behind the album art. This gradient is based upon the prominent colors within the album art itself. It creates a really nice effect and gives each album page it's own sense of personality beyond just the album cover.

Wouldn't it be cool to achieve the same thing in FileMaker? This idea came to me when developing a solution for a company who restores artworks. Their solution had a page displaying a grid of artworks. The various dimensions of artworks created a cluttered and uneven feel. To remedy this I wanted a consistent background, but wanted to ensure that background matched the artwork.

Below you can get a sense of what this achieved by comparing before and after.

JavaScript To The Rescue!

These days most problems in FileMaker can be solved with JavaScript, and this problem was no different. A bit of hunting led me to grade.js, a library which produces a gradient using the 2 most prominent colors in an image.

grade.js will insert a gradient background in a <div> element. It does this using the image specified inside the <div> element, using an <img> element.

Our code takes this further, styling the <div> element fill the entire web page (and thus the web viewer).

An image from a FileMaker container field can be inserted into the <img> element by encoding it as Base64, as shown below:

<img src="data:image/png;base64,**IMAGE**" style="display: none;" />

You'll also note we use a style to hide the image. This is because it's easier for us to overlay the container field in FileMaker than it is to correctly position the image in html.

FileMaker 19 introduced a change to web viewers, allowing them to render underneath other FileMaker objects. Prior to 19, web viewers always rendered in front of all other objects, much to this developers frustration.

The end result is quite awesome.

Returning Color Data To FileMaker

Another neat thing grade.js can do is make available the color data used to generate the gradient. This information can then easily be passed back to FileMaker by utilising the FileMaker.PerformScriptWithOption function call within the javascript.

This information can be parsed to do things like color text, or generate saved solid fills as we'll show later.

Generating Solid Fills

Gradients are pretty, but what if you just want a single solid color? Fortunately there are lots of examples out there on the web of how to do just this. I found one here on jsfiddle.net. Again it's very simple and works almost exactly the same as our gradient example. This code sets the html body background color to the average color in an image element.

Again we base64 encode and inject our image and make it invisible in the page. With some CSS styling we can ensure the background fills the entire web viewer.

This library can also return us RGB information about the background color generated using FileMaker.PerformScriptWithOption.

The Web Viewer Dilemma

Web viewers can do so many cool things, but one thing they cannot do is get placed inside a portal. So far we've shown fills that exist within the web viewer, and as such these are restricted to non-portal implementations. Web viewers also take a brief moment to load, and so there are very small flashes that can be seen while they load.

If we want to show these fills in a portal, then they have to exist outside of a web viewer. In this example we focus specifically achieving this for solid fills.

Rendering RGB As A Fill Color

As we saw in the previous example, our solid fill code can return the numerical values for red, green, and blue. The problem to solve is how to transform this into a visible solid fill in FileMaker, that isn't using the web viewer to render.

Fortunately this problem was solved for us back in 2013 in this great article from Excelisys. When the Base64Encode and Base64Decode functions were introduced to FileMaker, the guys at Excelisys used them to produce a 1x1px bitmap image of a color in a nominated RGB color. This was then used to produce a progress bar that could be dynamically adjusted - all without a web viewer. Cutting edge stuff back then for sure! Progress bars these days can be done in other ways such as button bars, or in web viewers, but the code still has great use.

We have taken the Excelisys progress bar code and instead used it to produce our own 100% filled progress bar of our required color. We can then use this as a background fill to display in portals.

There are a series of custom functions used to achieve this effect, which are available in the example file provided at the end of this article.

The Text Overlay Dilemma

Okay, we have our image our and our fill, but what about displaying text on our background? We want the text to be optimally readable regardless of whether the background is dark or light. So how do we do it?

( ( r * .299 ) + ( g * .587 ) + ( b * .114 ) ) > 186

This is how we do it. This code tells us whether a given color defined by its RGB components is a light image. If the calculation result is greater than 186 then it's a fair bet that the image is of the lighter persuasion and thus the text should be of the dark variety.

Conversely if the number is less than or equal to 186, it's a dark image and so light text is favourable.

In our example file we bundle this up into a custom function that accepts the RGB values as parameters. We return either a light or dark color using the RGB text formatting function.

This result can then be used to color text using the TextColor function.

Taking It Further

What we've shown really is the tip of the iceberg and there are so many more cool libraries out there and code examples that you could utilise in FileMaker. Below are just a few that caught our attention but we have not had time to explore further:

Fast Average Color

A cool library for getting average color of images for background display, with a heap of customisations around background display.

Color Thief

This library can return you a color palette of prominent colors of a provided image. Again, a ton of options possible. Here is one such implementation .

Image Blur

This is a simple nifty CSS hack that produces a background from an image by blurring it beyond recognition.

We encourage you to try these or any others you find and share your results!

Example File

What FileMaker Weetbicks article wouldn't be complete without an example file? The images in this article are from our file and we hope you enjoy it.

Click here to download the example file

How to Remove a Saved Password from FileMaker Go

Fri, 11 Jun 2021 09:52:00 +1200

The Problem is...

Have a database on your iPad with a saved password that automatically logs you in?

Has it been saved to the keychain under someone else's credentials?

Finding how to remove a password from Claris FileMaker Go is not the easiest, so we've put together a step-by-step guide to remove those saved credentials so you log in again with your correct account...

Remove a Password in 6 Easy Steps

1. If you have a file open, close it. Closing files/systems is solution specific, so if you’re not sure, ask your developer. If you can't see your solution open, press and hold the FileMaker Go app button to see open if you have open.

2. Tap on the "Settings" icon toward the top left of the screen. The "Settings" icon only appears on "My Apps" and "Hosts".

3. Tap on "Manage Keychain", you will be prompted for Face ID, Touch ID or your Passcode depending on the type of device you have.

4. Once you have been successfully authenticated, you will see a list of saved passwords for solutions and hosts. Tap on the "Edit" button to edit the list.

5. Tap the "-" icon to the right of the items that you wish to remove. Once you’ve removed the saved passwords, tap the "Done" button.

6. Additional tip - It’s also possible to swipe from right to left on the save password in the list to reveal a delete option.

Hotting Up FileMaker

Tue, 18 May 2021 10:54:00 +1200

For many years, FileMaker was somewhat of a 'closed shop' when it came to extending it’s capabilities. If we ever wanted to do anything "outside the box" (basically cool stuff) we really had to blur the lines of what FileMaker intended. (Which we certainly did with our Reactor plugin!)

However with FileMaker 19 Claris opened up FileMaker with “add ons” and JavaScript support, which means the development community can now extend the capabilities of FileMaker in some very cool, very powerful ways.

So we got to work, or in particular Daniel and Steve got to work, and we’ve come up with three new developer products — one is an add-on, the other a tool for crafting nicer interfaces, and the third a module for change logging.

All are designed to make both the developers life easier, and provide a nicer experience for your end users, whether they’re sitting at their desks using FileMaker Pro, out in the field using FileMaker Go, or anywhere using FileMaker WebDirect.

So to give you a brief rundown of the three products:

elemental_ux

elemental_ux is a design resource that helps developers build better looking user interfaces. Think of this as an image gallery. Somewhere you can go to access awesome avatars, icons, gradients and much more. It’s our attempt at giving developers the tools to take the ordinary to the extraordinary in design of FileMaker Databases.

elemental_log

Possibly the most mundane of the three, but easily the most important and business critical: elemental_log is data change logging toolset that embeds in your solution and tracks every field change in every table that you ask it to. This provides a complete audit log of who’s changed which data, when, and what values it’s gone from and too.

Log has been built to be as easy to use and set up as possible, with much attention paid to the design and the configuration. The joy of this is that there are very few steps required to get it up and running.

elemental_dropzone

Last but not least, our latest offering is from an amazing combo of Daniel and Steve…

elemental_dropzone is about to make your lives 110% easier, by giving you the ability to drag and drop multiple files and folders directly into your FileMaker solutions in a single go.

Not only does this work on FileMaker Pro, it also works on FileMaker Go and FileMaker WebDirect. This means if you are working on an iPad out in the field, you can add things like photos, signatures, documents, directly out of folders and right into your solution all at once without needing to add one file at a time.

And for your convenience, fellow developers, we’ve released this as a FileMaker Add-on, so it's always going to be there in your layout tools, ready to drop into any layout where it’s required.

To learn more about our elemental products, visit our dedicated website at:

elemental-fm.com

Wellington… Here We Come!

Thu, 06 May 2021 17:20:00 +1200

We’ve made a mental note that future job ads must include a reference to people named Paul/Paula/Pablo... You may ask why and that's because we have just taken on our latest 'Paul', this one being Paul Baker who will head up our new office in Wellington.

Paul Baker (or PB as he will be known) takes our 'Paul' count up to three, joining Paul Hutton and Paul Thomas (PT). Not a bad collection for a company of sixteen.

Left to right: Paul Hutton, Paul Thomas and Paul Baker

But back to Paul Baker, and welcoming him to the team at Digital Fusion. We always consider ourselves fortunate when we are able to take on new team members with Claris FileMaker experience. In the case of PB, he comes to us with an extensive background in the print industry, where he has put his FileMaker skills to good use, developing solutions that made the lives of his colleagues a lot easier.

In the last company he worked for, he took them from pen and paper, to full automation using custom built production and asset capture, Claris Filemaker solutions. Included was WebDirect access for clients and iPad capabilities for staff to capture live information out in the field.

We are excited to have Paul up in Wellington, an area where we have some great clients already and now with him on the ground there we will be better able to serve the region.

In his personal life, Paul is married and has a young son. He lives, and will work, in the central city, getting to take in the vibrancy of the fantastic city of Wellington.

SSL Certs and The Chain Of Trust

Mon, 24 Aug 2020 15:25:00 +1200

In the fun world of FileMaker Server configuration, one of the key tasks is to set up the domain name and an associated “SSL Certificate” — the cert verifies the server’s identity, and provides an encryption key used to encode data that flows between users and the server.

This is all marvelous stuff of course because it means that there’s no-way for someone to trick you into connecting to a different server than the one you meant to and because all the private personal and business data that is zooming along the wires and airwaves between you and the server is indecipherable to anyone else.

But there are some tricks to setting up secure certificates and how they work so we thought we’d share a recent experience we had when one of the certication authorities dropped the ball and broke what’s called the “Chain of Trust”…

Chain Of Trust

When you purchase and install an SSL Certificate on your FileMaker Server, you expect that you own the whole ‘kit and caboodle’, or at least you do for the timeframe you have purchased the certificate for.

To some degree that is correct, but there is a chain of trust that sits above your certificate that you ought to understand… in essence there are many organisations that can issue certificates, but only a few that are known and trusted by an operating system.

Therefore an issuer of a certificate has to be able to prove they are who they say they are and they do this by holding certificates signed by a higher authority.

The Root Of The Matter

At the top of the chain is a root certificate: every operating system and browser comes pre-installed with a bunch of known root certificates, which are securely stored in what is called a “trust store”.

(It’s worth noting that the private keys for these certificates are very closely guarded by the issuing certificate authorities! A certificate is validated with a private key.)

Taking an example certificate that we have, which proves that our teamdf.cloud servers are in fact genuine teamdf.cloud servers, the chain of trust looks like this:

An Example Chain Of Trust

Middlepeople

In this case teamdf.cloud is validated by Sectigo Ltd, who are in turn validated by The USERTRUST Network certification authority, and the operating system or browser on your device has a root certificate for USERTRUST allowing everything to be proven.

An important thing to note here is that there may be more than one “middlepeople” in the scheme and therefore many intermediate certificates will exist in the chain. This tree structure means lots of companies can manage and issue certificates, spreading the burden and allowing different security services to be provided.

It is common for an authoritiy to have multiple root certificates and to issue many intermediate certificates to other organisations.

What Could Go Wrong?

You may find that even though your certificate has just been purchased, those up the chain of trust have expired. This can cause quite a bit of confusion so it’s important to understand the above and have ways to rectify things.

This is exactly what happened recently with Sectigo’s AddTrust root certificate expiring (https://sectigo.com/resource-library/sectigos-addtrust-root-is-soon-to-expire-what-you-need-to-know)

A certificate authority, whether they are a root authority or an intermediate authority, has the ability to expire or revoke a certificate at any time. This can cause your certificate to become invalid and require a new set of intermediate certificates.

When you purchase your certificate you will be given details (links or downloads) for the intermediate certificate(s) as well. When you install the SSL certificate on FileMaker Server you will need to include these intermediate certificates (if more than one certificate is required you’ll need to combine them into a single file for upload).

FileMaker Server Import Certificate Dialog

When you have installed your certificate on FileMaker Server, connecting via FileMaker Pro, WebDirect, Data API or the admin console, the certificate will be verified by looking up the chain and verifying all the certificates it encounters right back to the root certificate at the top.

If you haven’t installed the intermediate certificate correctly or the chain is broken (e.g. an expired certificate), you will get an error. You can verify a certificate by clicking on the lock in the address bar of your browser or in a FileMaker Pro window.

Safari window highlighting the SSL lock icon

FileMaker Pro window highlighting SSL lock icon

Certificate Window

Trouble Shooting

So if things aren't working correctly some of the things to look into are:

Check that all the certificates have been installed correctly
Make sure you purchased your certificates from an authorised CA*
Double check that the server itself has been setup correctly
Use openssl to verify the certificates chain of trust, eg.

openssl verify -purpose sslserver -CAfile intermediateCertificate.crt certificate.crt

* CA = Certificate Authority

With SSL certificates now required on all FileMaker server installations, there are going to be some catches along the way. The above outlines things in a relatively simple form, but if you do strike issues, post a message below and we'll see if we can help resolve them.

FileMaker 19 Release

Wed, 27 May 2020 23:30:00 +1200

FileMaker 19 is here and with it we see a bunch of incremental improvements and some nice new features... and the end of the major annual update!

As Claris modernise their approach, they’ve pledged to move to smaller more frequent updates throughout the year - more of a continuous improvement approach. We think this is brilliant, we’ll see fixes and improvements much more quickly.

This first new version since rebranding to Claris, has a new icon: after 30-odd years of folders, FileMaker now sports the new Claris logo as it’s app icon. And the "Advanced" part of the name has been dropped — it's just "FileMaker Pro" now whether using the Advanced tools or not.

New Stuff

So what is actually new in this version? Well it’s pretty much as planned and revealed at DevCon in August last year. To recap:

On iOS mobile devices we get access to some more of the device technology such as NFC reading to be able to react to things like RFIDs and Bluetooth devices plus access to the Machine Learning engine in all Apple devices (including Macs) and Siri Shortcuts, opening up the opportunity to enable voice control of our apps.

Tag reading – Voice control – Artificial Intelligence

User Interface Widgets

Perhaps most exciting and visible will be new “widgets” that we can add to your FileMaker solutions: it will now be possible, thanks to new JavaScript commands, to embed complex widgets such as Calendars, Kanban boards, Gantt Charts and other diagramming, drawing, annotation and visualisation tools right into FileMaker solutions.

While this stuff is new as a native feature, we have been doing this for over 12 years with our Reactor plugin. At this stage Reactor still offers a nicer more integrated way of achieving the same result, but Reactor doesn’t work with iOS or WebDirect, whereas the new JavaScript commands do.

Claris intend to make some of these widgets available in a further update coming soon via an “add-on” mechanism that will drop in ready-made controls, but for now they’re not available, however feel free to talk to us now as we have years of experience creating these interfaces in FileMaker.

Web Browser Compatibility Improves

We also move a big step closer to 100% compatiblity when using a web browser to access your apps — we can now use the card window (a sub-window within the main window you’re using) in WebDirect.

What that means in practice really is that we’re very close now to being able to use FileMaker solutions from a browser, with minimal changes. Which also means you can access your solution from any computer or device connected to the internet. And in businesses where you’re not allowed to install apps without jumping through hoops, you’re good to go without that worry.

Personally I still believe that for apps you use extensively, you’re better off having them installed as a standalone app... but at least with WebDirect giving very close to the same experience, you have the choice and it is certainly a boon for those times when you need that access.

JSON Commands

At the very geeky end of the scale there’s a great new JSON command that makes it much easier for us to pull data out of FileMaker into JSON format — this will speed up certain development tasks and really represents further “opening up” of the platform.

JSON is very much the standard way that data is exchanged between applications (via APIs) and even within applications such as when synchonising data between a mobile app and a server when that mobile app has to be able to work offline.

Hello Darkness My Old Friend

For developers, FileMaker Pro now does “Dark Mode” on the Mac — since developers are allergic to sunlight this is a real boon. We can work with curtains drawn and at night, using dark mode to minimise the light cast from the screen, safe now in the knowledge that FileMaker won’t break the mood with a bright white blast from the script workspace or database definitions…

However to make a database itself, i.e. your app, have “dark mode” compatibility we still have to actually design dark layouts — we haven’t done it yet, but one possibility would be to have two versions of every layout, and navigate according to the system setting.

I can see this being particularly useful in some settings — for example with Aerial Toolbox’s helicopter flight record system it would make sense to use a light coloured background for daytime operations and switch to a ‘dark mode’ after sunset.

Our Recommendations

Don’t jump in just yet…

With FileMaker Pro: there’s some good stuff in this update but we’re seeing some user experience issues, including images in container fields distorting, slowness switching between screens, and some other small issues being reported. We reckon it’s probably better to wait til the first “point update” which usually follows fairly soon after a release in which Claris will likely address these issues.

For FileMaker Server: we’re keen to embrace the updates but we advise a cautious approach to updating your FileMaker Servers so suggest holding off for a short period: we’re switching some of our servers over to 19 right away, and will offer advice later in June on making the upgrade if all is going well.

Complying with a Pandemic

Fri, 08 May 2020 18:51:00 +1200

As Australia and New Zealand start to loosen the grips of lockdowns and businesses get back to work, you may find that costs for compliance are growing...

In short, the biggest element of compliance will be your time.

Good Ideas

A prime example of this was flagged with me over the weekend while sharing a few Zoom-drinks with friends who run a small electrical company. They have six staff in total and do a mix of domestic and light commercial work, all in the Christchurch region.

New Rules

Since the lockdown rules were flagged to be relaxed last week, they’ve been inundated with documentation that they need to complete. This is not from the government, but from their clients — it’s what they need to do to comply with other companies compliance rules!

These weren’t just documents that need to be signed-off by the business owners, but rather each staff member had to complete each form and sign it. Their only way to do this was to print out each document, get each staff member over to their home to complete, scan them and send them back. They have no simple way to automate this process, and they foresee that this is the ‘new norm’…

That’s only the start of a full time paper battle — they’re going to need to keep detailed records of who’s complied, and who was onsite when, plus of course that the actions they’ve agreed to are being undertaken. Did those gloves get disposed of correctly? Is everyone maintaining the correct social distance...

FileMaker + DocuSign!

When I mentioned that we’ve built solutions which used FileMaker integrations like DocuSign, and they could pretty much automate their whole process, including a robust and legally recognised digital siganture system, their ears pricked up…

But when you’re a small business using ‘off the shelf’ software, investing in a custom build is a bit daunting. So I put my sales hat on again and we did the math on how many hours/days they would save. When you start adding it up, an upfront investment like that starts making a lot of sense: the right solution could save a ½ or possibly full time position.

Claris Connect - A First Look

Sat, 07 Mar 2020 00:06:00 +1300

Claris have just released their new product Claris Connect, a cloud based service to orchestrate the connection and flow of data between different applications, including of course Claris FileMaker.

This means you can potentially do things like have a "card" created in, say Trello, automatically post a message in Slack, and create a task record in your custom FileMaker application.

The Business Case

For businesses this gives you way of using those smaller dedicated apps that you love, and linking them together to eliminate double entry and avoiding the need to build an API integration, or in some cases an entire custom app might not be needed at all — why not just tie together several different dedicated apps?

We'll come back and talk more about the business case for it in a later article, but for now as developers we were just dead keen to get our hands on it and have play around to see what it's capable of and get a true sense of how we might be able to use it to add value for our clients.

A few members of our team have jumped in and had a go so here's what we've found out and where we think it's going:

It's Early

Early signs are that it’s very promising, for both the casual ‘citizen developer’ right through to our professional developers here at Digital Fusion. There are some integrations/flows that would normally take a number of days that could potentially be implemented now in just a few hours. It’s early days in the life of the product, so we are interested to see how things evolve over time.

Our initial trials involved using Trello, FileMaker and Slack, connecting flows between them, so here's what we were able to achieve in about half day:

Let's Give It A Go Then

We set out to build a relatively complex workflow, connecting three different cloud based apps, each with their own complexities, in a very simple flow of information:

User creates a new card (task) in a Trello board
Have a message posted to Slack channel, posted by the Trello user, naming the card & id # of that card.
Execute a script in a FileMaker database to add that task

Adding the initial Trello trigger was a breeze, very easy to connect it to Trello & select the board we wanted to monitor.

Likewise connecting to Slack account was easy. There was a little time involved in figuring out posting to Slack but overall that was easy too. We ran into an issue where it does not appear Claris Connect can post to a private channel so we had to re-add the channel as a public one.

One really awesome thing about it was Claris Connect makes available to you any piece of information the Trello API returns, which you can use in future actions in the workflow. So we were able to formulate a message to post into Slack utilising any bit of Trello information. We could also grab the name of the Trello user and make that the “bot” name who posts, so it looks like the person who added the card is telling you in Slack.

The next step was to execute a script in FileMaker: the setup of this was actually pretty damn easy too. Very easy to connect to a FileMaker Server (must be 18v3) and select the database. We did have a few issues at this point in time with the script failing to execute on a number of occasions when passed information from Trello. Hopefully these bugs can be resolved in Claris Connect rather promptly as one of the most important aspects of this workflow requires this. It was at this point we came a bit unstuck and had to abandon completion of the workflow.

The “Test” feature is cool as it allows you to sample and verify the action (in this case run script).

Because we could only create three flows as part of our trial license, it did limit what we would love to have tested — ultimately we wanted to add the following:

Workflow for when a card updated, to update the task in the database
Workflow for when card deleted, i.e. remove the task from the database
Workflow for adding a message to Slack channel, the idea here is to be able to automatically add timesheet entries by typing a a slack post containing the Trello ID, hours & comment.

As mentioned above, we are really exited by the opportunities the product can bring to our development team here at Digital Fusion. We are going to keep a very close eye on how the product evolves and further opportunities for us to use it in our development.

You can find out more inlcuding pricing and sign-up for a trial yourself at the Claris Connect web site

Welcome MacBusiness

Tue, 14 Jan 2020 16:30:00 +1300

To kick off 2020 we’re absolutely thrilled to announce that the FileMaker team from MacBusiness in Christchurch NZ, are now part of team Digital Fusion, bringing 3 new developers to our team and a number of well established clients. In return we’re offering a bigger team for Jo, David and Sarah to be part of, and greater flexibility and capacity for those clients that we’ll be looking after under the DF umbrella.

David Christie, founder of MacBusiness brings over 25 years experience in FileMaker, Jo some 20 years, and Sarah over 15 years. These people know their stuff… MacBusiness has a top notch reputation and we know them well, having shared our knowhow and a few drinks from time to time over the years.

This brings our wonderful team up to 16 in total now, and with Sarah based in the North Island we have a new location to mark on the map — sunny Hawke's Bay. Moreover, as soon as we can convince these three to get certified, the sooner we’ll set a new record for the number of certified developers in… well, I reckon the Southern Hemisphere… certainly the Asia Pacific region any way.

And for those clients joining us from the MacBusiness fold — we are really looking forward to meeting you and getting to know you… but your existing team are right here and available for you as always.

Master Class In...

Tue, 03 Dec 2019 00:14:00 +1300

Eight of us crowd into the lounge of our Pyrmont office in Sydney Australia - four on a sofa, three on straight backed chairs and one standing. Albert Harum-Alvarez of SmallCo occupies the hot-seat from which to dispense his wisdom. Outside the sparkling waters of the harbour suggest a serenity that’s buffeted and bullied by the sounds of the inner-city streetscape…

The imagery of Albert’s slides take us literally half a world away as his metaphors, analogies and anecdotes gently tease and cajole us away from the structured rigour of pragmatic software. He wants us to find the 'who' of the application, not just the 'what' or the 'how'. Define the character of your software and stay true to it throughout he tells us.

When someone says design we think colour theory, the rule of thirds, the golden ratio, proximity, grouping and alignment. All of these rate a mention as respected fundamentals, but there is a perspective that Albert wants us to grasp - a way of feeling, seeing and thinking about our software.

…Character

We are to ask the question –

Is my app an extension of the user?

I’m reminded of Haptic Perception, the blurring of the line between body and tool as our proprioception encompasses the tool itself. Imagine a tennis racket, it’s not our sight that assures us that it will connect with the ball - it’s our understanding of the space it occupies in the world as an extension of ourself.

Designers of smart devices acknowledge this with Haptic Touch providing sensory feedback - the artificial click in response to pressure as reassuring as the impact of the tennis ball felt through the racket grip.

Is the App a comfortable tool that fits the contours of the user’s mind as the ergonomic grip of Albert’s Makita Sander fits the contours of his hand? Is it an extension of self that expands my capacity to remember, anticipate and communicate?

Does it in fact augment my abilities to super power status as spider venom did for Peter Parker? How else can I describe summoning a vehicle to take me anywhere I should desire with a flurry of gestures over glass?

Or is it my Sidekick? A helpful friend, a Copilot, a Navigator, or a Streetwise Buddy who gives me an edge in tricky situations?

Perhaps I’m the sidekick - the App is my mentor, my teacher, my trusted adviser- guiding me towards mastery of a skill.

If we think of our apps in these terms a sense of character can emerge that we can nurture and cultivate as we develop. If we stay true to this and inhabit the app as a writer inhabits their protagonist, we can intuitively identify the jarring out of character moments.

…Ego Management

Albert didn’t use the term, but frictionless is a notion that I inferred. Imagine tools so ergonomic to the body and mind, so effortless, you barely notice they are there.

And here’s the rub, the ego of a healthy human doesn’t gain sustenance from unnoticed achievements. We want our effort, our cleverness, our anticipation of the user’s needs to be noticed and admired.

Albert’s example was a [Compose Message…] button presenting all of the wonderful ways he and his team had achieved to send a message: “How would you like to send your message?” the app asked helpfully. But this is not the question that responds to the users immediate need. As unexciting as it is, what they need right now is an empty text field with a flashing cursor.

…Minimalism

Another ideal Albert asked us to pursue was that of less is more. Why is that element on the screen? What is the user doing here? At this point, do they need to see that data? Then why is it there? WHY IS IT THERE?

He drove towards single purpose layouts, insisting that ONLY the data and controls required for that purpose be present. This implies carefully orchestrated workflows rather than Swiss army knife single views where everything is possible.

...Faces

I’m not sure about you, but I’ve always thought of a portal as a table. It’s a way of presenting information, if the user wants to see more information there’s a helpful button that will take them to a detailed view. Albert sees them as lists. There are a number of types of lists (roster, log, ledger, punch list, cart or bunch) and a list shouldn’t try to be a type that it is not.

Take a roster for example…

Hang on, let me qualify roster - I think of a work schedule for employees, but Albert uses the term as a collection of items to choose from …a roster’s sole purpose then, is to present key data points that will allow the user to recognise the record they want to view.

Albert’s got another analogy for us - “You don’t recognise a person by their elbow, so don’t show a picture of their elbow, put their face on the screen”. He’s telling us to chunk together key data-points to build a face for the record. And to give the face character, in fact make it a caricature.

If it were a human caricature it would have big eyes, but in this case exaggerate the data-points that the user will instantly recognise, often the Vernacular ID. Love that term - Albert introduced me to it, the handle by which the people in the workplace refer to that entity in their day to day conversations.

Before v After

To wrap up

Reflect on the hierarchy of tools and techniques that we have. FileMaker gives us fields, and buttons and shapes and portals… and so on. These are the raw materials. Then we have the first layer of design abstraction: alignment, positioning, colour signifiers. At the next layer we diverge into an aesthetic stream with the rule of thirds and the golden ratio; and a usability stream with techniques such as grouping and proximity of elements. Albert’s master class extends the latter — he is teaching us to design for intent, for purpose, for use case. Fit the data and the design to the purpose of the app, and to facilitate the intent of the user.

Forward Thinking

Fri, 04 Oct 2019 16:04:00 +1300

At the FileMaker Developer Conference in the US this year FileMaker Inc. announced a few rather far reaching and exciting changes, starting with a new company name, “Claris”, followed by some new products in the pipeline, and of course a slew of nice new features coming to FileMaker itself.

All this comes on the back of the new CEO, Brad Freitag, who’s bringing a whole new level of invigoration and innovation to the organisation.

The strategy revealed at DevCon this year was profound, exciting and deep reaching.

But first, rest assured there are no plans to break or upset the platform that has evolved with much care and attention over the last 20 years.

Clear Yet Cloudy

There will be a shift to a more “Cloud First” way of thinking, which can only mean good things for FileMaker:

Better performance over the internet
Easier and more instant options for getting started in the cloud
Better features for web users (FileMaker WebDirect)
More web-like behaviours such as responsive layouts
Standardised deployment and maintenance of FileMaker Server

The emphasis on mobile is not letting up either: there are exciting new features coming for FileMaker Go including:

Siri integration
Access to the iOS Machine Learning engine
NFC reading — the ability to read RF ID tags and such

Think New

In addition to taking care of the existing platform, the team are also going to expand beyond FileMaker and tap into some new ways of thinking. And one of those is the idea of Workflow Apps — applications formed by tying together different apps and services using ready made connections (APIs) and logic commands to create, workflows and automation of data moving between different applications.

To jump start this technology, rather than try and build it onto the side of FileMaker they acquired a company called “Stamplay” which has been doing this sort of thing for a few years.

Out of that acquisition a new product is coming called “Claris Connect”, which promises to allow problem solvers and developers to build workflow apps, and which will open a up a world of connectivity to FileMaker by making it much easier to connect to other apps — think Salesforce, Box, Mailchimp, Slack etc.

Out beyond that, the company has started a “Labs” division where they’re experimenting with Next Gen products — ensuring the suite as a whole provides some truly innovative and exciting technology for supporting and creating more Workplace Innovation long into the future.

And Why Claris?

In the spirit of broadening the product offering, and representing the new thinking they sought a new name… and Claris, which derives from the Latin “clarus” meaning clear, bright, renowned, famous, upstanding, respected” was a very logical choice. We think it’s a brilliant brand name, nice that it harks back to the history of the company, but make no mistake this is a very new, very different Claris.

Easily Print or Capture Web Viewer content

Wed, 25 Sep 2019 07:09:00 +1200

Introduction

Back in 2008 when Digital Fusion released Reactor, we used web viewers a lot and we printed them a lot too. Display of javascript based gantt charts, calendars and other rich UI widgets would inevitably require printing by clients and so we'd come up with correctly sized print layouts to do the job.

That was the pre FileMaker 16 days, dating back to the introduction of web viewers in version 8.5. Printing web viewers back then worked pretty darn good.

Then in FileMaker 16 things changed. All of a sudden web viewers that render content fine in browse mode, would fail to render when in Preview mode, printed, or saved as PDF. The exact reasons for this change are murky and unclear.

These days, javascript is everywhere and more popular in FileMaker than ever. It therefore makes sense that people are going to want to be able to print the content they build for the web viewer.

In this article we cover a really simple and easy technique you can quickly add to your own solution to start printing web viewer content. No plugins are needed and no external OS level scripting or screen capturing required.

It's an API, duh!

Is anything these days not solvable with an API? I like to think not. When looking for a solution to a problem such as this, my first option is to look for an API that can do the job. So when looking for an API to solve this issue I looked for one capable of rendering html content.

The results took me to phantomjscloud.com.

PhantomJsCloud is actually a spinoff of an earlier project named PhantomJS. This was a headless browser API allowing testers to carry out user interactions on a website through javascript. Developers would write code to simulate user actions on a site. This project has since been discontinued.

PhantomJsCloud is a cloud based variant based on the same principle. It has a restful API where you can request the API to render a website and return the rendered site as an image, pdf, text or json.

Where PhantomJsCloud is really useful for us as FileMaker developers is its ability to render specific html code you specify, and it is this feature we use to print the web viewer.

The basic steps involved

Setup of the API is really easy. The API is free for up to 500 calls per day - more than enough for most people. With it you get an API key that you use in each request. There is no additional authentication required.

Let's say you wanted to print a web viewer that contained a javascript based chart such as the one below:

The steps involved to print are:

Obtain the code used in the web viewer. This is usually stored in a field and rendered in the web viewer with a Data URL such as "data:text/html,". Alternatively you can still use a URL to render if your web viewer is displaying a site.
Sign up to phantomjscloud.com and receive your API key
Using the Insert from URL script step, send a POST request to the API with your code/url.
The API will return you an image of the rendered code/site. Place this in a container field
Print the container field image.

That's it in a nutshell. We'll go into a little more detail as to how the setup and post request is constructed, but that is really all there is to it.

I encourage you to download and try out the example file for this article. You can use it to follow along with the rest of the article.

Sign up to the API

Simply go to phantomjscloud.com and sign up for an account. Verify your email address, and when you sign in on the dashboard screen you'll find your API key, that's really all there is to this part.

If you require more than 500 requests per day, there are pre-pay options or pricing plans available, but we think most developers won't need more than 500 a day.

Gather your web viewer code

There are so many different ways to render code in a web viewer. Some like to use a Data URL to render html content stored in a field or variable. Others might like to export their files to disk and reference them via the web viewer URL. Others might use a plugin to render content.

Whichever method you use, you're going to need your html code to be available to you in a script so that you can pass it to the API. If you simply display a standard URL in your web viewer than you are all set.

The API can accept either html code, or a URL to render.

using code in a field, rendered using a data URL.

Formulate your request to the API

The API request is a POST, and for this we'll use the "Insert from URL" script step, and some CURL parameters.

The URL for the request is pretty simple, it's the PhantomJsCloud site URL with the API key included:

The request is formulated as JSON, and sent as data in the CURL part of the request as a POST.

In our example file we have done the heavy lifting for you and written a standalone script you can use in your own solution. In it we've included the basic request parameters used, these include:

Viewport width/height - this tells the API what sized "virtual" browser window it should use to render and capture the content in. This is essentially how you tell the API what size image you want.
Render format - you can choose png, jpg, text or json. For the example solution we've included png, jpg and pdf.
Render output quality - for jpg images you can specify quality between 0 and 100.

When it comes specifying what to render, the two key json key parameters are "content" and "url". If you are simply rendering a URL, you specify the URL, and content can be empty.

If however you specify content, then the content parameter will include your html code. The URL parameter must be set to "http://localhost/blank" for it to work.

We send the request as a POST using CURL options as shown below. The $body variable contains our JSON request.

Store the response

The response from the API is typically an image (unless you specify the text or json options). So you simply set the result from the Insert from URL step into a container field. When done, now you have an image in a container that you are able to print however you wish, and that's all there is to it!

An alternative use case - SVG image conversion

Rendering code as an image using an API is a really novel way to render the web viewer. But there are other interesting applications to this API. One of which solves an issue I had recently when developing the Elemental solution. In this solution some of the APIs I integrated with would return the result as an SVG image. This meant that the SVG was unable to be rendered in a container field, and so for those examples, the image had to be rendered in a web viewer only.

This meant the image - in this case an avatar - could not be easily used by a developer. It couldn't be rendered in a portal (web viewers don't render in portals), and so the only option is to convert. In Elemental, my solution was a clunky web based method that was unreliable. It involved rendering there SVG in a canvas object in a web viewer, then converting the canvas to base64 encoded PNG. In order to extract the PNG out of the web viewer, a callback URL to a FileMaker script was used and the base64 encoded image passed to the script as a parameter. However there were 2 major issues:

FMP urls have a size limit on parameters, so larger SVG's did not work
The overall technique was clunky, and didn't work on windows and was unreliable.

The technique was abandoned. However in using this technique, I realised this actually solves the SVG conversion issue really nicely, here's how:

Render the SVG in a web viewer inside a div element.
Use some CSS styling to size the div element to the size of the web page. This allows the SVG to dynamically scale to be the same size as the websites view portal.
Now just run the code through the API and return the result as a PNG image.

In the example file for this article you'll find this exact technique as a working example. It can be used to convert any SVG of any size or complexity to png or JPG quickly and reliably.

Other functionality of the API

We've used the API purely for rendering a site as an image to suit our needs. However the API is pretty cool and does some other potentially useful things, such as:

Return a sites text content only, useful for extracting content out of a site
A separate automation API that can be used to programmatically interact with a site or content. This can be useful if you require your code to have user actions applied before it is rendered and captured by the API.
Zoom a page prior to capture
Render a site a a thumbnail - great if you want to capture a company site as a preview thumbnail, it uses smarts to extract best look of a site.
Generate a PDF of a web page - this is awesome! If your web viewer contains a large amount of data, or is wide/deep in terms of scroll depth, you can use this to produce a PDF render of its entire contents, something you can't do with a straightforward image capture.

A warning about security

You must take caution when using any API, especially if you are sending it sensitive or private confidential information in your site or code. Any information you send to the API could be stored on the servers at their end, and so make sure you only use this for generic purposes where you are not using information you wish to keep private.

If security is a concern, then consider purchasing phantomJsCloud enterprise plans. These are private cloud instances dedicated to your solution.

In conclusion

We've found this to be a really easy to implement and reliable way to render web viewer content generated directly from FileMaker. The API takes around 1-2 seconds on average to return the rendered image (usually 30-40kb in size). Other methods we tried involved plugins that screen capture the web viewer part of your screen. The issue here is around resolution and size of the capture, it is quite limiting. The API gives fuller flexibility around this. Not to mention no plugin is needed. This one is definitely worth checking out.

Example File

We always strive to provide the best example file to help you understand the article and get a head start on implementing techniques found therein. Please download and try it out for yourself below:

Click to download the example file here.

Take the Short Cut

Tue, 02 Jul 2019 07:53:00 +1200

Introduction

Learn shortcuts. Get Better. The End.

... well okay not quite, but this is perhaps the single biggest piece of advice I could give anyone looking to improve their skills as a FileMaker developer.

You can learn all kinds of tricks and techniques and yeah they're all great and will make you a better developer. But if you can double or even triple the speed at which you carry out actions in FileMaker through memorising and committing keyboard shortcuts to muscle memory, you'll free up so much time to do so much more.

In this article we'll show some examples of routine tasks done with and without shortcuts to illustrate how much more efficient your development can be.

We will also cover how you can extend FileMaker's existing suite of shortcuts to fill in the gaps in the product. Some of the missing shortcuts are so critical to speedy development it's amazing they're not built in, but we'll show you how you can easily define and add your own (if you are on a mac!)

Finally we'll go into more depth about some of our favourite custom shortcuts we use, and show some cool shortcuts you might never have thought you could do.

Learning shortcuts can be tedious!

If you're a new developer, now is the best time to learn shortcuts. Learning shortcuts as you learn FileMaker is the best way to do it.

However if you're a more experienced developer and have spent years attached to the mouse, contextual menus, or inspector to do things, then you've got a much tougher challenge ahead of you. Breaking years of habit can be hard to do, and you need to make a conscious effort to practice and use shortcuts.

FileMaker provides a full list of mac and windows shortcuts on their help documentation. A lot of people will be familiar with some of the more frequently used shortcuts (Define Database, Open Script Workspace etc). However did you know that there are literally hundreds of shortcuts!

We counted the total mac shortcuts available in FileMaker Pro, and there are around 260 give or take a few, that's quite a lot. Now, keep in mind that includes ones you might take for granted like cut/copy/paste, or arrow keys when in calculation dialogs to go to the start/end of a line - they're all considered shortcuts.

A real world example of the benefits

Enough preaching, time for a tangible example.

Below we have two videos. These were made for a talk I gave at the APAC Developer Day last year about this very topic.

To set the scene, we have a layout with some fields and labels, and a couple of other objects. The goal is to properly align everything nicely. In the first video we use no keyboard shortcuts - just the inspector and contextual menus. In the second video we use exclusively keyboard shortcuts.

We display a timer in both videos. In the second video we also show on-screen the keyboard shortcuts used.

First, no shortcuts:

and then with shortcuts:

Without using shortcuts we took 69 seconds, and using shortcuts the same actions took 45 seconds - a saving of 24 seconds. Or to put it another way we reduced the time by over 35%.

This is just a one minute example. If you do this kind of thing for a job developing 6+ hours a day, you can equate that to over 2 hours of saved time. Now that's an extreme example - you would have to be working exclusively in layout mode and doing a lot of manipulation to see that improvement, but this is a good illustration of how much time can be saved in increments over the course of a single day!

More to the point, I think the most important area you can learn and use shortcuts is when in layout mode. So much of layout development is making minor adjustments and then previewing your work in browse mode. This refine/preview cycle can go on for hundreds of iterations when building a layout. The quicker you can do your refinements, the more previewing you can get done in the same amount of time. You'll quickly find yourself becoming a better designer as a result.

And one final thing on the benefits. By using shortcuts you're not just getting faster at doing what you do. You will actually end up changing the way you develop. There's a tendency in developers to build something first, and refine or pretty it up later because that part of the task takes longer and is more tedious. By utilising extra shortcuts you'll find yourself doing refinements along the way rather than at the end (where they can often be forgotten about).

Spot anything unusual in the video?

For the keen eye who knows their shortcuts you may have noticed in the second video a few shortcuts you may not find in the standard set that comes with FileMaker. These are custom shortcuts we have added into FileMaker to extend our full set, and add even more functionality and efficiency to development. Some extra ones in the video were:

Resize Selected Objects to Largest Width
Align Selected Objects Vertically
Align Selected Objects to Smallest Height
Align Object Text to Top

Adding Custom Shortcuts

In FileMaker you can actually add even more shortcuts to fill in the gaps where shortcuts are missing. There are a couple of ways you can do this. For this article, you'll find our method in the example file that you can download below.

Download the example file CustomShortcuts.zip

Our basic steps to add custom shortcuts is:

Define which shortcuts to add, and what the modifiers/keystroke will be.
Generate some code to represent those shortcuts (automated in the example file)
Paste that code into the FileMaker preferences (plist file)
Restart FileMaker
Use shortcuts

The FileMaker preferences file (also known as the plist file), is where all settings and defaults for the FileMaker program are kept. We can add custom shortcuts to this file.

Mac Only (for this article at least)

At this point because we're getting into discussing how to add custom shortcuts, we must stress that the example file is for mac users only. To this point I haven't found a good way to add custom shortcuts for FileMaker on windows. If you have a good method for doing this please get in touch and we'll update the article.

Code to go in the .plist file

We won't go into too much detail about the specifics around building your own shortcuts because this is all covered with instruction in the example file. However to touch briefly on what is involved, let's look at some sample code:

This code is for a handful of custom shortcuts. You can see the shortcuts defined as key/string pairs of tags. This looks very much like XML. The key is the shortcut name (case sensitive and must exactly match the menu command in FileMaker). The string value is the shortcut representation. The code uses some special symbols to represent modifier keys:

@ for command
~ for option
^ for control
$ for shift

the modifiers are followed by the keystroke. Note some shortcuts require special symbols to represent them, such as the arrow keys, backspace, delete key etc. We list these special characters in the example file.

The code is pasted into your FileMaker preferences file. After restarting FileMaker you should be able to use these. Here is an example of some custom shortcuts for layout object manipulation:

The example file has 46 new custom shortcuts. All of them you'll find quite intuitive and similar to other existing keyboard shortcuts in the same area of FileMaker. For example a lot of the shortcuts in the "Manage.." use command+shift as the modifiers. The custom shortcuts continue this trend so you can easily learn them:

You can also add shortcuts in System Prefs

On the mac you can add application specific shortcuts (for any app) via System Preferences -> Keyboard -> Shortcuts -> App Shortcuts.

The shortcuts you add directly into your plist file will appear here, and vice versa. We prefer modifying the plist because it allows you to easily keep your custom shortcuts, and transfer them to different computers if you need to. However this is a nice way to view all of the ones you have defined or make any minor refinements.

Our Favourite Custom Shortcuts

Of the 46 custom shortcuts we use, there are a few standouts. These are ones either used most frequently, or quite unusual or interesting ways you can use shortcuts in FileMaker, we'll go through a few here.

Make Debugging Easier

FileMaker doesn't provide shortcuts to toggle the data viewer or script debugger, so why not add your own. These 2 tools are used so often in development it would be criminal not to use a shortcut!

Zoom to Actual Size

FileMaker provides a shortcut to zoom in (cmd+) and zoom out (cmd -), yet gives no shortcut to return to actual size, what gives? Let's just add our own. Most applications use cmd+0 as the standard, so we'll just use that, it's easy and intuitive for users and developers alike.

Layout object Manipulation

These are so critical. Completing the full set of layout manipulation shortcuts lets you never have to reach for the menus again. The best thing about these is they're intuitive and easy to learn if you already use the existing shortcuts (e.g. align edges)

Developing with Custom Menus?

Quite often when developing you need to build custom menus for certain layouts. While the users might require these, they can be incredibly frustrating for a developer especially when common commands might be missing from them. Often you just want to revert to the standard menu set - so why not bind a key to the standard menus? This lets you quickly an easily change the menu set no matter where you are.

Previewing Data in Layout Mode

The option to toggle sample data in layout mode is a really useful tool but is often overlooked because it is hidden away in the menus. Through using a shortcut key you can make this accessible and easy to toggle and add this valuable feature to your toolkit.

in fact you can add shortcuts for any items shown above.

Some cool multi-shortcuts

Now for some cool stuff. In FileMaker there are certain menu commands that essentially do a similar thing, yet at any given point in time only one of them is able to be used.

We're talking about the "Setup…" menu commands:

There are 8 different layout objects for which there is a setup dialog, however when working in layout mode you can only select one of these objects at a time for editing in the setup dialog.

This allows us to define the exact same shortcut for every single one. THey will never end up in conflict because only one will ever be enabled at any given time. How cool is that. It also means you only ever have to remember one shortcut.

Shortcuts don't just have to be for menu commands...

Interestingly, we found shortcuts can be applied to a lot of menus in FileMaker, not just the standard ones at the top of your screen. Take this menu for example:

Here we have a specify field dialog, and in it at the bottom is a special menu command to go to the Manage Database dialog. This is actually something we can add a shortcut to. Note this differs from the menu command File -> Manage -> Database… (the name is different).

The benefit of adding a shortcut to this item is if you have a very long list of table occurrences, you can use the shortcut to immediately access field definitions and the graph without having to exit this dialog, or go to the very bottom to access the command. Groovy. Now, you can always use the end key to jump to the bottom, followed by pressing enter, however this is a single shortcut that will instantly open the manage database dialog without the need for 2 key presses.

Work better in Script Workspace

How many times do you open the script step pane in the workspace just to look something up, and then want to get rid of it? How often do you need more space and want to collapse the script list (but easily get it back)?

Now you can just by adding some intuitive shortcuts:

These shortcuts are very easy to learn and intuitive. Here you can also make use of a similar technique shown above with the object setup shortcuts.

If the scripts pane is hidden, then the menu command is "Show Scripts Pane". However if the scripts pane is showing, then the command changes to "Hide Scripts Pane".

At any given time only one of those two menu items appears in the menus, so you can safely attach the same shortcut key to both commands without fear of conflict:

In Conclusion

I can't stress how great keyboard shortcuts are. I'm a total fanboy and I hope you all become fanboys and fangirls of them too. You'll find through a bit of dedication and time to learn them, you'll rapidly become a far better and faster developer as a result.

I encourage you also to make use of some of these additional custom shortcuts. There are some gaping holes in the standard set of shortcuts in FileMaker that fortunately we can patch with our own shortcuts quickly and easily.

Happy shortcutting!

Example File

We've referenced the example file a few times in this article, you can download it here. The example file contains further information about custom shortcuts and a step by step guide to defining your own and implementing them.

Click to download example file CustomShortcuts.zip

Thank you Matt Petrowsky!

I wanted to give special mention to Matt Petrowsky from filemakermagazine.com who got me onto these custom shortcuts many years ago now. Since then I've embraced them and used them daily and am a huge advocate for them.

Matt produced a database back in 2011 to help you build these shortcuts and implement them. While the file may no longer work in later versions of FileMaker, I encourage you to check out his site and the page for his solution. I drew a lot of inspiration from his work!

You can find his original solution here

Elemental has Landed

Mon, 17 Jun 2019 18:58:00 +1200

Introduction

Elemental is here! This is my first foray into building a product/resource that is much larger and more expansive than my standard demo files you'll find on articles. It's the main reason why the blog has been quiet these last couple of months as I've been spending all my spare time on this project.

If you want to check it out before reading, you can download a copy at https://www.elemental-fm.com

So what is it?

Elemental is more a resource than a product. Maybe you noticed over the last couple of years a trend toward more design and user interface based articles such as:

This is mostly because design and building solutions that are both usable and visually appealing really floats my boat. The user experience is paramount here and anything that can be done to improve the users enjoyment of using a solution is vitally important. Just think how many hours a day people spend using a solution that you might have built - you want it to be as fun as possible.

That's what Elemental is about. My goal is to provide UI resources that you can incorporate into your own solution to improve user experiences, be it through better user interface, or just purely a better visual design.

How much does Elemental cost?

Elemental is and always will remain free to the community. A lot of what I have done is writing code to help integrate with various API services, or make it easy to use freely available resources in your own solutions.

While I ask no fee to purchase Elemental, my site does have a donate option. Building this does take a lot of time and effort. I would really love to continue building on Elementals feature set which is why I have added this option. You are able to help make a contribution toward the continued development of Elemental. You can also just offer a donation if you really like the product and want to help me out, but this is not expected.

What's in Elemental?

In this first version I've got 5 sections...

Avatars

An avatar is something you'd typically find on the web. Most sites you sign up for have a profile photo you can upload. Some offer a randomly generated avatar if you do not provide one.

I've collated basically every restful API service out there that offers various avatar generators - 23 in total. They're all slightly different, each offering a different feature-set of options that you can customise.

Most work on unique generation based on a seed you provide. A seed is something generally unique to a user. Most of the time it will be the name of an individual, but you can just as easily use the primary key UUID, or whatever you like.

The avatar generator will take that seed and hash it to produce a unique avatar at the other end.

In Elemental you'll find a script group named "Avatar Generators". These are built to be standalone scripts you can copy/paste into your own solution to implement an avatar generator. There are just a couple of places in the script you'll need to fix up for your own solution:

The bottom of the script has the section where the avatar is returned and set into a container (or text field for SVG) you'll need to point this to your own container/text field.
Some scripts rely on a custom function @validate_input to make sure items passed are valid for the API. If the script uses this you'll need to import it into your solution.

And that's about it. We pass all parameter options that the API can accept to the script using JSON functions. You'll see at the top of the script all parameters are parsed.

Some API's will return the avatar as an SVG, which for us is kind of useless because container fields don't display SVG's (although you can render this in a web viewer and that is what we've done in Elemental for previewing the avatar). Fear not! Through some magic we've got a SVG to PNG converter built into Elemental which works all within a single web viewer off the side of the layout. Feel free to explore how this works. We'll cover this more in an upcoming article.

Placeholders

These are quite similar to the Avatars. We integrate with API services that provide placeholder images. These are great if you need an image of certain dimensions, colour or type to act as a placeholder. Perhaps you have a product database where you need a placeholder image, or you expect the user to insert an image of a specific size - you can integrate with a placeholder API that provides you an image showing dimensions.

We've got a few fun placeholders in there too....

SVG Icons

This one might prove most useful to the most number of developers. These SVG icons are from the Syncfusion MetroStudio suite of icons which are freely available. We've downloaded them all, and ran them through some processing to make them FileMaker ready. You should just be able to put these straight into a button bar and they'll be sized and positioned correctly ready to be used. You'll find over 7,000 icons in this set.

SVG / GIF Animations

A little bit of movement never hurt anyone! Add a bit of animation to your solution. These are a selection of around 20 loading style animations. These would be great if you have a Perform Script on Server that you are executing and need the user to wait to complete, or any other operation that takes a while to run. A bit of visual feedback is sometimes all a user needs to accept that there will be a wait time.

GIF's have been included because these are universally compatible on both mac & windows.

The SVG animations use SMIL technology which works great on Mac's but be weary on windows, not all browser versions support this so you may need to use GIF's.

These were obtained under free license from loading.io (but you can purchase many more). They are fully customisable and we offer instruction in Elemental on how to do this.

Gradients

Either love 'em or hate 'em, gradients are included :) We've collated over 330 different examples of gradients from GradientJoy that you can browse through and pick your favourite to use. Hex color codes are included so you can easily build your own in FileMaker.

Other Cool Stuff

Elemental has been built not just with some cool resources, but I want the overall solution to be considered a resource in and of itself. In it you'll find some other interesting little nuggets. Here's a hint of what they are and where to find them:

Elemental theme provided fully styled
HTML5 Color pickers are used in some avatar/placeholder examples (where the OS version supports them)
The Jdenticon Avatar has a double-range slider control (again if your OS supports it!)
About/Acknowledgement pages contain animated SVG icons - these are done entirely with CSS animations on a static SVG. To discover how it is done check the custom function @svg_animate. This was a feature I hoped to flesh out a bit more in this version but it might have to wait to the next one.
SVG to PNG/JPG conversion using some javascript in a web viewer and nothing more - check Avatar/Placeholder examples where it is used
plus lots more!

In Conclusion

Building Elemental has been a labour of love. Most evenings over the last 2 months have been spent working on this instead of having a life! I hope you all enjoy it and find something in there you can use, no matter how small, or at the very least to just be inspired to think more about design or the user experience - if I can achieve that then my work here is done :)

FileMaker 18 Release

Thu, 23 May 2019 12:34:00 +1200

FileMaker Inc have released the major annual update to the entire FileMaker platform today bringing a bunch of under-the-hood improvements and a few quite valuable, though generally quite technical new features. There are new versions of:

FileMaker Pro Advanced
FileMaker Server*
FileMaker Go

*The Server update includes a new version of WebDirect too — better, faster, stronger.

Should You Update?

In short Yes! ...but not necessarily immediately — here’s how we see it:

On Desktop, iPad and iPhone

We think you’ll be fine to go ahead and update the FileMaker Pro Advanced app on your computers and iOS devices right away — the business world is getting used to updating software regularly and even automatically now which you see with most cloud software.

On Server

We’re a little more cautious on FileMaker Server, where we reckon on waiting at least a couple of weeks to see if any issues emerge: FileMaker Server has had some substantial changes in how it works and while these have been tested extensively for many months now, there’s nothing like the real-world to turn up issues in software.

We’ll be progressively upgrading our own servers in coming days so that we too get some real world miles under our belts and can advise you.

That said, if you’re suffering from bottlenecks on the server then the good news is that 18 brings some huge improvements to multitasking, which basically means the server can better handle lots of users and tasks at once. In which case, let’s get on and upgrade you as soon as possible—just drop us a line asap.

Mix and Match

You can mix and match too — you don’t have to update for FileMaker Server immediately, and nor is it necessary for everyone in your organisation to update their apps at once.

In fact, it’s also possible to keep both FM17 and 18 on your device or computer, so you can try 18 and still fall back to 17 if there is anything misbehaving. (And in which case, let us and FileMaker know — use "Feedback" under the Help menu.)

To be clear though, in the long run though you’ll want everyone in the organisation on the same version and we always recommend staying up with the current version for robustness, security and to ensure you have the latest capabilities available. Also please bear in mind that the new version is not extra licenses — you’re not permitted to use your previous version for other users; please ensure you are licensed for the correct number of users.

What’s New?

Aside from the Server architecture, which is in fact one of the biggest and best things in our view, here’s what else is new:

For developers:

New commands for reading and writing text files
A new “while” construct for loops in calculations — Wahoo! Now we don’t have to think about recursion in order to create functions that work through piece of data.
Full XML / text dump of a database file — great for version control and change tracking.
Script error logging

New capabilities:

Support for more barcode types
Start-up Restoration — FileMaker files can now automatically recover themselves after a hardware or software crash on server.
Auto-open a particular database app on launch — simpler and easier for people who’re using one primary application within FileMaker.
Improvements to the “Data API”, allowing other apps better access to data stored in your FileMaker solution
Vastly improved data import tool
Enhancements to security, especially plugins and external access

Insecure Plugins

When you first launch FileMaker 18 you may well get warnings like this for each of the plugins you use:

The reason is that FileMaker now requires code to be "signed" by the developer, which simply ensures that it hasn't been hacked or modified. It's best practice and all apps are like that nowadays so it makes sense that the plugins should be too. You can go ahead and "Load plugin" for now, and I'd be inclined to tick the "Always load this plugin" option too, otherwise you are going to be prompted every time you open FileMaker 18.

That said, the correct and proper solution is to go and get the latest version of the plugin from whomever made it — all plugin developers should have released an update which is signed and secured in the correct way by now or very soon. If you're using our Reactor plugin, the latest version can be found on our fusionplugins.com site.

Moving On:

Plus with the move to ongoing subscription licenses means you’re always entitled to run the current version, and it’s easier just to stay current than lag and then have to catch up.

And… What are we losing in FM18?

macOS High Sierra or better is now required
Peer to Peer sharing is “deprecated” and permitted for testing purposes only*
Swedish language version of FM Server is being dropped
No new app icon — this version retains the same icon as FileMaker 17

And some of the older licensing options have now ended: the transition to a simple per user license continues and we think this is a great idea, ultimately making licensing simpler and keeping it fair.

*Peer to peer sharing refers to being able to open a database on your computer and let others connect to it, thus “saving” you having to run the database on server. It’s kinda convenient but not very robust or secure way to run a business at all. Given that FileMaker user licensing includes server (in fact you’re permitted to run 3!) we believe this is a good move. It is still useful in some cases, particularly when developing a new database and wanting to connect from an iOS device directly to the database on your machine as you’re building it, and that use case is still supported and permitted.

FileMaker 18 Release

Thu, 23 May 2019 00:00:00 +1200

FileMaker Pro Advanced
FileMaker Server*
FileMaker Go

*The Server update includes a new version of WebDirect too — better, faster, stronger.

Should You Update?

In short yes, but not necessarily immediately — here’s how we see it:

On Desktop, iPad and iPhone

Mix and Match

You can mix and match too — you don’t have to update for FileMaker Server immediately, and nor is it necessary for everyone in your organisation to update their apps at once. In fact, it’s also possible to keep both FileMaker 17 and 18 on your device or computer, so you can try 18 and still fall back to 17 if there is anything misbehaving. (And in which case, let us and FileMaker know — there’s a feedback option under the Help menu.)

On Server

We’ll be progressively upgrading our own servers in coming days so that we too get some real world miles under our belts and can advise you.

That said, if you’re suffering from bottlenecks on the server then the good news is that FileMaker 18 brings some huge improvements to multitasking, which basically means the server can better handle lots of users and tasks at once. In which case, let’s get on and upgrade you as soon as possible—just drop us a line asap.

What’s New?

Aside from the Server architecture, which is in fact one of the biggest and best things in our view, here’s what else is new:

For developers:

New commands for reading and writing text file
A new “while” construct for loops in calculations — Wahoo! Now we don’t have to think about recursion in order to create functions that work through piece of data.
Full XML / text dump of a database file — great for version control and change tracking.
Script error logging

New Capabilities:

Support for more barcode types
Start-up Restoration — FileMaker files are now automatically recovered after a hardware or software crash.
Auto-open a particular database app on launch — simpler and easier for people who’re using one primary application within FileMaker
Improvements to the “Data API”, allowing other apps better access to data stored in your FileMaker solution (what are they?)
Vastly improved data import tool
Enhancements to security, especially plugins and external access

Moving On:

FileMaker, as with most software makers nowadays are pushing more forward rather than maintaining a lot of backward capability. Not only does this make life a lot easier for the developer, it also ensures the latest robustness and security. It’s an important move and we fully support it — for us, maintaining old versions and having to work in them when clients don’t stay current means inefficiency and frustration. Moreover the move to ongoing subscription licenses means you’re always entitled to run the current version, and it’s easier just to stay current than lag and then have to catch up.

And… What are we losing in FileMaker 18?

macOS High Sierra or better is now required
Peer to Peer sharing is “deprecated” and permitted for testing purposes only*
Swedish language version of FileMaker Server is being dropped
No new app icon — this version retains the same icon as FileMaker 17

And some of the older licensing options (the Volume Licensing Agreements) have now ended: the transition to a simple per user license continues and we think this is a great idea, ultimately making licensing simpler and keeping it fair.

This does mean though that very small operations, say 2 - 3 users, need to purchase the 5 user license — think of it as “Up to 5 users”. That might mean an increase in cost for some unfortunately. That said, we reckon FileMaker is very good value — it works out at $17 per user for 5 users with no additional cost for the server software nowadays (that used to be more than $1500 itself), and if you are just a two person operation it’s $50 per user per month.

A Variable Way of Writing Recursion

Fri, 22 Mar 2019 07:22:00 +1300

Introduction

Recursion can be a complex and often intimidating part of FileMaker development for many. Wrapping your head around what it is and how it works is something even a seasoned developer can struggle with from time to time - just ask anyone who has sat the certification exam!

In this article we start by offering a brief introduction as to what recursion is by way of a simple example, before digging into the main reason for this article which is to present an alternative way to write your custom functions that is much simpler and easier to understand and follow. If you are already caught up on what recursion is and how it works, then feel free to skip down this introduction and get stuck into the more interesting stuff further down the article. Otherwise enjoy this introduction to recursion :)

So let's go!

Recursion is really just a loop

Yup, that's about it. We use recursion to simulate a looping construct when required in a calculation. FileMaker has no loop function at this point in time and so we rely on recursion to achieve the same effect. Think of it as being the ugly awkward half brother to a FileMaker scripted loop. A scripted loop can be used to loop and process records, or values stored within variables among other things. Recursive functions typically are used to loop through a list of values while performing actions on that list. They can also be used to transform values, or build lists of values.

Of course they are used for much more but in the world of FileMaker development most recursive functions you will come across tend to involved processing of multiple values, such as a list.

You write recursive functions using a Custom Function

In FileMaker, we use the Custom Function feature to write recursive custom functions. A custom function is purely a function you entirely declare and write yourself. They need not be recursive, but given we have access to write functions, we can easily write them to be recursive if need be.

You will find custom functions in FileMaker under the "File" menu - File -> Manage -> Custom Functions.

Writing Custom Functions

Note that in FileMaker Pro 16 and earlier, this feature is only available to users of FileMaker Pro Advanced. While a standard copy of FileMaker Pro can execute a custom function, you cannot write them. With the release of FileMaker Pro 17, there is no longer a separate version of Advanced, and so you can write these functions using FileMaker Pro. You just have to make sure you enable the "Use Advanced Tools" option which is set in the FileMaker Pro preferences.

Okay, so recursion is like a loop... but how?

Techterms.com has a nice and simple definition of recursion:

Recursion is a process in which a function calls itself as a subroutine. This allows the function to be repeated several times, since it calls itself during its execution. Functions that incorporate recursion are called recursive functions.

The key here is that the function calls itself. Each time a function calls itself again, you can think of it as progressing to the next item - or drawing an analogy to a scripted loop it would be akin to moving on to the next record to process. If we wanted to loop over a list of 10 items doing something to each, then the function would call itself 9 times (the first time the user calls it, and the other 9 times the function calls itself.).

Another way to look at it is to think of it a bit like the Droste effect. I'm sure you have all seen pictures similar to that below, it is a good way to think about recursion. You can read more about the Droste Effect here.

A simple example of recursion

Here we have a simple function _factorial (_integer ).

When this function is passed a number it will return the product of the integer and all integers below it, ending at the number 1. For example _factorial (4) will return the result of 24. This is done by multiplying 4 * 3 * 2 * 1.

The function first takes the parameter and makes it an absolute number - purely done to ensure we don't end up with a negative number parameter.

Recursive functions have an exit condition. This is a check to determine whether recursion is going to end or continue. It's exactly like the "Exit loop If" script step.

Each time the function is called, it will be being passed the next lowest number. The exit condition is when we are passed the number 1.

If we have not yet been passed the value "1", the function will multiply the integer passed by the result of the function called again (with 1 less as its parameter).

If you are still not following, have a look at this graphic:

Here we are showing each row as a subsequent recursive call to the function. The first time the function is called it is passed the value 4. The exit condition is checked "is 4 equal to 1?". Because the answer is false, we multiply 4 by the result of a recursive call. Now imagine repeating this but for the function with the parameter of 3. This is illustrated on row 2. We repeat the exit condition which is still false, and so the result of this call is 3 multiplied by the function call again with the parameter of 2.

Once more we repeat this until row 4 where the exit condition is true - 1 is equal to 1. The result of this is simply to return the number 1.

So the result of 1 is passed back up to row 3 and used as the result. Row 3 is equal to 2 * 3. This is passed up to row 2.

Row 2's result is 3 * 2 * 1, and this is passed right back up to the first row.

You can see this in the result column, results of each function call are passed back up the recursive chain to the original function call, and it is here that we can fully evaluate the result.

Clear as mud? Good! However if you are still struggling, at this point we recommend you download the accompanying example file for this article. You'll find a link at the bottom of the page. The example file includes a step by step guide to following the recursive function along with illustrations. You can also look at the function yourself in the unlocked file, to get a feel for how it works.

Let's take this further using variables

As we have seen, one of the most common ways in which recursion is done, is to process a value at each iteration, and then pass a modified version of the parameter to the subsequent recursive call. This is normally done by removing elements from a list, or maintaining a counter parameter which is incremented with each subsequent call so that each recursive step knows what position in a list it is processing.

Modification of lists such as chopping off values, or obtaining left/right values, can be quite an expensive and time consuming operation when done hundreds of times. Ideally we want to keep any parameter we use in an unmodified state and reference positions within it using a counter, it's a much more efficient way to process.

But what if we don't want to pass counters as parameters, can we do this? Can we use a local variable as a counter? Furthermore how far can we take the usage of local variables to improve readability and simplicity of the function? Turns out we can take it quite far.

The key - variables persist from one recursive call to the next

That's right. You can define a local variable in one recursive call, and the value of that will be accessible to all subsequent recursive calls. This makes them very handy for transferring of information from one call to the next without using function parameters. Think of them as storage lots that you can place information in to refer to throughout the function.

Now we are going to utilise this fact to show an alternative way to write a more complex function.

It is important to also note however that sometimes the method we'll show is not the best method. Often if recursion is simple enough, then just go with the simplest way to write it. Using variables is a good technique to improve readability for other developers, and can improve performance through minimal list manipulation functions, but go with what works best for you.

Example: _RemoveValues function

(Note you can find all examples from this article in the example file, linked to at the bottom).

Time to take things up a notch. This function is defined as:

_RemoveValues ( _listA ; _listB )

It will take 2 return delimited lists as its parameters. The function is to return all values in _listA which do not exist in _listB.

The way in which the function is written above is a pretty typical style that you might find in a lot of recursive functions. It begins with the exit condition which is when the first list is empty.

If there are values in _listA to process, it checks if the first value in that list is present in _listB. If so, it keeps it, otherwise it discards it. It does this by either getting the 1st left value from _listA, or the 0th value of _listA (in other words nothing).

To that value, it appends the result of the recursive call, however the parameter to this call is _listA without the left-most value present (as we just processed that one).

You'll note we are using 2 rather costly functions here - LeftValues and RightValues. These are inefficient function calls when dealing with larger lists. Consider a _listA with a thousand items. We will be doing a thousand recursive calls, however each time we do that recursion we are running the RightValues function to strip out the left-most value, that's a lot of calls !

Now let's look at it rewritten with variables

Here is our alternative approach to writing the same function but this time using local variables and a standardised approach to the functional structure:

There's quite a lot going on here to talk about. First thing to note is yes there are more lines of code here even without comments included. While there are more lines of code, it actually makes for a more readable function overall, as well as helping to better lay out a more simplified approach to thinking about recursion. This approach is more like a scripted loop, where you do not need to think as much about the complex nature of recursive calls.

Structurally the function follows this standard layout:

A counter is defined, as well as an exit counter value.
Use however many variables (both local or within a Let statement) you require to be clear and readable.
Use a local variable to maintain your final result value.
Define your exit condition. When evaluated to true, clear all used local variables, and return your result value.
If exit condition is not met, simply call the function again with the exact same parameters.

One of the key differences here between this and a standard method of recursion is that we don't bother updating passed parameters to the recursive call. They can remain exactly the same - no modification to them is required. We also do not require a counter parameter - this is maintained through a local variable.

A note about the exit condition and variables

Upon reaching your exit condition, it is highly recommended that you clear all your local variables. This is because if you do not do so, their values will persist in the data viewer after the function finishes. This state is known as the 0 script state, and is a state where local variables can exist if defined outside the scope of a script - such as here in the function. In the interests of tidiness clear them when you're done. One of the reasons why we prefix all of our variables with an underscore when defined in a function is so that we know they were defined from a function. Normal script variables if defined should not be defined with the underscore. This is another way to ensure there is no conflict between variables defined in a function that may not be cleared, and those that get defined in a script.

Defining a counter and exit value

The first step in our function is to establish a counter, and an exit value. The counter will be incremented each time the function is called in order to track our position in the recursion. The exit counter value tells us when to stop processing. Usually we know when this will be before we begin because it usually corresponds with the size of a list we are processing.

You'll note the first check is whether we have a counter value at all - this will ensure that the very first time the function is called we set an initial counter value of 1. After that, each subsequent recursive call will see a value in our counter, and so increment it instead of initialising it.

The same goes for our exit variable. On first call it will be empty so we set it to the size of our listA. Subsequent calls we do not modify it. This only needs to be set once.

Defining processing variables

Processing variables help us store values that will be carried from one recursive call to the next. For these we use local variables. If we require variables that need not be transferred from one call to the next, we instead use Let statement variables, whose scope is only that of the current function call.

In our example each successive function call will work with a specific value in our list. We use our counter to tell what value that is, and we use GetValue to obtain it. GetValue is a far more efficient function call than Left/RightValues.

We do our check to see whether our value is in ListB or not, in the same way we did in our earlier function definition.

Finally, we have a result variable - $_return - which we will store what our end result will be. This value persists from one function call to the next.

The exit condition

Here is our exit condition:

The exit condition is almost always the same - it's when our counter reaches our exit value. At this point in time we need to do a couple of things:

Clear the local values we defined
Store our return value in a Let variable
Clear our return variable
Return the result

Steps 2 and 3 are a bit of a quirk. Our result is stored in a local variable, but we cannot clear this variable before we return it as a result. To work around this, we store it in a Let variable and return that instead. the Let variable is automatically cleared when the function ends. Using the Let function allows us to clear all used variables used in a nice concise manner.

And finally, the recursive call

In our recursive function definition, the actual act of recursion is reduced to somewhat of an afterthought. We don't need to think about it, or worry about what we pass it. We just call it.

Pros and Cons of this method

As mentioned earlier, this is an alternative approach to writing a recursive custom function but not to be considered the correct way. There is nothing wrong with writing it however you wish. There are pros and cons with using this method. Some pros are:

Improved readability - useful if other developers must interpret your code
Simplicity through closely resembling a scripted loop
No need to modify parameters passed through each subsequent call
No need for state-tracking parameters such as counters (done in variables)
Easy to follow.

Some cons however are:

You need to clear variables when done
There is a risk variables could interfere with other processes if not cleared
No guarantee this is a supported FileMaker feature, no guarantee it won't be deprecated in future.
Perhaps performance hit through act of using local variables as opposed to purely Let statement? Unsure.
May not play nice if your recursive function calls itself multiple times within each call (e.g. some sorting functions).

The choice is yours. If this works for you then by all means embrace it and use it. We certainly have. But not all functions are the same and some other approaches to writing them may work better for you. Our aim here is that this method is clear to read and follow and might help developers feel less anxious about writing complex recursive custom functions.

Example file!

Click to download example file!

Easily View Microsoft Office Files in FileMaker

Thu, 28 Feb 2019 10:22:00 +1300

Introduction

When it comes to viewing Microsoft Office files within FileMaker, this has always been quite a sore point for developers. Unlike images, video files, audio files, and PDF files, we cannot directly view these file formats within container fields. Developers tend to resort to exporting the files to disk and auto-opening them locally on the users machine. This however requires that the user have a copy of Microsoft Word, Office, or PowerPoint installed in order to view the file they wish to see. This is not always the case.

In this article we're going to show how you can add Excel, Word or PowerPoint document viewing to any existing FileMaker solution in about 10 minutes, the setup couldn't be simpler!

Viewing Files Online - Using the Office App Viewer

Microsoft has a range of apps within its office 365 offering. Examples like Word, Excel, Powerpoint are so commonplace in industry today that almost everyone at some stage needs to view a doc file, or open a spreadsheet in Excel. Microsoft also makes these apps available online in the cloud via their 365 service. Users can keep their documents online in their MS OneDrive, and use online tools to view documents entirely within the browser.

But did you know that they also have an online file viewer, which is freely available for anyone to use, no account required? This will render any Word, Excel or PowerPoint presentation providing that file is hosted online and the URL is accessible to the file viewer tool.

Using this fact we can utilise the viewer in order to view documents stored directly in our own solutions. We just need to get the file online so that the viewer can render it for us. No more viewing of a document in FileMaker and just seeing this:

Getting your files online

The first obstacle to overcome is getting your container data online so that the office viewer can render it. Now there are obviously numerous ways you can do this, such as:

Host via third party service (which we will do)
Use your own web hosting server (good as you can secure it and control access to just the viewer)
Hack around with Apache/IIS to directly host externally stored container data - yes it can be done though not recommended!

For this example we're going to use a really simple online file hosting service called file.io. The goal here is to upload container fields to this service, and use the resulting hosted URL to pass to the office viewer for display.

File.io - Pros and Cons

File.io is a great little service for hosting files. One of its key benefits is that it is a single-view only service. When a file is hosted there, the URL is only valid to be viewed once only. After that single viewing occurs the file is deleted and the URL is removed. This is perfect for our use because we don't want that file to hang around on a server somewhere, nor do we require the URL after we view it.

While that all sounds good, you have to be very careful when dealing with any third party service especially when they will be hosting your files. You may have sensitive information in your files you do not wish to put in the public domain. While secure, the files will still reside temporarily on someone else's server, and while the URL is a one-time view, you can never fully trust that.

We are using this service for the demo but you should consider a more secure method of hosting your container data online if you intend to use this service. A good method would be to host them on your own server, and only allow the office viewer URL access.

Uploading files to File.io using Insert from URL

The file.io api is really simple, no keys are required, it's a simple CURL post of your file to their server, and in return you are given some simple JSON. Included in that result is the URL to your file.

You can find this script in the example file included at the bottom of this article. It is recommended you download it and have a look through as you read.

Here's the code above. What we do is first put the container data into a variable $file. This makes the subsequent steps a bit easier and clearer.

Next, We calculate a local variable name, which we store in $VariableName. Why do we do this? Well this comes down to how posting of a file works using CURL, in conjunction with what the file.io api is expecting us to give them. This will be more apparent in the next step:

Evaluate ( "Let ( " & $VariableName & " = $file ; 1 ) " )

We are evaluating a calculation string here where we are setting our variable to the file contents that is stored in $file. As an example if our file name was "test_file.doc" , then the name of the variable we are setting would be $test_file.doc , and the value of this would be that of the file itself. We use a LET statement to do this as it allows us the ability to soft-code the variable name without having to explicitly define it.

Why must we do this? Because in the following POST to file.io, we send the file using the "-F" command:

When we use a FileMaker variable in a CURL request, the name of the variable is important. File.io is using the variable name as the name of the file itself, and FileMaker in turn is passing the actual content of that variable to file.io - the file itself. If we were to use some other variable name e.g. "test" then the resulting file uploaded would be called "test". The Microsoft office viewer would not recognise this as a valid file format and so fail to display it. This is why variable name is important to be given the same name as the actual file we want to view.

Once our request is posted off to file.io, we simply parse out the "link" key value from the JSON response.

Rendering in a web viewer

Once we have the URL to our file, the rest is easy. The office viewer simply follows a simple url format which accepts the files URL as a parameter:

http://view.officeapps.live.com/op/view.aspx?src=[OFFICE_FILE_URL]

We just replace [OFFICE_FILE_URL] with the one returned from file.io. We then display this in a web viewer.

How does it look - Word

This is what the viewer looks like for our 3 main file formats. Firstly a Word document:

Not too shabby! The document is strictly read-only so no editing is allowed. Some of the options listed in the toolbar and menus are not available but others are, things that work include:

Accessibility Mode - a nicer full screen experience
Save to Onedrive (provides a sign in option) not fully tested!
Print
Search within document
View document comments

There are buttons to "Download" and "Download as PDF" but these do not seem to work in the web viewer. However, the Print option does. The print option should open a new tab in your browser (so outside of FileMaker) and give you a PDF version that is printable. From here you can print or save as PDF.

How does it look - Excel

Here is a simple Excel spreadsheet:

Again, pretty good all things considered. Once again read only, but you can clearly see cells/columns and it looks very much like excel. Again options you can make use of include:

Viewing multiple sheets within the file
Summing/counting columns - totals are shown in bottom toolbar
Save to oneDrive
Print - opens in browser as PDF
Find within sheet
View comments

Same again as the document, download buttons don't work.

How does it look - PowerPoint

Lastly we have a PowerPoint presentation:

Features include:

Navigate through slides
Toggle reading / slideshow view
View associated slide notes
Start slide show (opens in browser, slide show includes animations)
Save to oneDrive
Print to PDF (via browser)
View slideshow comments
Accessibility mode

What about Google?

Google has its own similar offering based on its Google Docs service. Again it works in the same way office viewer does - it's just a URL that accepts another file URL to render.

Google actually has quite a bit of benefit over Microsoft when it comes to viewing other file types. Google offers a far wider range of file types to preview. This is really handy for some industries such as graphic design, because Google allows viewing of things like Adobe Illustrator, CAD, and other graphical formats. Google also allows preview of CSS, JavaScript and HTML files which would come in handy for some.

There is however a big drawback to Google, and why we haven't sung its praises in this article to this point. Unfortunately it doesn't work very well with our file.io service we are using.

When Google Docs is rendering a file URL, it must be accessing that URL more than once. File.io only allows access one time, and so Google Docs fails to render most file formats for this reason. Now, this is purely a limitation of file.io so if you host files using any other method you are likely to be able to use Google perfectly fine, in which case this may be the better option for you.

Google renders its previews as a PDF in almost all instances (exception being audio/video)..

As of writing this article it would appear only the Word Document format reliably works with file.io and so that has been included in the Demo.

File formats that Google accepts includes the following:

Image files (.JPEG, .PNG, .GIF, .TIFF, .BMP)
Video files (WebM, .MPEG4, .3GPP, .MOV, .AVI, .MPEGPS, .WMV, .FLV)
Text files (.TXT)
Markup/Code (.CSS, .HTML, .PHP, .C, .CPP, .H, .HPP, .JS)
Microsoft Word (.DOC and .DOCX)
Microsoft Excel (.XLS and .XLSX)
Microsoft PowerPoint (.PPT and .PPTX)
Adobe Portable Document Format (.PDF)
Apple Pages (.PAGES)
Adobe Illustrator (.AI)
Adobe Photoshop (.PSD)
Tagged Image File Format (.TIFF)
Autodesk AutoCad (.DXF)
Scalable Vector Graphics (.SVG)
PostScript (.EPS, .PS)
TrueType (.TTF)
XML Paper Specification (.XPS)
Archive file types (.ZIP and .RAR)

So in Summary..

We've shown a really quick and easy way to view office based files from FileMaker. We have however shown you must think carefully about how you use this because both google and Microsoft require a publicly available URL that it can access in order to render the file, so think long and hard about how you handle this requirement.

Good luck!

Inspiration for this Article

While searching for a way to view spreadsheets in FileMaker for a client, it was this following site I came across which gave the answer:

https://gist.github.com/tzmartin/1cf85dc3d975f94cfddc04bc0dd399be

Many thanks to that sites publisher tzmartin for providing this invaluable information. You will also find on his site information about how you can do this within an iframe, and how you can use both Google and Microsoft to view files stored directly on their respective cloud offerings - Google Docs, and OneDrive.

Example File

As with all of our articles we produce we like to provide a detailed example file to go along with it. It’s not enough to just read how something is done, you should be able to see it in action and explore how it works yourself. Please find attached the example file below. This article is based on the example file. As always, this is a free download, and we won't make you sign up to download :)

Click here to download the example file!

DIY: Tempting Templates

Thu, 07 Feb 2019 12:04:00 +1300

If you want to build your own app for your business, then FileMaker is just the platform: powerful, yet accessible enough for those focussed on solving problems, especially if you have a bent for code. But where do you begin?

In this article Stu takes a look at the latest template files from FileMaker Inc., files that get you up and running with a basic working solution, but they're open for you to then add-on and customise:

New And Improved

FileMaker have just released a series of three new templates that allow users the ability to have a starting point in terms of a featured solution.

We think these are a great idea, and are a real step up on what was on offer in the former starter solutions. They meet some really core needs for some organisations/businesses and for quite a number, may well be all they need.

The three templates are:

Memberships
Job Tracking
Event Management

In each case, an organisation could pick up on these and use them to manage their member base, job management and events respectively. The basic requirements are covered and all you need are some FileMaker licenses, somewhere to host the database, and you're away.

What makes us happy, as professional developers, is that it gives those of you taking the DIY approach a sound starting point, so that if you come to us for help or to pick up where you've left off, the foundations are both standardised and well structured!

These templates allow you to get a clean, basic app in place, and then build in the features unique to your organisation, industry or way of doing things. There are also a bunch of ready made add-ons, tutorials and guides accessible from the FileMaker site to help you along the way — www.filemaker.com/templates

And of course we're very happy to help with guidance, one-on-one tuition, or to pick up where you leave off to carry on development.

Features

Looking a little more in-depth at each of the templates:

Memberships

This one is ideally suited to the organisation that needs to manage a membership base along with campaigns/donations.

The core features are:

Member details including name, address, contact details, whether they are active or inactive, along with your interactions with them
Building a campaign and tracking the donations against a target
Viewing and exporting all campaign and donation data

This is a great entry level way to manage a membership, but we can already see that you would want to hook this into a website (so donations can be taken online), more reporting features, user management etc.

Job Tracking

Like the membership template this one includes all the things you need to track jobs, all within a single well build database.

The core features are:

A basic CRM to allow you to list all staff and clients
The ability to setup a job, which in this template they are based on a building/construction business
Setup jobs and tasks and assign staff to each
Have staff track their time entries and mark whether they are billable or non billable
View all time logged against a job or task

With job tracking being one of the primary types of solution we build for clients, we know this template will be popular. It'll probably get you to a point where you want a lot more, such as an iOS app (using FileMaker Go) to allow staff to track their work while out on the road or worksite, more reporting, the ability to record material costings, and so forth, which would all make this a more fully featured application.

Event Management

Managing an event from start to finish is a huge job, and all to often done via a stack of spreadsheets. Having an orderly way to manage an event will take away a big headache and allow you to focus on the more important tasks at hand.

The core features are:

Add an event including the the date and location
Add sessions, with date and start/finish times
Manage all attendees to the event
Create a registration list that can be exported as a PDF

Once again this template is a great start, and the features included may be all that is required for an organisation to run an event. Taking it the next step further, you could add web integration so attendees could view and book sessions. You may also have different sessions at different locations, have a limit on how many people can attend any session, have the ability to manage payments (if it’s a paid event).

As you can see by the above, these templates are a good starting point and they may meet all the needs of some organisations. Or it might be that you want to further develop them yourself, in which case FileMaker have given guidance on how these can be extended further.

So we say give them a try, see what you think (you can use the FileMaker trial license to start with), if you need a hand down the track do reach out to us, we would love to discuss your requirements.

Scheduling With DayBack

Tue, 22 Jan 2019 17:54:00 +1300

Scheduling is one of those perennial problems that businesses face when allocating jobs and resources. It’s deceptively simple to do on paper or a whiteboard when you have just a few people or resources to organise…

But ramp that up to say 40 technicians across multiple locations and two countries, and you have a much trickier challenge. Handling jobs and resources is the sort of thing that's ideal for FileMaker, but it needs a calendar-style interface. A calendar is a great way to visualise what’s going on and makes interaction easy because you can drag jobs to allocate them.

Boom! A Calendar

You can’t do that sort of complex dynamic user interface with FileMaker alone so implementing a calendar as an add-on is the only way to do it. While we have a great resource calendar with our Reactor plugin, we decided to use the DayBack calendar from Seedcode for this project because it has a few key features that fit this project better.

Like our calendar, DayBack is essentially a web page, embedded into the FileMaker layout within a web viewer. In saying that, the web page doesn’t come from a remote web server, but is generated directly within FileMaker on the user’s machine.

Integrating such complex controls with FileMaker via the web viewer is a powerful and very smooth way of bringing in extra functionality and it feels like it’s just a normal part of the screen — below you can see the calendar and native FileMaker fields together on the one screen:

Tailor Made

We needed to be able to schedule technicians to jobs in various locations, and convey that information to them individually, while maintaining a single centralised overview in the job database app.

To do that the scheduling screen allows administrators and managers to tailor the view to groups of technicians, jobs, and days. You can choose which techs to show and which days you need to see, and if you choose to view more than fits on screen you can page through the technicians with forward and back arrows. This means each branch can focus on their own techs or subgroups of techs as need be.

On the calendar there’s a special column labelled “none”, where jobs sit until they are allocated: simply drag a job from the “none” column onto a technician to assign the work.

Technicians have differing background colours indicating the type of equipment they have, which affects the type of jobs they can be assigned — that feedback guides the user and avoids frustration… and having the overview of a group of techs at once means you can see at a glance what you’ve got to work with and who’s available.

Speaking of availability, the scheduler also shows when people are unavailable because of leave or travel periods. Another nice feature is that some jobs require overnight stays, so the calendar is also used as a way to record that information which means that each technican can easily find their accommdation details when needed.

Integration With Google Calendars

Behind the scenes the scheduling calendar is integrated with the Google Calendar API so that each technician can have their own personal Google Calendar where their appointments are shown, including job notes and accommodation details for those overnight stays. This also means they can tailor the calendar behaviour such as colours, views and notifications to suit how they work.

Modal Magic

Tue, 13 Nov 2018 08:23:00 +1300

Introduction to Modal Dialogs

What is a "modal dialog"? When we talk about dialogs we’re actually talking about windows in the FileMaker sense. They could be a card window, or they could be a regular dialog window, or even a floating window or FileMakers own modal window style. Modal refers to a window state where the window cannot be dismissed without the user explicitly making a decision that will lead to the closing of that window.

Example File

Rather than wait til the end to check out the demo, we strongly recommend you download and explore the example file as you read. This will help you follow along with the content of the article and help you to understand what we are talking about. The demo file contains a lot of examples and information relevant to the remainder of the article, and you’ll find it easier to follow along the article with the demo file open so that you can explore as you read.

Click here to download the example file

FileMaker's “Card” Window

A simple modal dialog just opens and sits there forcing the user to do something. No scripts are running, and it’s up to the user to click a button or do something that has been scripted to carry out an action and close the window. The user is unable to move to any other window in the solution before dealing with the modal dialog. Think of a card window that opens showing the user some preferences. The user can do things on that layout, but has been given a close button to dismiss it. The card window is modal in a sense that the user cannot interact with the underlying parent window. Card windows are modal to the parent window only.

FileMaker's “Dialog” Modal Window

Other modal dialogs such as FileMakers “Dialog” window option, are more modal to the entire solution. When a dialog window is created, the user cannot move to any other window in the solution while the dialog window is open. FileMaker Dialogs are useful but they do suffer from a couple of drawbacks which we don’t like.

Firstly, any script that you execute from within a FileMaker dialog window must reside within the current file. You are unable to run a script in an external file. In some solutions this is a deal breaker. You are also unable to spawn any other temporary windows for the purposes of carrying out actions in a script, you literally are locked into a single window.

It is for these reasons we never use FileMakers dialog window option.

Different Uses of Modal Dialogs

We’ve touched upon a couple of uses of modal dialogs already. One may be used simply to have the user locked into a window, such as editing critical preferences. You would not wish for these to accidentally be left open in a window on-screen. By making it modal, the user must close in order to continue using the solution.

Another typical use to replace FileMakers custom dialog script step in favour of a more appealing dialog built using a layout. A script is run and a modal dialog window is opened showing the user a nice dialog in which they have to make a decision. Based upon the decision they make, a different process is performed.

Script Execution and Modal Dialogs

This last use raises an interesting question. If we are using modal dialogs in scripts, such as replacing a custom dialog, then surely the user decision in that script should be then used in the remainder of the script that initiated it?

To show what we mean, lets look at a diagram:

We have a script that is run, and that script at some point in its execution requires a user input to be made. To do this it opens a new modal dialog. This could be either a card window or a dialog window. The user makes a decision, which the script then continues execution with.

But wait, something is not quite right here? If the script opens a new window waiting for the user to do something, what happens to the execution of the script?

There are 2 possible scenarios here. The first is that upon opening the modal window the script ceases execution, leaving the user on the modal window. The user might then do some input, or click a button. The script that they execute in the window might be responsible for continuing the execution of the original script.

Another scenario is that the initial script upon opening the modal window enters a paused state. The script is still running but stuck until resumed. Upon the user making a decision in the modal window, the script is resumed and can continue execution.

It is this second method that we prefer, and love to develop with. There are a number of reasons why we prefer this method which we’ll cover next.

But first, lets talk about reusability

Reusability of modal dialogs is an absolutely critical concept we need to talk about, and it is where modal dialogs become really powerful. Think of a modal dialog as a function. You call a function, you pass it some information and then the function does some calculations and returns a result.

Modal dialogs can be the same. You initiate a modal dialog. The user does some stuff in the dialog, and the dialog returns a result. Through designing modal dialogs in this fashion, you can build a dialog that can be reused multiple times your solution. The dialog becomes something you invoke whenever required to obtain a certain value.

A classic reusability example
Let’s look at a really simple example of a modal dialog being reused. Let’s say you have a table of contacts in your solution, and in your solution there are multiple different scripts that require you to select a contact. One example might be if you create a job, and in order to dos you must know which contact the job is for. Another might be raising an invoice, a quote, or establishing a relationship between two contacts. All of these processes require a contact to be chosen (or added if they do not exist).

In all of these scripts we write, we could program different dialogs in which the user selects a contact, or we could build a single modal dialog - known as a “Contact Picker” purely for this purpose, and reuse it in all our scripts.

The contact picker is invoked by a script to launch it. The user can then do a search in the picker, or perhaps they can choose to add a new contact. The result of the picker is to simply return the ID of a contact chosen - that’s it. If nothing is returned, we assume the user cancelled and did not select a contact.

Now, if we could invoke this in every other script that requires a contact, we have a nice reusable dialog to suit all situations where a contact is required.

Building a Reusable dialog

Reusable code is nothing new, nor is reusable dialogs of this fashion. People have been building them many years. However most of the modal dialogs we have seen in other solutions typically involve a certain process mentioned earlier where once the modal dialog is opened, script execution terminates, and is then reestablished upon user decision.

Here, our initial script A is run. Perhaps this is for creating a job lets say. It requires a contact to be chosen, so opens the modal contact picker dialog. Script A then terminates and is no longer running. The user selects a contact in the dialog and upon doing so, it begins execution of another script, B.

There is one big issue here - how does script B know that Script A was initially running and required the contact ID? Moreover, how does script A continue its original execution now that it has terminated?

There are various ways around this. One such way is that B is a decision script, and we store which process was initially running (ie Create Job) in a global variable. Script B checks this, and knows that prior to the dialog being invoked, the “Create Job” process was running, and so returns the contact ID chosen back to this script.

Even in doing so however, any state that was in script A was lost the second it was terminated (unless everything was stored in global variables).

It’s all a bit of a mess, and the more times you use the contact picker dialog in more scripts, the more checks and branches you end up with having to cater for and the more scripts you have to restore.

Fortunately there is a far easier way to structure your modal dialogs.

Never stop your script running!
The simple solution is to never stop your initial script running. Once the modal dialog is invoked, your script enters a paused state, and just sits there… waiting. It is waiting for your modal dialog to finish, and return back to your initial script the contact ID. Once that happens, your script simply carries on and uses the chosen contact ID as required. So easy!

Here’s what it looks like. So much simpler and easier to understand. The other major benefit is that because your script does not terminate all variables and state you have defined in the script is still there just waiting. There is no need to create a script that is responsible for figuring out what was originally running before the modal dialog, because it is still running!

So, how do we do this?
It’s easier than you think. There is a really basic structure to the modal process that we use. First, lets look at what Script A might look like:

This is the typical structure of our initiating script. It calls our modal picker script, and immediately it grabs the result and deals with it. But in reality it’s not immediate. Our picker script can take quite some time to return that result, depending on how long the user farts about in selecting a contact! The key is that the modal script will enter a paused state waiting for the user to do whatever it is they need to do.

Here is the basic structure of our modal script:

We initiate the modal dialog, and then we enter this special loop. Inside the loop the script is paused.

The next line of code looks really out of place - how can we be obtaining a script result when no script was called? I hear lots of heads scratching here. Well, the thing that makes this all possible is the fact that any script the user calls now through clicking a button on the layout can return its result back to this script. So for example if the user clicks on a contact, or clicks a cancel button, whatever that script exits with is passed back here!

There is one thing that all scripts the user runs must do however. They must be set to resume the currently running script - that being our modal script.

Here is what one such button on the layout looks like. We’re running a special script called “Modal Decision”. We are passing the script a parameter that tells it what the user has clicked. Note that the option to Resume current script is used. If you don’t want a button or script run in the modal dialog to continue execution of the modal dialog, simply set it to keep the current script paused.

In this case, we’re passing our decision script a selected contact ID.

Here is our Modal Decision script:

Couldn’t be simpler! We just spit back out exactly what we got in. This tells our modal script what their decision was.

Recall back in our modal script. Once this script resumes it too returns the user decision, which is the contact ID. This ID thus flows back to our original script, where it is picked up and dealt with in script A that continues execution, so simple and elegant!

Why do we need the loop?

You’ll note that we have a loop in our modal script. In the example we just showed the loop is irrelevant and not used. But there are times when the user may make a decision in the modal dialog that requires some checks to be carried out before their decision is accepted.

Going back to our contact picker example, what if our dialog has the ability for the user to enter some details for a brand new contact? We might use global fields to allow user input. We may however have some requirements that a contact name is specified, or that an email address entered is in a valid format. These are checks that must be done before user decision is accepted.

It is in this loop that we can carry out those checks. When the user decision is received, we can carry out checks, and only if all checks are successful do we exit the script with the result. If checks fail, the loop simply repeats, putting the user back into the paused state, thus waiting for them to remedy their errors.

Here is one such example. The user has chosen to add a new contact, and we can assume they have attempted to fill out some global fields for the new contacts details. Upon resuming, this script does a check - have they entered a name for the new contact? If not, a custom dialog is shown to the user saying they need to enter a name, and they are taken back to the name field.

If that check does not happen, the alternative is to create the contact, and return the new contacts ID as the result. The new contact ID goes back to the original script.

So in Summary

Here is the basic flow of process for our modal structure:

1. Script A begins execution
2. Executes Modal Script
3. Modal script initialises dialog and pauses in a loop
4. User interacts with dialog, eventually making a decision
5. Decision is returned back to modal script to resume execution
6. Modal Script carries out checks, processes decision, and returns result if all checks are valid
7. Result returned back to Script A
8. Script A continues processing using the information returned from modal dialog.

We hope that this is pretty straightforward and easy enough to follow. The 3 main keys to this process are:

1. Entering a paused state in the modal script
2. Being able to detect what action user has done in modal script, by way of retrieving a script result
3. Being able to resume execution and return result back to originating script

A gotcha bout closing the modal window

With this method, one thing you may need to pay attention to is how a user cancels the modal dialog. A button is the easiest way, and have that button return a decision of “Cancel” back to your modal script to handle as required.

Because our modal dialog is paused, the standard “X” in the top left corner of the window to close will not work, nor will the standard close menu item. To work around this, you can add a custom menu to the modal layout. If you override the close menu item with your own decision script (the exact same one you would attach to your cancel button in the dialog) then you can work around this and close the dialog by using the menu item, or shortcut.

However because modal windows are designed to be modal, we would recommend the user have to explicitly press a cancel button if they wish to cancel the process.

Other benefits of this modal method

We have already covered the main reasons why this method of implementing a modal dialog is great - simple, reusable, and no need to terminate your parent script However one thing that is also great is something we touched upon right at the start of the article. Recall that FileMaker “Dialog” modal window is unable to execute scripts in other files while open? Well with this method you can do that, as well as spawn new temporary windows for use in your scripts, all while keeping the window truly modal.

Example File

Click here to download the example file

Workplace Innovation Platform

Sat, 10 Nov 2018 00:18:00 +1300

At the recent FileMaker DevCon conference in Grapevine, Texas, there was a very special announcement.

Over the past few years FileMaker has been working to find a category that best explains what it is and what it does.

For a long time it has sat in the 'no code - low code' category, which is all good and well, but for those who want to really extend FileMaker to its full potential, you really do need to know how to code.

So the announcement at DevCon centred around a new category that best suits and explains FileMaker, and that is the 'Workplace Innovation Platform’..

At Digital Fusion we love it, we believe it really symbolises what FileMaker is all about, and we are passionate about taking this category forward.

We are all about innovation, so to extend this into a category really helps with how we promote FileMaker to our current clients, but also how we can project it to new and interested clients.

Along with the new category name, FileMaker have come up with a lot of new branding material, along with some cool advertisements.

These are being showcased in the US and in other regions around the world, but you will potentially see them pop up on your YouTube and other social media feeds.

If you do miss them, we have embedded them below…

Better Breadcrumbs

Thu, 04 Oct 2018 00:00:00 +1300

Introduction

Breadcrumb menus are great. They tell the user a lot about where they are within a solutions hierarchy. They also provide a really quick and easy way to navigate up/down that hierarchy if needed. In the FileMaker world, people have been making breadcrumb menus in various forms for a while, the most common implementation is that of a repeating fields, button bars, or in the case of vertical menus, a portal.

And while all of these methods are workable, they tend to have limitations when it comes to 2 aspects - the visual quality of the menu, and the ability to customise and extend the menu. So what do we mean by these? We’ll start off by giving an example of a breadcrumb menu built using a button bar, discuss some of its limitations, and then present our alternative implementation using a tab control object.

Example file time!

BetterBreadcrumbs.zip

A typical breadcrumb menu

Here is an example of a standard breadcrumb menu. This is a location based menu, as the items in the menu are locations within the solution the user can navigate to.

The user currently resides at the right-most location in the menu, and as you scan to the left you can work your way back up the navigation hierarchy all the way to home screen. These navigation elements are clickable, so the user is free to traverse back up the hierarchy to any point they wish.

Building this in FileMaker

Many peoples first instinct would be to use a button bar to design and build a breadcrumb menu. It has a number of properties that suit a breadcrumb menu:

Multiple segments, each could be a step in the hierarchy
Clickable, as each segment is essentially a button
You can calculate the text to appear in each segment.

But here’s the problem. Button bars are of a fixed width, and the segments within the button bar are all proportional in width to the overall width of the bar itself. So if you have a 100pt wide button bar, with 10 segments, then each segment will be 10 pts wide. If you extend the width of the bar to 200pts, then each segment grows to 20pts in width. You have no control over the width of each individual segment.

So what does this mean for us in real terms?

Here is a crack at building a breadcrumb menu with a button bar. The issue we have is that each segment has a variable amount of text, yet we can only have a single width per segment. Add to this the fact that typical breadcrumb menus have a divider between each element, and you end up with a pretty average looking menu.

This is what it looks like in layout mode, to further illustrate whats going on.

Now, we have seen people come up with attempts to work around this fixed width segment issue. Some involve creating button bar segments based on calculations, where the text inside each segment is padded with spaces to make it a certain width, while others involve starting off with hundreds of small segments, and programmatically removing certain segments and padding others. The simple fact is these are all complex and a real pain to work with, and you still do not achieve a really beautiful result.

What about a tab control?

What’s that, I hear you ask? A tab control? Surely a tab is the last object you’d think of to build a breadcrumb menu right? Well maybe, but the fact is tab controls are the perfect layout object for building them (short of an actual breadcrumb menu layout object!).

The reason why tab controls are so great for this, is the simple fact that the width of each tab control name is variable in width. This means it doesn’t matter how much or how little text goes into each tab name, they won’t all end up the same width.

This is a tab control, designed to look like a breadcrumb menu. Looks pretty nice doesn’t it. Notice how all of the spacing between the dividers and the items are all consistent. So how is this done?

Here is the same tab control object highlighted in layout mode. The height of the overall object has been reduced such that there is actually no content space, it’s just the height of the tab names themselves. We aren’t going to be using this object for placing other objects in, we are only concerned with the names.

Let’s look at the tab control setup next.

Interesting! What we can see here is that the odd positions in the tab control are given the names of the items in the menu. Whilst the even positions are used for dividers. This is a key concept in our technique for building the menu - odd spaces are for items, even spaces are for separators.

The above setup is kind of useless in an actual solution because it is so hard-coded. Ideally you want the menu to be dynamic, and have elements add/remove as you traverse up/down the navigation hierarchy of your solution, but at this point we’re simply showing you the building blocks for how we structure the object.

We use the “Label width + Margin of” option for tab width, this allows tabs to grow as more text is added, whilst maintaining an even spacing between items and dividers. We are using an ascii character of a right arrow for the divider.

Formatting items

You’ll note that the first three items in the menu are underlined. This is to give visual indication to the user that these are clickable. The right-most element is not underlined, suggesting that is the screen they are current on, and there is no need for them to click that link.

Visual design is achieved through conditional formatting of each individual tab control. In this very basic example, the condition for the first 3 items is simply “true” and we format them to underlined. Again in reality we want to be a bit more dynamic in our conditional formatting, which we’ll cover later.

For a navigation breadcrumb, you may actually wish to simply go with a hard-coded menu such as the one above, and just adjust its display for each layout it appears on, and indeed this may be the easiest implementation. Other implementations may require a more soft-coded dynamic approach.

A simple example

In the example file we start off with a simple wizard example. Here we use a breadcrumb menu to indicate position in a step by step wizard.

This wizard has 5 steps, and the user will work their way through the wizard, and continue to the next section by clicking a button. The menu itself is not clickable, it exists purely as a visual aid to inform the user of their progress in the wizard.

We use the tab control for display of the menu, and we are using a slide-control beneath it for the wizard itself. So, the slide control has 5 panels and each panel is named Wizard_1 through Wizard_5.

The tab control setup is as follows:

Pretty simple stuff. Again odd positions for items, even positions are separators. Because the size of this wizard is known, we only need to add however many tabs are required for each step.

Navigation through the wizard is done by running a script. The script takes as a parameter a direction, be it forward or back. Depending on which direction, it updates the value of a global variable $$WIZARD_POSITION. We use this global variable to help us know which step of the wizard we are on. The script then simply navigates to the next or previous slide panel.

The breadcrumb menu now has to update visually to reflect the users position also. We know the position of the user based on the number in the global variable which will be between 1 and 5. The visual updating is done via conditional formatting, so let's take a look at that:

This is really easy. What we are looking at is the conditional formatting rule for the second position “Your Details”. We’re saying that if the user is at this position, or has gone past this position already, that it should be coloured.

Here the user is on step 4 “Interests”, and so the conditional formatting of items 1 through 4 are evaluated to true, and are coloured bold and green.

For the dividers, they are irrelevant in our example, so we can either always evaluate their conditional formatting to true (and assign them some property, in this case grey colour), or you can leave them without conditional formatting, in which case they will inherit the default formatting of the tab control object.

In this example, you’ll note that the text is black, and the dividers are grey, so we have a difference in formatting of the 2 types of tabs. In the interests of simplicity, we make the default tab text colour black, and we have applied conditional formatting to all dividers, to change them to grey.

Adding action to navigation items

More often than not, you want the user to be allowed to click an item in the navigation menu and run a script accordingly. We can achieve this in tab controls by using the OnPanelSwitch object trigger.

Here is the same wizard, although this time all sections can be navigated to at any point in time.

We start by altering the formatting so that all objects are underlined to begin with, indicating that they can be clicked. The other conditional formatting properties are the same as in the previous example, if the user is on a position, or that position is to the left of where the user currently is, we make it bold and green.

If we apply an OnPanelSwitch trigger to the tab control object, then our script will run regardless of which tab is chosen. An important piece of information we will use in the script is the position of the tab the user has clicked. This can be found by evaluating the first value in the function Get ( TriggerTargetPanel ).

There are 2 possible situations here. Firstly, the user may have clicked a divider. Our script will still run in this instance, so we must handle this situation. Recall all even positions are dividers, so we can check whether the clicked position is even. If it is then we return a FALSE result from the script, and the divider tab is not navigated to.

The only other scenario is the user has clicked on an actual item that they can navigate to. This will be an odd number. We must translate this number into the actual wizard position. We need to do this because of the dividers, they offset the clicked item.

To illustrate this consider clicking on “Immediate Family”. You know that this is the third position in the wizard, but it is actually the 5th position in the tab control. So we need to write a translation between the position chosen and the wizard position. It’s pretty straightforward and simply Ceiling ( $PositionClicked / 2 ). In our example, this would be 5/2 = 2.5, and taking the ceiling of this gives us a wizard position of 3.

Now that we know the wizard position, it’s just a case of setting our location to that value, and going to that sliding panel object, all done !

You can indeed write your own script to cater for any positional click in your menu, regardless of what you are using your menu for.

Abstracting item names into a table

Often times your wizard or menu items will exist in a table as records because you need to customise them, or build different menus for different purposes. In this example we’re going to show that you can still use the breadcrumb menu in this fashion.

Here is a table of records, each for a different section in the breadcrumb menu, and below is the breadcrumb menu. The 2 important bits of information in the table are the name of the item, and its position in the menu.

The beauty of using a tab control really stands out when using an abstracted menu like this. The menu will simply expand to accommodate variable lengths of text. In order for things to work smoothly there are just two things you need to be aware of:

Make the initial width of the tab object wide enough to cater for a worst case scenario length of menu.
Add enough tab control objects so that you are sure you have enough menu positions to cater for all the items that may end up in the menu.

Here is the tab control setup of this abstracted menu. Wow things are really getting interesting now! What you see there is a custom function which we have named @BREADCRUMB. It takes 2 parameters. The first is a keyword identifying which records in our wizard setup table to retrieve, and the second is the order number to retrieve. The 5 items in our table are all of type “Abstracted”, and are all numbered 1 through 5.

Here’s the custom function. It’s a simple executeSQL query where we retrieve names of items based on their type and order number, again nothing magical here just standard FileMaker.

The rest of the implementation is no different to our other examples. Conditional formatting for the items, and a script trigger for navigation.

Abstracting the formatting as well as the names

In this last example we show how you can tailor the formatting of individual items in the menu as well as their names. Now you could achieve this with conditional formatting again, but if you want a specific item to have a specific formatting you may wish to abstract this into a table of records to be based on actual items, rather than position in the menu.

This is a very similar example to the one above, with a slight exception that we have an additional field in our table containing an RGB function for the colour we want our item to be.

Here is the tab control setup for this example:

We have added in 9 different tabs here. In fact we add more than required in case more are needed. Because the items are abstracted to a menu, but adding more tabs, we ensure we don’t have to come back and potentially add more in future.

The other interesting thing to notice here is that we no longer are adding dividers into the even positions. It’s all just calls to a custom function called @BREADCRUMB_Formatted. This function is identical in behaviour to the earlier one, but this function does a couple more things

If the order number passed through is even, it returns the divider character
If the order number passed through is odd, it obtains the name of that item from corresponding record.
It also obtains the formatting properties from the record, and applies them to the name, using the Evaluate function.
It also determines using the wizard position $$WIZARD_POSITION whether to format the item, or whether to not format

So in this case, we are not using conditional formatting to determine whether to format an item or not, it is entirely done within the custom function. The formatting properties we use comes from the record itself.

The end result of this is that because we are only displaying text for items, we have full formatting control over how that looks using the text formatting functions. Here we are using slightly different colours for each item.

Tabs are awesome

The tab control object is just one of those cool objects that just keeps giving. We really love these breadcrumb menus and feel they have a really useful place in solutions. They can also be now made to look really professional and behave just like a breadcrumb menu should as well as being very easy to customise and format.

Example file again!

Breadcrumbs.zip

Credits

We'd like to thank Greig Jackson here at Digital Fusion for coming up with this method — nice work!

FileMaker Developer Certification

Sat, 22 Sep 2018 00:20:00 +1200

A little known fact about being part of the FileMaker community is that a large number of developers go through a rather rigorous FileMaker Certification exam. And that exam has to be sat each year for each new version of FileMaker.

At Digital Fusion we strongly believe that all our developers need to be current in the latest version of certification. That's important for many reasons:

It shows our clients we're professional and know our stuff
It encourages each developer to closely review each new version
It shows that we measure up against the bar FileMaker has set
It helps us ensure we are all on the same page

The exam isn’t easy either — even when you’ve done it several times! And it’s fair to say everyone gets a bit nervous in the lead up. To give you an idea of what it consists of, there are about 60 questions to be answered over a two hour period, examining all different aspects of the productline covering everything from programming techniques to design to server and security. It’s pretty thorough and detailed.

When we are employing new team members, we don’t specify that they must be certified, but we do expect that they have a crack at it fairly on so they/we can benchmark their knowledge. It can take 2 or 3 attempts before they nail it and can call themselves a FileMaker certified developer.

Developers by nature are a competitive sort so when a new certification exam is released, there is a bit of gamesmanship as to who goes first, who gets the best result. This is all very friendly but does mean there is good banter around the office.

“Being a certified FileMaker developer shows that you are a capable and competent developer who can utilise all of the features in the FileMaker product family to their fullest potential” Daniel, now certified in versions 8 to 17!

“Being a certified FileMaker developer brings my lanyard one step closer to the floor at DevCon" Paul Thomas - FileMaker Certified Developer version 16-17

FileMaker 14 Support Ending

Thu, 13 Sep 2018 00:00:00 +1200

As of the 21st of September, 2018, FileMaker, Inc. will discontinue the ongoing support of the FileMaker 14 platform.

What does this mean?

Firstly and probably most importantly, there will be no ongoing support or updates for the software. This means that if a bug is found (although unlikely) then it won’t be fixed, the software will remain as it is now.

Other things will happen, you will no longer be able to buy a license for 14 and you will not be able to downgrade to 14. Although these likely won't effect the vast majority of our clients, there are times when we come across old versions of databases that need assistance.

What should you do if you're currently using 14 still?

The simple answer is that you should be upgrading, preferably to FileMaker 17, the current version available.

The benefits of upgrade are well worth the costs (if any), you will experience greater speeds, you will take advantage of superior security, and you get to add features to your solution such as connecting external apps using the data API.

While there is no change of format — a FileMaker 14 database can be hosted on and accessed by FileMaker 17 without modification — you may need to make the jump to having your own dedicated server. That's because if you've got your databases hosted on a shared server, it will be no newer than FileMaker 14, and FileMaker 17 can not access files on 14 server. The reason for this change is that for security and licensing reasons FileMaker Inc. disallowed shared hosting from FileMaker 15 onwards. Moving to your own server is probably going to cost more and we're happy to advise on the options such as:

Your own server on premise
A dedicated server in the cloud (e.g. Amazon Web Services)
FileMaker Cloud

Moving to a dedicated server is not a bad thing, in the security of your database will be greatly enhanced.

If you are still on FileMaker 14 and below, do get in touch with us and we can build a plan to get you upgraded. We are happy to offer advice on whats needed, including what FileMaker licensing best suits your organisation.

Building a Multilingual App

Sat, 01 Sep 2018 09:23:00 +1200

Introduction

Multilingual - what do we mean by that? Well, “multi” means more than one, and “lingual” has its origins in the Latin word “lingua”, meaning language… err in other words we’re talking about a single solution that can speak more than one language :)

Why would you want many languages?

In most cases, a solution is developed using the most common language of the user of that solution. But what if the solution has many users across many geographic regions and who speak many different primary languages?

Being able to present a solution to a user in their native language is a real benefit and widens the market for a solution that you may sell as a product, or indeed any solution you develop to be used in many countries. Even within a single country many languages can be spoken so being able to give users the freedom to select their language of choice is going to greatly improve their user experience.

Is this for everyone?

In short, no. Building a multi-lingual solution takes time and planning. Once the key framework is in place for adding multiple languages it can be quite efficient to develop with but it will always be a slower to build than if you just ripped into development using a single language.

You need to think carefully about whether the solution you intend to build will ever potentially be used by individuals who may have a different native language to the one the solution is developed in, and whether you want to make that investment up front. It is much harder to make an existing solution into a multi-lingual one than it is to begin a solution from scratch to be multi-lingual.

Before we get into things, grab the example file!

For the remainder of this article we are going to use the associated example file as our reference. I strongly recommend you download the example file and have a look (and read) through it as you read this article. The example file includes many different scenarios that you will encounter in building a multi-lingual solution and also contains a lot of helpful information about each.

MultiLingual.zip

The first table is Languages

It’s pretty straightforward really. Each record in the language table is, yup you guessed it, a language.

As you can see above we have established three languages in our example. The information we capture is again very simple: name, abbreviation, icon and a flag field indicating whether this is the primary language in the solution. It is really up to you the developer as to how you decide which language a user is to use. Almost certainly this would involve having a User table, where each user stores their individual preference for what language they want to display the solution in upon opening the solution. If it is a brand new user however, or if the user has made no preference, then the default language can be used and set on startup.

The next table is Phrases

Think of a phrase as having no associated language, it is merely some form of written text within your solution, that you are going to be required to translate into a language. For example, a particular phrase may be a label for a name field, it may be a label on a button, a tab control, or it may be an item in a value list.

Phrases can also be for specific records. You may for example have a table in which you have records for your solutions navigation - each record being a link to a screen in your solution. These are going to need to be translated, so phrase records can be setup and linked directly to each record. We’ll cover more on these later, but for now think of a phrase as purely something to be translated.

Here in the table above we have the phrases setup in the example file. By looking at this you may start to have some light bulbs going off as to how we are going to achieve multilingual functionality through global variables.

In our phrase table we have essentially 3 different category fields named type, category and sub category. The description is purely for our own purposes to help the developer identify what the phrase is actually pertaining to.

The variable name that you see is a calculation and we build the name based upon the users nominated type, category and sub category.

We should point out here that this method of categorising your phrases is just one such way in which you can do this. This part of the process is entirely up to you the developer as to how you want to identify phrases, and thus how your variables are going to be named. You may simply want 2 categories, you may want none, or you may end up with more, it’s up to you.

Variable Names are really important!

So if you haven’t clicked by now, each phrase has an associated global variable name. The way in which we will do multiple languages, is to store into these global variables the translation of the phrase in that of the users chosen language.

This method requires that variable names be used throughout your solution, from calculations on button bars and tab controls, to merge fields on your layout, to within calculations and scripts - there is an element of hard coding throughout your solution of variable names.

We do this primarily for readability. Looking in the data viewer will give you the full list of all of the language based variables used so you can easily reference them. It also makes it easy when looking at layouts and calculations to ensuring you are using a correct global variable for a given purpose. At the end of the day, hard coding is going to be done, so we may as well make these as readable as possible.

But the drawback to this is that you must make sure you name your variables in such a way that you are happy with them, and that you are not going to go back and change the naming down the track. If you end up recategorising your phrases, it will mean you have to change variables names accordingly in your solution, which can be difficult if you don’t know where they are used. Applications like BaseElements and FMPerception can help with this.

If you wanted to make a modification to the framework, there is no reason why you couldn’t simply name your global variables by using a Unique record identifier (UUID) of the phrase record instead. The benefit is variable names won’t change as the UUID won’t change, but the drawback is your global variables become unintelligible and you cannot simply look at them to know what they are. That is why we go with human readable names.

The key takeaway here is to get your categorisation and naming convention correct early so that you're happy with it... and that you won’t change it!

And Finally, Translations

The final table we are going to require is called Translations. The translation table is simply a join table between Languages and Phrases. Each Phrase is going to have 1 Translation record per language. The translation record will store the actual translation of the phrase into the nominated language, and that’s pretty much it.

In our example file, we define are translations using a specially constructed portal as shown above. The portal is filtered based upon the user choosing a nominated language from a drop down above. What the portal shows is actually phrase records, but inside it we place a translation field. We have constructed a special relationship with “allow creation of records in this table via this relationship” enabled. This makes it really easy for us to define the translations for every phrase for a chosen language. We simply change the drop-down to the next language and then we can create our translation records for that language.

Above we display the type of phrase record, its descriptions and categories, and its variable name so that we clearly know what it is we are translating.

Putting it all together - the basics of the framework

So that’s about it really for the table structure of our framework, it simply consists of 3 tables - Languages, Phrases, and Translations.

The next stage of the framework is defining all of our phrase global variables for a given language, so lets look at how we achieve this.

How variables are defined

We saw earlier that global variable names are defined on the phrase table. It’s a calculation, and we are using our category names to define our variable name. We also strip out any spaces or illegal characters from the variable name, replacing with underscores.

When your solution is opened, as part of the startup procedure, we will be required to define all of our global variables and give them a value for a given language. So we should at the very least know the language we want to use - this will either be the system default language, or a language based on user preference.

In our example file we have 3 key scripts responsible for management of languages. The first “Load Language” is really the only script you require. You pass it the primary key ID of a language to load, and it does so. The other two scripts are helper sub-scripts.

The basic process of Load Language is:

Obtain a list of all of the variable declarations for given language
Evaluate these declarations, thus loading them as actual global variables.

And that’s all, pretty simple really.

Variable Declarations

So, we know the language we want, and so using this knowledge we can find all translation records for that language. On each translation record we have 2 special calculation fields, named variable_set and variable_clear.

What these calculation fields are defining is a string which represents either setting the global variable to the value of the translation record, or simply setting the global variable to empty.

As an example, here is the variable_set calculation:

PHRASES::variable & " = " & Quote ( value ) & " ;"

We grab the associated variable name from the phrase, stick in an “=“ sign, and then he translated value in quotes, followed by a semicolon. This is exactly how we would write it if we were defining this global variable in a LET Statement, and in fact that is exactly what we are going to do. We are going to build up a Let statement containing all of our global variables declared to their translated values, and then run that statement using the “Evaluate” function.

This is what the 2 helper scripts achieve, they help retrieve all of the required variable declarations, and then build the LET statement before finally executing it.

How it actually achieves that is something we’ll leave up to you all to explore in the example file. The scripts are designed to help load all the variables successfully. One limitation is that of the size of a calculations definition. To overcome this for large solutions which may have thousands of translations, we chunk declarations into no more than 500 at a time, so that we never hit the limit of a calculations definition.

To cut a long story short, this is what we get…

After calling our Load language script, what we end up with is something like this:

This is our data viewers current tab, and inside it you can see all of our global variables loaded up with words. Note that we use the LANG prefix on all global variables that are to do with the language of the solution, this just helps us keep them all grouped together.

We also store the ID of the selected language in a special global $$LANGUAGE.SELECTED_ID . This has benefits later on which help us overcome some other challenges with multi-lingual implementation, so it is important to know at all times what the current language is.

There are also some special META variables defined. This is loading in information about the current language which we may wish to display on-screen to the user. They’re loaded in as variables in case they ever need to be used, but they are not critical.

What are these?

You may note that at the bottom of the list of global variables are some odd looking variable names:

They certainly are not the categories we have defined for our phrases, so what are they?

These are special translations that are not for text that may appear on a layout directly (such as a label, tab or button). They are translations for words that exist in records within the solution. In fact this is one of the challenges of a multi-lingual solution that must be overcome - there are often times that data residing on records within a solution need to be translated.

What type of record data are we talking about?

It is very important here to make a distinction about what kind of record data we’re talking about translating. We are NOT talking about user-entered record data. We have no control over what data a user will type into a text field for example, and so we simply cannot provide translations for every possible thing they may type, that is ludicrous!

What we are talking about here is record data that we know exactly what it is, and that will not change. Typically this is record data for use in value lists for example, or record data for user interface purposes, such as a navigation portal. Both of these examples are covered in the example file using this method, and we’ll talk about these a bit more later.

Defining a “Record” type Phrase.

Previously we were just talking about phrases for standard text in your solution on layouts, buttons and so forth. They were defined using categories. Record phrases however are defined using the Primary Key ID of the record that is being translated, along with a special keyword to identify what it is on that record we are translating. Our phrase table has a type field named “phrase_type” that is set to either “Variable” or “Record” which helps us define what type of phrase it is.

For record based phrases, we still use the category fields, but instead, our primary category is the ID of the record being translated, and the sub category is keyword to help identify what on that record is being translated. The keyword is important because there may be times where a record has more than one field that requires translation ,so the keyword helps create different variable names for each field being translated on that record.

Okay, time for a quick recap!

We’re about halfway through now, so lets just quickly recap what we have covered:

3 tables - Languages, Phrases, and Translation
For a given language, we generate global variables, 1 per phrase, that contain the translated word for chosen language
We can then use these global variables throughout solution where required, e.g. labels, buttons, tabs, calculations, scripts etc.
We have special global variables that are tied to a record/field to be translated (more on this shortly).

So it all boils down to a pretty simple framework really.

Let’s see it in action

Here’s an example of a layout that uses the global variables:

You can see some merge-variables used for the field labels. The buttons (which are button bar segments) have calculated values set to global variables. The tab names are calculated global variables. And even the merge field contact_display_title makes use of a global variable.

This is a great example actually of how we achieve multi-language in calculations. Lets look at that calculation in more detail:

We have a contact chosen. We start by getting their name. We also grab the translation of a special phrase used if no contact name is provided. Next, we take another phrase we use for the string, and we replace a piece of defined placeholder text <<NAME>> with a value, that is either the contacts name, or our special “no name” phrase.

If we look at the phrase definitions used:

You can see in the first phrase we have our <<NAME>> placeholder. This is how we can insert actual record data into a translated piece of text.

The second translation is what we will display if a contact has not been given a name. Here is what it looks like in browse mode:

Pretty cool huh?!

Keeping data-entry as simple and universal as possible

Now we are going to get into some of the more challenging aspects of multi-lingual solutions, the first of which is value lists.

But before we get stuck in we need to be clear in our understanding of what is translatable in a solution, and what is not. Earlier we stated that no user-entered record data will be translated and we stand by that. You simply cannot provide a translation for what a user will type in as data on a record. For example, if you have an english-speaking user enter contact names, then those contact names are almost certainly going to be in english. If you have a Chinese person enter contact names, then they’re going to enter them in Chinese. Differences in the languages of entered data is something you just have to live with in a solution.

There are some situations however, with careful planning that you can avoid these conflicts by being smart about the format of data that users are entering. So what do we mean by this?

Lets say you have a field in your database called “Test Complete”. This is a straightforward boolean field with either a yes or no response. The user chooses a value using a value list.

One way of data entry would be to provide the user with a value list of “Yes” and “No”. These are english words, and if you do that then the user is actually entering english words in as data onto that record. Then, what if a Chinese person then wants to enter data? Will they know the meaning of Yes and No in the value list?

The solution to this problem is to at all possible opportunities come up with a universally recognised method of data entry that has the same underlying meaning across all languages.

In this case, don’t use words. Instead, use a check-box. Store a “1” as a yes response, and store an empty value as a “No” response. Present it as a check-box to the user. Everyone understands the concept of a ticked box meaning “Yes” versus an unticked meaning “No” regardless of their language of choice.

By providing the user with a visual means of data entry, like a check-box, versus a textual means of data entry like words, it means the method of entry becomes universally accepted and understood, and you remove any confusion you would otherwise have by presenting words to the user. The users need never see the actual underling fields value, providing it is always visually presented in a universally accepted format.

For times when this is not possible, a value list is required

Check-boxes are the main example for where you can universalise data entry. Another would be using colours for things like a priority value. But generally you will have to display a value list to the user for the purposes of selecting a value. So how do we present a value list in a users native language?

One problem we have in FileMaker is that if a value is chosen in one language, then the value will not appear in a value list based on a different language.

The solution is to think about storing where possible the primary key record ID’s, instead of the actual textual value.

Here is a great example of this - selecting a country. A country will always be the same country regardless of its name - the name is just a means to identify it. So if you need to select a country on a record, why not just create a table of countries, and store the ID of that country record? This is another way in which you can universalise the data entered. A primary Key is a primary key in any language, and in most solutions we develop users will never be exposed to a primary key value anyway, to them it is meaningless.

If value lists become tools for selecting primary key IDs, then what the user actually see is purely a visual component, and something we can manipulate to display in the users chosen language, and that is exactly what we do!

Again, it is important to note, we’re talking here about record data that is known, and not likely to change or be modified by a user. We can easily build a table of countries and base a value list off that. If instead we were to build a value list of contacts names and IDs, then we cannot translate contact names, and so a user in any language will always see just the names as they were entered onto contact records.

In our example file, we have a table of countries on the left. Each country has an ID, and a name. The name in this case is purely to help identify the record, and is likely to be in the developers native language. We won’t actually be using the country name on this record for display in a value list, instead we’ll be displaying a translation of that name instead.

The table on the right is phrases, and we have 1 phrase record per country record. We link the phrase record to the country record through the countries primary key. We are using a keyword “country” as the phrase identifier.

We define translations for the phrases in the exact same way we did previously:

But in this case you’ll note we are dealing with phrases that are of type “record”. The variable name contains the countries primary key value, and a keyword “country”.

Defining the Value List

This is not trivial unfortunately, and it’s a bit of extra leg-word to get the value list properly setup, but once done, it is really cool, promise!

Think about what the value list actually needs to contain:

The ID’s of Country records
Displaying the translated value, from the translation records.

The country ID resides on Phrase records, and the names reside on translation records. So in our definition of the value list, we need to relate to all phrase records that are for countries, and then relate to the translations for the selected language.

Here is the first relationship, from our base table occurrence (which could be anything really), to phrases. We have 2 predicates. The first is finding all phrase records for a specific set of primary key values (country IDs), and the second is linking to the specific keyword which is “Country”.

In fact, this is a bit overkill. If we wanted, we could actually just relate on the keyword “country” providing it is unique. However the reason we do it as above is by relating to a specific set of records matching on ID’s, we don’t necessarily have to have a value list based on every phrase record for countries. We could control which countries are in our value list based on which ID’s we have on the left hand side of the relationship.

In this case however the field “country_ids” on the left is basically a return-delimited list of every country primary key ID.

Okay, so we have now a relationship to all phrase records for countries. This serves as the basis of the first field in our value list. We will be using “category_primary” as the first field. Recall this field actually contains the country ID.

Next, we have a relationship to translations. We first match on phrase so that we are only getting translations for the given phrase record. We then must filter further to the specific translation record for the language the user is currently viewing the solution in.

Recall earlier we defined a global variable $$LANGUAGE_SELECTED_ID. We are now going to use that in the calculation field _CURRENT_LANGUAGE. This calculation simply contains a reference to the global variable. Each time the language is changed by the user, the value of this calculation changes, and thus the relationship to specific translations changes to just those for the user chosen language.

Here is our value list definition:

As you can see, the first value is the country ID, second value is the associated translated country name for the users chosen language.

We only show the displayed value, the user has no reason to see the ID or care that they are actually selecting an ID.

Putting it all together here is what it looks like, first in English:

and then in German:

Note that regardless of the language chosen, the actual country chosen remains ticked in the value list and is displayed to the user in their chosen language.

Phew! We made it!

Value lists are tricky, and are indeed what we believe to be the most tricky part of a multi lingual solution. But they are possible and once you get the hang of how it works actually quite easily to setup and use.

The next example is very similar to value lists as it involves displaying record data however this time it is not data the user is going to be entering into a field, it’s purely a visual/user interface thing.

Translating data in records for layout display

Often we’ll want to translate record data to the user where the record data is used as part of the interface. A classic example is building a portal-based navigation system, where the labels of screens will exist as data in a table.

Here is a simple portal containing records from a Navigation table. Each record corresponds to a layout in the solution the user can go to, or a function the user can do, such as logout.

Here is our table setup and phrase setup. This is identical to that of the value list setup. We have a navigation table on the left. The screen name here is purely for the developer to help identify what record is what.

The phrase table on the right has 1 phrase record per navigation record, with an identifier “navigation”, and description.

Now, you may wonder why even bother with a navigation table, why not just put your navigation directly into the phrase table? Well there is no reason as to why you couldn’t do this. You could simply treat the “Navigation” records in the phrase table as your actual navigation records. The reason why we don’t do this is we wan’t to keep the language, phrase and translation tables purely for multi-lingual purposes. We don’t want to clutter them with user interface elements or value list data. This is why in both the value list and this example we still have a separate table containing value list data and record display data.

Anyways, back to the example!

Once again, the exact same setup of translations as before, we just choose a language and define the translation. Note the variable names here again contain the navigation ID and keyword.

Making use of having the ID in the variable name

We now finally can make use of having the record ID’s contained within the variable name. In the value list example while we still had variables declared for countries, we didn’t actually use them for the purposes of the value list. However in this instance we are going to make use of them.

Given a navigation record, we know what its ID is. We also know that it is for navigation. These 2 pieces of information should allow us to calculate what the global variable name associated with the record is. We know all language variables begin with $$LANG. We also know that the ID follows this in the variable name, and we know the Navigation keyword is on the end.

To help us obtain the correct global variable, we have built a custom function, named @LANGUAGE_GetRecordTranslation

This function receives 2 parameters - the ID and the keyword identifier.

The function recreates what the name of the corresponding global variable should be, and then returns its value by evaluating it.

We know that all spaces and hyphens are replaced with underscores when the variables are defined, so we build these same rules into this custom function to help reconstruct the variable name.

And that’s it, pretty simple! We can use this custom function in a calculation field directly on the Navigation table, and here it is:

We run the custom function, telling it the navigation ID, and the keyword “Navigation”, and it will in turn give us the translated name of the navigation record, in the users currently selected language, brilliant!

That concludes the technical stuff

Congratulations, you made it! Pat yourself on the back! We hope that wasn’t too confusing for you. The basic concept of the framework is simply to follow, it’s just setting a bunch of words into global variables and then using those variables in your solution.

The two gotcha areas are value lists, and translating data on records, but we have found ways to solve both of these issues. In building real world multi-lingual solutions these were the only 2 complications and so we don’t anticipate many other issues….

However…..

There are actually other things you need to consider in building a multi-lingual solution. These are non-technical but you must be aware of them and be thinking about them as you develop.

No two words are created equal

In english, the word “Settings” is 8 characters long. In German - according to Google Translate - it is 17 ! (die Einstellungen)

The implication of this is that if you are placing any text on your layout you must consider the variable widths of words in different languages. If you place a label to the left of a field, then that label may look fine in English, but in German you may find the label is longer, and overlaps the field.

You need to be smart about text placement. For labels, consider placing them above the field instead of to the left. By placing them above, you are giving yourself much more room to accommodate labels that are wider or shorter in different languages.

Don’t rely on an online translator service

For this example file, we used Google Translate. Almost certainly the words are not 100% correct for the German and Spanish translations and for that we apologise. If you are building a real world multi-lingual solution, we could encourage you to enlist the help of someone who speaks the language that you are translating into, to assist with the translations. There is no substitute for someone who knows the language.

Plan your phrase naming convention early

This was touched upon earlier but needs to be reiterated. Make sure you come up with a good naming convention for your phrases early on in development that you are happy with. These serve the basis of your global variable names that you are going to be hard-coding throughout your solution, so make sure you don’t need to change their names down the track!

And finally, have fun!

Building a multi-lingual solution is challenging but incredibly rewarding. There is no sweeter feeling than selecting a different language and seeing your entire solution instantly change before your eyes, it is simply magic. Enjoy the process!

Extra Bonus - Making your Framework even better

If your solution runs server-side, consider making use of this when it comes time to load in your global variables. Depending on the size of your solution, retrieving all of the global variable declarations can be time consuming. This part of the process can quickly be handled by server using the Perform Script on Server script step. Ask server to get you a list of the required variable declarations so that you can load them in locally. This will help improve the speed of selecting a different language.

The scripts in this example file have PSOS capabilities built into them and are controlled by passing through a parameter to the script to indicate you want to use server-side processes.

Example File

If you made it all the way here without having downloaded and looked at the example file then hats off to you, it must have been a tough read! You can download the example file below which we would strongly encourage. It’s always better to see something in action and then figure out how it works than to try and read how it works before diving in.

MultiLingual.zip

R&D Tax Credits in New Zealand

Mon, 18 Jun 2018 00:00:00 +1200

There’s no doubt that a huge opportunity exists in many businesses to dramatically improve productivity, or even completely disrupt an industry, by using technology and innovation. Doing so takes vision and guts, of which we have plenty in NZ.

However “Vision and Guts” aren’t quite enough — you’ll undoubtedly need some Money…

Spare capital is in notoriously short supply especially if you’re a startup or small company with modest means, but those are exactly the kinds of businesses that are hungry for growth and looking for opportunities. In fact I think this is where true entrepreneurship lurks…

Enter a new government keen to stamp their mark on the landscape and lift NZ’s meagre level of investment in R&D (1.28% of GDP). The aim doesn’t particularly ambitious though: over 10 years the hope is to raise that level of investment to 2% of GDP, which is still well below the OECD average of 2.38%. In a nutshell we invest about half as much as our peers and even with 10 years of ramping that up we’re still not expecting meet the average!

So to help kick things along they’re bringing in a new R&D Tax Rebate that takes effect from 1 April 2019. It works like this, I believe:

You can claim 12.5% of the value spent on a specified R&D project as a tax rebate. So you spend $100,000 on investigating and building an innovative new "Thingamabob" and you get to take $12,500 off your tax bill, which is quite nice.

While the government is committed to making the scheme happen from that date, exactly what it will look like isn’t entirely locked down yet. There’s a discussion paper that has been made publicly available and from that will come further discussion and possibly some changes before it’s drafted into the laws of the land.

Custom Software Development?

We’re particularly interested in the whole concept because we think a lot of projects your projects with us might qualify — after all what we do is build innovative new technological solutions that help business take on the world. Most projects we do involve determining a new approach (your research and ideas), and development on our part. As the owners of such projects, it would of course be you, our clients, that get the rebate — but that’s good for us too because it reduces the real cost of taking the plunge.

Things To Know

While the scheme is still only in proposal form we can see a few catches and things to bear in mind — here are 5 key aspects to keep in mind:

1. Scientific Method

The current proposal includes a requirement that projects should adhere to “the scientific method”, which as I understand it means:

“A systematic progression of work, that proceeds from hypothesis to experiment, observation and evaluation, and to logical conclusions.”

Basically, a fair degree of discovery as you try things is to be expected and worked through in a logical way. The outcomes are somewhat uncertain at the beginning and will depend on what’s learned along the way

Each project we work on is innovative and different, and they always evolve and change with testing and trial — which does seem to fit the definition of the “scientific method”.

2. Minimum Spend $100k

Another catch is that you need to spend $100,000 in a financial year to qualify. That said there is also mention that certain suppliers might be deemed “Approved Research Providers” and that when using such a supplier you may still be able to claim the rebate without necessarily spending the $100k minimum.

3. Special Treatment for Software

The paper is also a little vague on software R&D projects specifically:

I think that’s a positive sign though because when clearly around half the R&D spend is going on software it needs to be well defined and clear what types of software development and which parts of the activity will qualify.

4. For Profitable Companies Only?

Another thing to bear in mind is that this type of funding is not a capital-injection and there’s an obvious rub with it right from the outset: you need to have tax to pay (i.e. be making a profit) in order to receive the benefit.

So as it stands this scheme is not going to suit the innovative high growth startup type business that takes several years of mad growth before turning a profit. However the plan is to address that issue the following year (2020) but for now finding a way to provide benefit to non-profitable companies is in the too hard basket.

5. Qualifying Expenditure

The discussion paper gives a couple of ways of defining what type of expenditure might be able to be included, but the good thing is that it looks like it will include both your own in-house costs, especially direct wages and resources used, plus external contractors such as us.

Conclusion

While we don’t profess to be experts and would advise you seek legal or financial advice before making any bets on this, we think the ideas here are an interesting start for at least one approach. What would also help would be the ability to fully expense R&D investments, particularly in software development of course, in the year they’re incurred.

My take on it is that this scheme will make some modest benefits available to a much wider group of companies than the previous systems, but it’s not startling — more “useful and encouraging”, which is probably ideal because what we really need is to build a culture of reinvesting in our businesses to improve and grow through productivity and innovation not just more man-power and number 8 wire.

FileMaker 17 Released

Wed, 16 May 2018 02:51:00 +1200

It’s that time of year again — when FileMaker Inc bestow upon the world the latest major update to the database platform we know and love. Funny how quickly this has become a practice: the annual update cycle… and personally I think it’s a great thing because not only can we plan for it reliably, but it also ensures the platform keeps moving forward at a steady pace.

No doubt there are a few key questions in your mind if you’re running a business on a FileMaker database application, like:

Why upgrade?
What’s new this year?
Will there be any issues?

So let's take a look...

Why upgrade?

First off, with most people on a subscription type license now there’s no extra cost to upgrade, meaning there’s no financial reason not to.

Importantly, new versions always include a lot of non-critical fixes and functional enhancements that don’t really make the headlines. A number of minor issues surface through the year and these get rolled into the next major release.

Each new version always brings under the hood tweaks that make it faster, more robust and secure too — and those are qualities that we’re always looking at now with cloud hosting and access over the internet being the norm.

So our advice? Keep with the times!

What’s new this year?

So aside from the general improvements and keeping up with the times, what is actually new this year? Well the definitive list of new features can be found here:

https://fmhelp.filemaker.com/

And we’d like to highlight a few that we think are the top 5 most important:

1. Data Migration Tool

This is going to make deploying a database update 100x easier!

With the “DMT” you can develop separately from your production or live database, then complete testing (and fixing!), before deployment. Moreover deployment can be achieved without having to write complex data import scripts — scripts which often take hours or even days to complete on big databases.

DMT opens up a world of opportunities because FileMaker solutions can now be productised more easily: if you’ve got hundreds of people (or even just 2) using copies of your database app, then there needs to be an easy way to issue and update and this tool helps solve that problem.

It’s also going to be handy when fixing damaged databases because we can very quickly grab an empty clone (FileMaker Server should be set up to create a backup clone each night), then use the DMT to rapidly copy data from the corrupt database into the good clone. The DMT will fix broken records if it can.

2. Access to more sensors in iPhones and iPad

It’s almost scary how much your phone can know about the environment it’s in — from how many steps you’ve taken, to which direction it’s facing and whether it’s accelerating due to gravity, i.e. about to bounce on the concrete. I say ‘almost’ scary because thankfully Apple have built in protocols to ensure these sensors can only be accessed by apps if you allow them, and the good news is we can now access a whole lot more of the sensors from FileMaker database apps.

Aside from being a bit of fun, a key way to make mobile apps more usable is to have the application automatically read as much data as it can — Location is of course a good starting point, but we can now determine altitude, speed and acceleration, air pressure, step counts, and battery level.

3. Notifications for iPhone and iPad

Another handy features is the ability for apps to queue up notifications on the device — much like calendar reminders.

Paired with the GeoFencing functionality this can be used to alert the user when they enter or leave an area or approach an iBeacon (useful for locating very specific points or objects).

4. Data API — with scripts

FileMaker has always offered a really good number of ways to connect with the outside world, and now with the “FileMaker Data API” — first introduced in a cut down beta form last year, fully fledged and ready for use we have THE industry standard way to make FileMaker data available to other services including a website.

The Data API now supports scripts and images, for example if you have a website that needs to upload an image to FileMaker then run a script to process that it can all be done through this standardised and secure interface to the world.

5. Account Lockout

This is an important security enhancement because it helps stop automated ‘cracking’ attempts, a real risk when you have a database app hosted in the cloud or available over the public internet.

Basically all it does is lock the account (user name) being attempted if several password attempts fail in quick succession. After a few minutes, it’ll reset and you can try again if you’re legitimately trying to get in…

Will there be any issues upgrading?

We’re not anticipating any problems at all, particularly for people switching up from FileMaker 16, but being a new release we generally recommend customers sit tight for a couple of weeks just to see if anything emerges before running the updates.

We’ll be emailing all our customers with the news of the release and advice on when to go ahead and upgrade… each case might be slightly different so if you're in any doubt, give us a bell and we can advise...

support@teamdf.com

Introducing Paul Thomas

Tue, 16 Jan 2018 14:34:00 +1300

It’s not every day that we get to take on a new developer with a wealth of experience, so when one comes knocking at your door, you sit up and pay attention.

This is what happened when our latest team member, Paul Thomas came knocking and we jumped at the chance to take him on.

Paul (or PT as he is referred to around the office) comes to us with over 10 years FileMaker experience at AA Tourism.

Being the sole developer at AA Tourism meant that he was a ‘jack of all trades’ which lends itself nicely to the sort of role he will have at Digital Fusion. We will be able to call upon his skills in designing and developing iOS apps in FileMaker Go, beautiful desktop apps in FileMaker Pro, and giving access to core user groups via FileMaker WebDirect.

Outside of work, Paul is married with three children, two dogs and like most developers, gaming is top of the list of hobbies.

Welcome aboard Paul!

Swipe Out!

Wed, 13 Dec 2017 04:39:00 +1300

Introduction

In our previous article, we built beautiful drawer menus for desktop and iOS. These menus were horizontal in that they would slide in from either the left or right side of screen. This is achieved either through using a slide panel object, or through layout transition effects available in FileMaker Go (if you wish to have your menu as a separate layout). The sliding panel layout object gives us the power to use left/right swipe gesturing to close (or open) the menu.

But what about vertical menus? That being a menu that slides up from the bottom of screen. In FileMaker Go you can achieve this effect through using the ‘Slide in from Bottom’ layout transition - brilliant! The user can then press a close button on the menu to reverse the process through using a ‘Slide out to Bottom’ transition effect, returning the user to their original layout.

However one key element is missing from this equation which provides a much more intuitive and native iOS feel to this menu - the ability to swipe-down on the screen with your finger in order to dismiss the menu. In our horizontal menus, left and right swiping can be utilised through a panel control, but how do we achieve swipe down (or up for that matter)?

First attempt using a sliding panel

When this challenge initially arose my first thought was to just use a sliding panel again. It already has swipe gesture, so surely there is a way to ‘flip it on its side’, right?

Unfortunately not! The rotate option is not supported for slide panels in FileMaker Pro - dang! But wait! All layout objects are just somes FileMaker XML and CSS underneath it all, so what if I could just modify that XML to add my own rotation? To do this, I used myFMButler Clip Manager to retrieve and modify the XML:

The rotation attribute can be seen above, we just modify it from 0 to 900 in order to rotate 90 degrees.

Voilà! Now we’re cooking! But does it work? Well yes and no. It works in the sense that you can click the dots to navigate the panels and you can script moving between panels. However actually putting anything useful inside the panel becomes a nightmare. If you copy/paste something simple like a label inside the panel, you’ll note it immediately rotates 90 degrees also to be in the same orientation as the panel. You can then rotate it again to have it correctly oriented. This is fine for simple things, but for more complex menus this becomes a real challenge to have the objects properly rotated and positioned.

And then there is the positioning of objects. Using the keyboard it is somewhat manageable but given the rotation of the panel, all the directions are also rotated. So the up arrow moves an object right, the right arrow moves it down, and so on. But once you reach for the mouse and drag the object, then things reach a whole other level of weird as illustrated in this short video below.

So basically the panel was a no go. Couple with the fact that when the panel was tried in FileMaker Go, the swipe gestures were still left & right even after it was rotated - the final nail in the coffin.

Back to the drawing board…

So now what? How else can we do a swipe down gesture? Other possibilities arose such as using the onGestureTap trigger, but this only capture finger taps, not swipes.

Then I thought of this:

It’s called the rubber band effect, and is an effect that has been in FileMaker Pro/Go for a few versions now. (FULL DISCLOSURE: I am completely ignorant of FileMaker on Windows so have no idea if this is present there).

In FileMaker when using a scrolling device in FileMaker Pro or your finger in FileMaker Go, you can effectively drag the layout down/up beyond its normal position. When you release your scrolling device, the layout ‘bounces back’ to its original position. A seemingly useless artefact of the operating system one would presume, particularly when it relates to FileMaker Pro and seemingly has no use. This rubber band scrolling was first introduced with the original iPhone (you can read all about it on Cult of Mac)

In more recent times however this rubber band effect has been utilised as a method to perform some secondary action in iOS apps. Most notable of those is to refresh the current view. Apps like Instagram, Facebook and Strava to name a few all utilise this swipe-down-and-release to refresh the current page.

But can we use it in FileMaker?

That was the 64 million dollar question. This is as close (currently) to a swipe-down effect as we have. Can it be utilised to somehow perform a script when the user swipes down to produce the rubber band effect?

To make any use of it, we need to be able to detect when the rubber band effect is being performed, and secondary to that, we need to be able to control at which point during the effect we should be triggering a script to perform an action, in this case closing the menu.

GetLayoutObjectAttribute provides the solution

Our trusted friend - GetLayoutObjectAttribute - comes through in the clutch for us yet again. This handy function can tell us some useful properties of layout objects. In this case we use the “Top” coordinate property of a layout object.

On our layout, we place an object. It doesn’t really matter where on the layout it is placed, or what type of object it is. Give that layout object a name. Now we can use GetLayoutObjectAttribute ( “ObjectName” ; “Top” ) to determine where that object is relative to the top of the window.

The key point here is that the top attribute of a layout object changes during the rubber band effect. As the layout is moved down the screen, all of the top coordinates of objects on the layout increase. Conversely, they decrease as the layout is swiped up - even into negative coordinates for those that go above the top of the screen.

So to recap: When you first go to the layout, the object will have a top coordinate. Then, as you drag the layout down, the top coordinate of that object increases. Are you beginning to see how this can be useful?

An onTimer pulls everything together

Knowing that the top coordinate increases is not quite enough. We need some means by which to detect when the top coordinate hits a given value, and to run a script at that point. There is no such thing as “onRubberBandEffect” trigger sadly!

To do this we use an onTimer script. When the user first enters the menu layout, we install an onTimer to run every 0.1 seconds. This script is tasked with checking the top coordinate of our special object and waiting for it to reach a certain value. When that value is reached the script performs the desired action - in this case closing the menu.

For all of this to work smoothly, our onTimer script should not reference, or set any record data. It should also be doing no heavy lifting such as refreshing the window or committing records. These actions would cause slight pauses in the script execution and create a bad user experience because the user will see that there is something running in the background.

Fortunately in this case our script can be very light weight - all it does is evaluate the GetLayoutObjectAttribute function, and check to see if it is at a given value, if not, it does nothing. Given this is so quick and low cost, the user has no visual indication that a script is running at all which is exactly what we want!

What does our onTimer script do?

The purpose of the onTimer script is pretty simple, and can be summarised as below:

When the menu loads, store the layout objects top coordinate for future use
Subsequently, compare the current top coordinate of the object with its original coordinate
When the top coordinate hits a nominated value greater than the original coordinate, close the menu

And that’s it, pretty simple!

To illustrate what the top coordinate is doing, have a look at the video below which shows our demo file in action. As we drag down with our finger, you’ll see the top coordinate value at the top of screen increase. When it hits our designated position, we close the menu, and thats all there is to it!

Well, not quite all there is to it, there is one more thing

Not all layouts exhibit the rubber band effect. Your layout has to be setup in just the right away in order to produce the rubber band effect. The rubber band effect only appears when the layout is scrollable and so if your layout dimensions are too perfect (i.e. they match exactly your devices dimensions) then you may not end up with any scrolling at all.

The answer is to make your layout just slightly taller than the default height by a few points. Not enough to give any hint of a scroll bar, but just enough to introduce the rubber band effect. You don’t need this on every layout, just those where you want to utilise this technique.

Other potential uses

I hope this article has sparked some other ideas and potential uses for you. One such idea we thought of would be to replicate a native applications use of the rubber band effect to carry out a refresh action. You may be developing an offline solution which pulls data from a remote location, or your layout might simply require a ‘refresh window’ every so often to keep it up to date.

Native apps tend to put an icon in the refresh area that reveals itself during the rubber band effect. Can we do the same in FileMaker? Well surprisingly again the answer is yes!

This grey area shown above that reveals itself during the effect is actually the ‘layout background’ style.

It is accessed by making sure no other object or part is selected on your layout. Options are fairly limited and you only really have a fill option. One of the fill options however is to use an image. If you use an image as your layout background then this image reveals itself as you drag down on the layout!

Simply set your background image to one with a reload icon positioned at the top of it, and this should appear as you drag. In the video below we show what this looks like. Our background image is relatively the same size as our device screen. Most of the image is a transparent png, with a little refresh icon at the top of the image.

Pretty nifty huh?

Finally a nice wee gem in the Demo file

I’ve included a bonus technique inside the demo file (completely unrelated but equally awesome). The technique is very simple and is an easy way to render SVG animations inside a web viewer. Check out http://loading.io to accompany this - a very awesome website with some amazing tools to use in conjunction with this technique. Give your solutions a bit more vibrancy and visual feedback.

Demo file

No weetbicks article would be complete without a demo file to accompany it. You can download the demo file below. Once you’ve read the article everything should be fairly straightforward and make sense. Just note that to really get the most out of demonstrating the technique you should be using it on an iPhone or iPod touch. While Macs also have the rubber band effect, it doesn’t really work that great on a laptop or desktop - this really is an iOS technique only.

Click here to download the demo file

Master and Apprentice - Queenstown Marathon

Tue, 21 Nov 2017 15:54:00 +1300

As the sales guy, I spread the myth that the developer sorts are just geeks, who at the whiff of fresh air or sunlight head back inside to keep coding.

On the contrary though, at Digital Fusion there’s an underbelly of rebel runners and none more so than the godfather, Stephen Baker.

To sum up Steve, some say he runs more kilometres in a day than he speaks words. If you follow him on Strava you will see that pretty much everyday he’s out there pounding the pavement. With 10 Marathons already under his belt it’s fair to say he’s truly a master of the marathon.

In the Apprentice corner you find myself, having run a couple of half marathons and the full once, albeit very slowly. But around six months ago, this was all about to change with the apprentice signed up to take on the master, namely both of us running the Queenstown Marathon.

The apprentice decided that to conquer the beast would take skill, resolve, and someone else telling him what to do. I enlisted the help of two coaches based out of Sydney and got to work.

Training

From a shocking first five km run, I gradually pulled myself up to some level of fitness. Six months is a long time to keep running, particularly when you have a coach tracking everything you do. Keeping yourself honest is one thing; keeping a coach happy is another altogether.

Well after much training and getting up to the ridiculous level of running 35km’s (in the rain no less), the time was ripe to dethrone the master. But….

Three weeks out I pulled up lame, having blown my right calf muscle. Many physio appointments later it was decided that there was no way the calf could withstand a four hour run so I sadly withdrew my entry from the marathon. The folk that run the Queenstown Marathon kindly offered to downgrade me to the 10km which I thought would at least be a nice walk around the lakes of Queenstown.

The master had shown the apprentice that it was indeed a marathon and not a sprint.

Race Day

So come last Saturday, the two of us made the trek down to Central Otago, donned our Team DF running kit, and set out on our respective runs through the stunning Queenstown scenery, along with close to 10,000 other runners!

From my perspective, I started on the basis that if I could feel my calf hurting I would pull up and walk the remainder of the event. Fortunately there was no pain and I managed to run the whole way, in what was quickly becoming a very warm day.

Steve set out on the marathon around 8am and word got out fairly early that Queenstown wasn’t going to be offering up any “personal bests”. At 26°C and no wind at 9am, there were plenty of people struggling. The good news was the Steve finished the event and retained his rightful title of DF’s Master of Marathons, knocking off his 11th Marathon in a respectable time.

All up the event was awesome, in quite possibly the most beautiful place in the world. I think the master and the apprentice both have unfinished business so this blog post might need a little updating in 12 months.

Editors note: As you’ll note in the photo of Stu, seen zooming past other runners, he nailed the 10k run, finishing 8th in his class. Well done both of you — you’re an inspiration to the rest of us.

Zero to App in 3 Weeks

Tue, 14 Nov 2017 17:26:00 +1300

The Back Story

Danny Hui is a man on a mission, and it’s an incredibly special mission that is very close to his heart.

When you have a child with disabilities, you look for ways to make their lives easier and better, as well as yours as a parent.

Danny and his wife Jess have gone to extraordinary lengths to offer their son Monty, the opportunities that most children would have, like walking unassisted or running around a park — the simple daily activities we take for granted that are huge challenges.

With challenges like this it's a team effort to get the best outcomes, from advisors to family caregivers, all offering their advice around the best approach and what to expect. In one of our first discussions with Danny, he mentioned they have something like 20 different points of contact that are regularly consulting on their son: doctors, therapists, grandparents, the list goes on.

What Danny very quickly realised is that with such a big team comes a mismatch of communication. Not everyone has the same information; there’s no one place to gather and share knowledge and progress; and it’s just too easy to find that not everyone involved is on the same page.

A prime example centres around Danny's son heading to school next year: he needs to get a chair, but because he’ll be at school, there's an array of people who need to approve the type of chair that would be best for Monty’s needs, from the school principal, to therapists, everyones input needs to be factored in. And the way that it’s always been done is to have all the details about the chair in a folder, and you cart this around the different therapists and meetings…

The Front Story

So if the above is the back story, you can guess what Danny has set out to do, which is nicely encapsulated in his company name — introducing:

Danny had the idea that if he built an app, then everyone would have the same view of what care and requirements are needed, how his son was progressing, and of his therapy and action plans.

So he got to work, giving up his full time job to take on something he is immensely passionate about. He entered the world of “Social Enterprise” and envisioned an app to help track and share information for Monty and others like Monty.

As part of his research, he realised that he needed to get something up and running quickly which he could get in the hands of families to start testing. How these families used the app would help make design decisions for further development.

The question then became: How can you design and develop a mobile app fast, and deploy it to a group of people with minimal fuss?

As a long term user and advocate of FileMaker, he started considering this as a rapid development platform. He approached Digital Fusion in May 2017 to discuss the project and get our thoughts on moving forward.

We were blown away by the thought and consideration that Danny had already put into planning the app. Our part was to take these initial ideas and work them into a practical solution through an initial Analysis and Design phase.

Wireframes for a “minimum viable product” were drawn up, discussed, changed, and finally locked in. A plan was put in place for development that would see the app up and running quickly, but which was also very flexible to make sure we could make changes as feedback was received.

FileMaker Go makes for a brilliant platform to develop an iOS app quickly. Not only is it econmic to develop with, but we were able to get it out to the families quickly for testing.

We also used FileMaker Pro and FileMaker Server to host the central database behind the app, and to provide management tools such as usernames and password administration, usage tracking, and overall giving Danny the ability to self manage the app.

The end result is now being tested by facilities across Australia and Danny continues to look at modelling the business side of the app.

What would have cost a lot of money to build as a native iOS app (think 100’s of thousands of dollars and many months) was developed in FileMaker at a fraction of the cost and time.

The Kicker

All the while we have been discussing and developing Danny's app, he has been part of the Optus Future Makers programme. The programme is focused around innovators who have an idea or business that will benefit disadvantaged youth.

It’s a pretty special opportunity that Optus offers, with full day workshops to teach the innovators ways to bring their ideas to life. There is the added benefit that they award funding to some of these innovators, with the chance to then go onto the APAC regional section as part of a SingTel (the big Singaporian telecommunications company) accelerator programme.

Well, we are super stoked to announce that Danny was successful, in fact very successful in the programme, and was awarded entry into the APAC region Future Makers programme along with a substantial fund for further developing his product.

The money is going to substantially help Danny and Jess realize their dreams by removing some of the financial pressures of self-funded app developement.

Digital Fusion are immensely proud to have worked with Danny, he is a very special person whose work will make disability care more coordinated, easier for everyone and ultimately bring better outcomes to many families.

Team DF Goes Racing

Fri, 27 Oct 2017 07:54:00 +1300

Have you ever wanted to live out your childhood dream of racing a car around a track at very fast speeds?

Well our CEO, Craig Saunders, had that dream and last year decided to give it a crack with the advent of an entry level series called the "2K Cup"

The key thing about this series is in the name: '2K' means your car must be able to be bought for $2000 or less on the open market. Sure, you can (and should) add a roll cage and safety kit, but performance modifications are prohibited to keep the cost down.

Well the 2016 season passed and Craig found himself enjoying the sport, and the company of other petrol heads, so when the series sponsorship was up for grabs he raised his hand. He reckoned that after the first season he could clearly see that he wasn't going to win personally, so by getting "Digital Fusion" onto every car in the series we could be sure of sponsoring the winning car. (You can see why he's the boss.)

We are now pleased to announce that the South Island version of the sport is called the Digital Fusion 2K Cup:

This means Digital Fusion branding is splashed over all the cars, and our message to "Get Ahead", whether that be through racing or through better business software, is being spread to the masses.

And what would motorsport be without a team? So we have nabbed a young whipper snapper from Custom D and have him driving in a Team DF car. (Incidentally, Custom D did the graphic design for the car, which we think is a pretty cool way to use our logo huh?)

So if you ever find yourself at a loose end over summer, and you are in the South Island of New Zealand, do head out to your local circuit and give Craig and Josh a cheer.

Update — March 2018

Craig's finally had a tidy enough run to actually publish an in-car video of one the races — in this it's a handicap start too, where the slowest cars get a head start:

Tesla Roadtrip DevCon 2017

Fri, 22 Sep 2017 19:37:00 +1200

The 2017 FileMaker DevCon was held in Phoenix Arizona, a few hundred miles inland from Los Angeles, where flights from NZ land, so rather than catch another flight I figured a drive would be more interesting…

I'm Thinking...

I’ve always been a “petrol head”, I love cars, driving and high performance engines, but now the with the rise of the electric vehicle I have a new perspective on things…

It has occurred to me that the internal combustion engine really is a kludge — a work around, an extremely complex, highly refined, remarkably engineered work-around to convert explosions into motive power. To see what I mean think about the systems that a petrol engine needs to work successfully: fuel, lubrication, cooling, transmission, exhaust, crank and electrical. In fact you have to have an electric motor just to get things started.

The modern combustion engine is a marvel to behold, an engineering and manufacturing triumph, but wow is it complex!

The electric motor on the other hand is dead simple. Some magnets and coils of wire, feed in an electric current and you get rotational motion.

So I believe the days of combustion engines — for main stream transport anyway, are numbered. We already have viable electric cars that perform well — fantastically well in fact — and can achieve a decent range between charges… there’s the rub though, with charging taking up to several hours. So petrol engines still have that ace up their sleeves — the 5 minute “recharge”. But when you factor in the advances coming in batteries and charging… in a few years those issues will be gone: range will double or better and much faster charging rates look like being possible. In fact I think battery technology is like the silicon chip: it’s probably the key driver of much of the technological innovation we see now — they’re everywhere, enabling devices and sensors to pervade our lives, whether we like it or not.

So that brings me to some real questions: When do you switch? How good are the best electric cars now? And what is it like to have to recharge your car on a road trip?

Road Trip!

I figured the best way to find out for myself would be a road trip — a pretty decent trip, not just some city driving and a quick blast through the hills, but an 1300 kilometre return trip from LA to Phoenix in a Tesla Model X. Through a scorching desert where you will die if stranded. Or if the aircon stops.

Turo

First problem: how do you hire one?

A quick check of the mainstream rental companies revealed… nothing. But then a web search revealed Turo, a new way of renting cars from private individuals — essentially this is AirBnB for cars, and the result is a huge variety of vehicles including some very exotic and unusual options…

Signing up for Turo, uploading my NZ drivers license and getting ready to hire was a breeze — a hell of a lot easier than signing up with any of the old school rental companies, that is for sure. I can see yet another big industry disruption going down here — watch out car rental companies.

So I found a very nice 2016 Tesla Model X 90D. The choices available meant I could even find a colour and interior combo I liked, complete with the rather unique 6 seat configuration. Sweet!

UX

To use the language of our industry, what was the User Experience (UX) like? i.e. What was it like to drive?

Quite simply the Model X is a beautiful machine to drive, with strong acceleration even at higher highway speeds (80-90 mph) and power that is instant and smooth. And it steers and handles with precision and confidence — our driving was city streets and freeways, but I’m betting it would’ve felt sublime carving out some twisty back roads too (i.e. New Zealand).

It’s true, there is no visceral V8 tearing apart the airwaves like my M3 but… it just doesn’t matter. I think until you’ve experienced it you can’t really understand this. Don't get me wrong the sound of the M3 is just fantastic, but the Tesla doesn't lack for not having it — in the same way petrol cars didn't need the sound of hooves, electric cars just don't need to roar.

Baptism by Fire

So it turns out that heading out into that lovely scorching desert with limited range and big distances between chargers might’ve been slightly foolhardy, at least for the inexperienced EV driver.

The trip computer calculates your journey nicely — all you do is put in the destination and it tells you exactly where you’ll need to stop and how long for. It worked out the journey with a couple of stops of about 40 minutes, even though the journey could theoretically be done in one stop — that’s because the Superchargers “fill up” better for the first 3/4 of the battery capacity so it’s not worth waiting for a complete top up.

HOWEVER, if you leave with ‘just the right amount’ and then drive this car with any sort of vigor you will find that the range you thought you had, rapidly disappears. This can be a problem.

Tesla has your back though, and it’ll start pointing this fact out: “Stay below 70 mph to get to your destination” … at first I didn’t take that too seriously, I could see that the battery range was still greater than the distance left…

However continuing to drive briskly and with some incline or altitude or heat, or maybe a combination of all of the above, led to “Stay below 65 mph”. This brought on a fair dose of Range Anxiety.

I slowed down, moved to the slow lane and watched the big rigs I'd passed earlier haul ass on the Model X. Argh.

Pulling in to Quartzite, small town in the middle of the desert, things were getting pretty marginal and life support systems were on the verge of shutdown. Dire:

My passenger, fellow FileMaker developer CJ from LA, came with the bright idea that we install an exercycle in the passenger footwell to generate some extra power. Fortunately Quartzite has a Tesla Super Charging station.

Destination

On arrival at the JW Marriott Desert Ridge Resort in Phoenix, the Tesla was again down to the last few miles so my first question to the bellhop was “What are your charging options?”, to which he replied “$29 for valet…” — “Er, no mate. I mean electricity, where can I plug in?” The answer I was surprised to learn was “no where”. At least not at the hotel. Turns out that’s a bit of a problem…

Over the next few days I had to take the Tesla over the road to the shopping mall (which is about a kilometer away) and plug it in. The first place I took it to charged $1.50 an hour, which seemed OK, though I didn’t realise it went up to $5/hour after the first 3 hours, so I ran up a $20 bill and only half filled the car — the shopping mall chargers are way way slower than the Tesla Super Charger stations.

I found another charger a bit further down the road at another shopping mall car park — this time free, but with a 3 hour limit. So over the next 3 days I took the car there several times and gradually built up a decent charge. This was painful. Especially the walk back to the Marriott in that 40°C (104°F) plus heat.

Not being able to charge overnight at your destination is a killer. If we’d needed to go any distance each day, say a trip to Sedona or the Grand Canyon we’d be SOL. The nearest Tesla Super Charger was about 40 minutes away on the other side of Phoenix so a visit there was out of the questions too. I have to say that I was very surprised that a top notch hotel like the JW Marriott wasn’t equipped for electric vehicles. In fact the bellhop said they’d had 5 Teslas arrive that day alone! So what did those drivers do for charging I wonder?

Range Anxiety Max

Somehow I failed to learn from my journey out to Phoenix and on the way back I made the same mistake charging up to just the minimum amount of time recommended. After gather just enough electrons I then proceeded to nail it up the on-ramp and we headed briskly down the freeway. Within about 20 minutes the car came up with some bad news: You do not have enough charge to reach your destination.” WTF? This was a bit concerning because rather than needing to drive slower to get to the destination at Coachella, we simply were not going to make it. Basically it was telling us we were screwed.

After a quick team discussion we figured that we didn’t need to turn back yet — we hadn’t reached a point of no return — so we’d try a bit of Daniel’s cycling expertise and tucked in behind a truck to draft along at a modest speed for a while. I’d also figured out how to make the autopilot follow closely to maximise the draft effect (knowing that the autopilot would brake quickly enough if need be!)

Peak Time Traffic

Arriving into LA at 5 PM on a Friday afternoon was always bound to involve a spot of commuter traffic. Turns out autopilot is very handy in this situation, bringing the car to a complete stop then driving off with the cars in front, even if you’ve dozed off in the meantime — saves a lot of embarrassment. Just kidding, but actually it was good as long as you didn’t want to change lanes — to carve your way through traffic, such as you might want to do when you’re running late to get to the airport, you really need to take charge and drive it yourself.

So… Would I Buy One?

Yes I would but I don’t quite think they’re for everyone yet: the Tesla range are still very expensive cars and there desperately needs to be either a very quick way to charge or charging points everywhere you might stop for the night. My problem is that I just can’t bring myself to part with the M3 yet.

Beautiful and Easy Drawer Menus for Desktop and Go

Tue, 18 Jul 2017 09:17:00 +1200

Stepping up your design game

FileMaker is no longer simply a database development tool.

With FileMaker edging closer every day to being a fully fledged mobile and desktop application platform, as developers we should be striving to build the best user experience possible. That means building controls that both look and behave to the same standards as if they were developed in any other platform.

Until recently this has been quite a challenge in FileMaker. We have been restricted by controls that were limiting in their functionality, and often needing to resort to plugins or simply putting things in the too hard basket.

It is my belief that as FileMaker developers we should no longer be settling for "just good enough". We need to step our game up and become great designers and developers of applications, not just databases. If we can build controls that are easy to drop into a solution and use (even if they are complex underneath it all) then we should be doing this for the betterment of the user experience. After all - what we build is for people to use all day every day.

Sliding Drawer Menus

We have covered these types of menus in the past. A couple of years ago I wrote an article about how they can be built using sliding panels. That article went a little over the top by having the menu open/close simply on a mouse-over action through the use of a plugin and tooltips. The technique while workable had some limitations - the plugin on FileMaker Go and WebDirect being one of them.

Recently I began development on a large client solution and decided to overhaul this technique and make it both easier to implement, and more usable and reliable. The menu was to work on both FileMaker Pro and in FileMaker Go.

I wanted the drawer to look and feel as native as possible, and leverage all the tools that FileMaker provides to give the user the most native experience.

Jump right in and have a look!

We always try to build easy and user friendly demo files for our articles and this one is no different. You can download the demo file that accompanies this article below. Have a play round, explore, learn how it works. Make sure to try it on all platforms such as FileMaker Pro, iPad, and iPhone.

Download the Demo File!

The Basic Structure for the Menu

The menu setup is quite simple. It comprises of a sliding panel object with 3 panels:

The first panel (default) is empty and unused, it just happens to be the one the user ends up on by default.
The second panel (on) is the panel that contains the actual menu and contents.
The third panel (off) is again an empty panel, but is used to close the menu via a swipe gesture on FileMaker Go.

So that's it, pretty simple huh! This panel object can be placed on your layout wherever you want the menu to be (typically the left edge). There are a few other design considerations for the panel:

It has no fill colour so that you can see the underlying layout
The navigation dots are hidden as they are not required.
Swipe gestures are enabled so that the user can close it via swipe on FileMaker Go

A single script for opening and closing

There is a single script responsible for either opening the menu, or closing it. Under normal circumstances, the script does not accept a parameter, and the default action is to toggle the menu on or off.

The script keeps track of whether the menu is open or closed by way of defining a global variable - $$MENU.STATE. When it has a value of 1, the menu is on, otherwise it is off.

The basic way we open and close

Recall our object has three panels. When using a left of screen based navigation the following actions are done to open and close the menu. First, for opening:

The script goes to the third (off) panel
It then animate going back to the second (on) panel.

and to close:T

The script goes to the third (off) panel.

Our demo file is built on the basis of the menu opening from the left of screen. If you instead wanted a right of screen menu, you simply reverse these actions. To open the menu you would start on the first panel and go to the second. To close, you go to the first panel. In fact, the right-of screen menu only requires 2 panels, not three.

The beauty and power lies within Script Triggers

While the above menu script & processes are great, they are for toggling a menu on and off through using an action such as the user pressing a menu button on the screen. But you can take this so much further and make the menu so much more usable by leveraging script trigger functionality.

Consider other ways the usability could be enhanced:

What about opening the menu using the right-arrow key?
What about closing the menu using the left-arrow key?
What about using escape to close the menu if it is open?
What about using a swipe-gesture to close the menu?
What about tapping on an area outside of the menu to close it?

We can do all this, and it's easy!

The first three actions can all be done by using an onLayoutKeystroke script trigger with a corresponding script. These are leveraged for FileMaker Pro where keystrokes are used. In the demo file this script is provided and used. The script needs to check a few things, but its basic operation is:

If the user has the mouse cursor in a field, or a layout object such as a button has focus, it will not trigger the menu.
Otherwise, if the user pressed the left arrow key, close the menu.
If the user pressed the right arrow key, open it
If the user pressed escape key, close it
Otherwise just let the keystroke proceed as normal.

So simple and yet so effective! Check the demo file and try these for yourself.

Taking it to the next level with FileMaker Go.

The sliding drawer while a great desktop control, really shines on the iPad and iPhone due to these devices limited screen real estate and extra usability features we can leverage. It is a control you commonly see in a lot of native iOS applications, so users are familiar with how it works, and there is a certain level of expectation also that goes along with a drawer as to its behaviour.

The following FileMaker tools have been leveraged to give the complete user experience:

The existing panel control & navigation script
Enabling of Gesture Swipes on the panel object
The onPanelSwitch Script trigger to capture the user swipe & direction
The onGestureTap layout level script trigger to capture user tap on screen.

The onPanelSwitch script trigger captures the target destination panel. If the menu is open (on panel #2) and the user has swiped to the third panel #3, then they have swiped their finger to the right in a motion where the expectation is they are minimizing the drawer. Great! We can just run our navigation script to toggle the menu to close, done!

It is also interesting to note that swipe gestures work on the mac desktop in FileMaker Pro if you use a trackpad or mouse capable of having swipe gestures.

Tap tap tap!

For the onGestureTap script trigger, it's a little more complicated, but once you understand how this trigger works it's simple!

The function Get ( TriggerGestureInfo ) returns us lots of useful information about the users tap:

The string "tap" indicating a tap was done - we don't care about this.
A value containing how many fingers were used - we will only trigger with 1 finger.
The X coordinate in the document where the gesture occurred - we want this!.
The Y coordinate in the document where the gesture occurred - we don't care about this.

The importing aspect here is whether the user tapped with one finger, and where in the horizontal axis of the layout did they tap.

Why do we care about where they tapped? If you look at the behaviour of most sliding drawers on iOS, a tap within the menu does not close it, yet a tap on screen outside of the menu area will close. So that is the behaviour to be replicated.

How to tell if the user tapped off the menu

Again, more simple leveraging of the tools at our disposal.

The panel object has been defined, and all the panels are named. So the GetLayoutObjectAttribute function can be used to get all the information needed:

GetLayoutObjectAttribute ( "menu.on" ; "right" ) gives the right-edge coordinate of the menu, where "menu.on" is the panel object name.

So knowing the right edge of the menu and knowing the coordinate where the user tapped, the script simply needs to compare the two values. When the user tapped a coordinate greater than the right edge we know they tapped outside of the menu.

Some other considerations when implementing

This menu works great and it's a beautiful modular control you can throw on your layouts. With just a few scripts and controls you can have it up and running in your own solution. To make it more usable, consider building the contents of the menu via a context which is universal (accessible from all other layout contexts). This allows you quick copy/paste of the control onto other layouts for use and you don't need to worry about changing field and portal references.

Because the panel control sits on your layout, it can be often annoying trying to work in layout mode with it present. There are 2 options at your disposal:

Just drag it off the edge of the layout while developing, OR
Use the new layout object inspector in FileMaker 16 to hide the object while in layout mode.

Remember, the panel control should be at the top of your layouts ordering so that it sits on top of everything else - you don't want other underlying layout objects to appear in front of it!

Finally, it is recommended to use a fill coloured rectangle to replicate the actual menu background, as opposed to simply filling the colour of the panel itself. In our example, we have attached a single "Exit Script" script step to this rectangle object.

This is done so that if the user is clicking or tapping on the menu, they are not inadvertently clicking on any underlying field on the layout. If you do not do this, there is potential for unexpected actions such as entering a field or clicking a button under the menu object, as shown below.

Panel is not the front-most object

The navigation is not a button, so the user can click behind it

Limitations

While we are forever getting closer to perfect implementation in all circumstances, there are still some limitations to this technique. One of which is FileMaker's inability for objects to span vertically across layout parts. If your layout uses a top navigation or header, then putting this control in that part will not work as it chops off once it hits the part below. Actually in the solution I developed for this was the case, but it was quite easy to simply sit the navigation below the top navigation part in the body and it still works great.

This control doesn't work in list view or table view for similar reasons to those mentioned above. Hopefully one day FileMaker will give us horizontal layout parts so that the side of our layouts are a separate space for controls such as these.

Finally, the navigation control works great in WebDirect, but it comes with a caveat. In WebDirect, any object overlaying another will prevent the underlying object from being clickable as a button, or enterable as a field. In this case, the navigation panel sits at the front of the layout object ordering, preventing the user from clicking what lies underneath. In order to implement for webdirect, introduce a hide condition on the panel. Recall the use of the global variable $$MENU.STATE to keep track of whether the menu is open or closed. Simply add the hide condition of "not $$MENU.STATE" to work around this issue.

Demo File Download

The demo file has been built to work on both FileMaker Pro, iPad and iPhone. If opening on a phone, it should open on a separate appropriately sized layout. On the iPad and Desktop, you'll end up on a larger layout. This demo is suitable for FileMaker Pro and FileMaker Go versions 15-16.

Download the Demo File!

Feedback and comments are always appreciated!

Intro to FileMaker Cloud

Tue, 11 Jul 2017 12:12:00 +1200

If you’re dialed in to FileMaker Inc for the Asia Pacific region you’ve probably heard that “FileMaker Cloud” is now available — Wahoo! Here's one now:

But what is it exactly? What does it mean for you if you’re a business owner?

Quite simply FM Cloud is a service where your databases are hosted in a data centre (a big warehouse full of computers) for you, and you're billed monthly based on how many connections you want and how much you use the service.

Cloud

“Cloud” does not mean it’s on the web. There’s a bit of confusion in the world — actually there’s a lot of confusion in the world…. but lets stick to FileMaker:

The term “Cloud” in this case simply refers to the data and application being hosted in a cluster of computers that are managed for you.

In this case the “cloud” is Amazon Web Services (AWS), one of the leading providers of such cloud infrastructure globally, which means they’re extremely good at providing a robust yet flexible service. We’ve been hosting FileMaker solutions on AWS for several years now so we know a lot about how it works and just how easy and reliable it is.

FM Cloud is a bundled service that includes both the computer power you need for hosting, plus the FM Server software, backup and administration tools. You still connect to it using FileMaker Pro on your desktop/laptop computer, or through WebDirect (if your app has been designed for it), or FileMaker Go.

Some big wins

Hosting solutions in the cloud has some major advantages over hosting on your own server on your premises. It really simplifies deployment and management and lets us all concentrate on the business end of the solution:

You’re no longer responsible for the physical computer hardware: that’s taken care of for you.
It’s scaleable: if you need more power or more storage, it’s simply a matter of reconfiguring the server through a web page.
Cloud hosting makes it easy to access your apps from anywhere — they’re no longer trapped inside your network.
Super security: AWS data centres are so secure no-one knows exactly where they are*, plus they have back-up power generation, multiple high bandwidth connections to the internet and are fully climate controlled.

(* While that's what we've been told, we're picking someone must know where the servers are...)

The only real drawback is that you might see a performance reduction if you currently run a server in-house simply because data has to travel a lot further when the server is not in your office. Performance will depend a bit on how far you are from the data centre and what type of internet connection you have. FM Cloud for our region is hosted in Sydney which pretty much means you’ll get good to great performance from anywhere in Australia or New Zealand that has broadband.

Is it right for us?

Essentially FileMaker Cloud is fairly similar to the service we’ve been providing our customers who host with AWS, but there are a few technical differences and these affect whether or not FM Cloud is going to be right for you.

FM Cloud uses FileMaker Server 15

We don’t see that as a big disadvantage but there are performance gains to be had with 16, and of course new features like PDF printing and the new data API. This also explains why the icon is pink/purple vs the blue/purple FileMaker now sports.

We have no doubt that FM Cloud will be updated to use FileMaker Server v16 at some point in the near future. Even with the server being 15 you can still use FileMaker Go or FileMaker Pro 16 to connect to it to get most of the advantages of the latest FileMaker version.

FM Cloud does not support Custom Web Publishing (PHP and XML)

If your database has a web site attached using PHP then it won’t be able to be hosted with FM Cloud.

Server-side Plugins May Not Be Compatible

FM Cloud runs on a Linux operating system so you need to have special versions of any plugins on the server in order to be able to use them. Many of the solutions we’ve built use our Xero plugin, BaseElements and Sendmail: we don’t have versions of these plugins suitable for FM Cloud at this time.

No Scheduled Scripts

Scripts that automatically run at predetermined times on the server can't be setup or used in FM Cloud — in most cases re-thinking how those operations are carried out should be doable.

For a more thorough and direct comparison FileMaker have produced a very useful table that shows how FileMaker Server compares with FileMaker Cloud — bear in mind they compare FM Cloud to FM Server on premise, but there is also a third and very popular choice which gives the best of both worlds, i.e. a custom configured cloud server with FileMaker Server installed.

So in a Nutshell…

Despite some limitations FM Cloud is a superb product and we’d be more than happy to talk to you about whether or not it might make sense to move your solution onto this platform.

And if the turn-key FM Cloud service doesn’t work for you we can essentially provide you with a very similar service, using AWS to configure a FileMaker 16 Cloud-based server running on Windows.

DevDays - 5 Go Wild In Sydney!

Wed, 17 May 2017 00:00:00 +1200

We had a tonne of fun being a part of the Asia Pacific FileMaker Developer Days mini-conference held in Sydney last week. There were over 100 developers from around the region, many travelling in from as far away as Malaysia, Perth and New Zealand.

FileMaker Inc. brought in Andrew Paulsen, one of the key product architects on the FileMaker Pro team, and Brad Freitag, Vice President of Worldwide Sales. And of course the local Asia Pacific team were there with David Borgnis organising and MC'ing the whole event — thanks David!

From Digital Fusion we sent five staff, with four them involved in presentations — the fifth was there to hold placards up to encourage suitable audience reactions.

Incredibly Informative...

The conference coincided with the release of FileMaker 16 so we'll lay claim to leading the world in getting into some serious discussions of the new features.

A number of speakers noted that the 16 release is quite developer centric with features such as the new RESTful data API, new window controls and the new object inspector. Even so there's a lot of features that will affect users too — a lot of discussion was on how these things will help us build better user experiences into our FileMaker applications and make it easier to fit in to the world of web services smoothly.

Andrew spoke a lot about FM16 features and product direction, as well as two of the best sessions we've ever seen (including those "under the hood" sessions at DevCon) on performance optimisation — very informative and directly applicable to the work we're doing.

Brad covered some of the sales and marketing strategy that's driving FileMaker nowadays and it was interesting to see how they're comparing against some of the new comers in the space such as Google AppMaker. FileMaker is a far more mature product and doesn't require buy in to the Google realm. However having these new players in the field helps validate and grow general awareness of the need for rapid, robust business app development tools.

It's also very reassuring to hear how FMI recognise FileMaker as more of a software development platform than the simpler "desktop database" that it used to be.

...Highly Entertaining

Another highlight was developer Salvatore from Goya showing us how to send photos of objects off to an Amazon Artificial Intelligence service (using the API tools) which would then return the contents of the picture as text — send it a picture of a cup on a table and it'll come back with "Cup"; he sent off a photo of a glass of beer and it came back with "Glass of Orange Juice". He's one of the funniest developers we've heard and his ability to entertain while telling us about such a dry subject is gold.

And to keep that theme running, we sponsored some drinks and food at the end of the first day to help spur the creative juices and socialisation amongst the FBA community that were present... if you weren't there you missed out on a free beer on DF so don't let that happen again will you?

Something For Everyone

The two days were targeted seprately to cater to two different audiences, with Monday being for FileMaker Business Alliance (FBA) members, and the Tuesday for all-comers such as "citizen" developers and non-FBA developers.

We were lucky enough to get four of our team onto the speaking schedule with...

Daniel and Craig with "Making the most of new features for a better user experience"
James and Craig on "Stand Alone Apps: App creation and deployment using the iOS SDK"
Cath going it alone with "Wonders of WebDirect: Success stories from the frontline"

Not only was it a great experience for our team to be part of the conference, they thoroughly enjoyed being able to share their knowledge. I think it's a bit of a buzz to nail a presentation in front of a big audience... and these are knowledgeable peers with plenty of questions!

And what would a conference be without the company branded top plus obligatory photo (in this case we got the team mid-Conga):

Dynamically Resizing Backgrounds That Don't Distort

Mon, 20 Mar 2017 19:41:00 +1300

Introduction

If background images are used sensibly, they can provide a beautiful backdrop to areas of your solution, such as a login screen, splash screen, or indeed the entire solution. FileMaker allows the user stretch the window both horizontally and vertically in any ratio they wish. Anchoring has allowed us to try and compensate for this in our designs, but often images suffer because they are themselves a fixed aspect ratio, and deviating from that ratio will either stretch and distort the image if 'maintain aspect ratio' is off, otherwise result in blank space around the image edge if aspect ratio is on - both options are not ideal for a background image.

In this article we present a technique that allows you to resize an image and have it re-generate a thumbnail version upon resizing of the layout. This thumbnail version is a cropped version of the original, but respects the original image's aspect ratio. If you choose your image sensibly, you can make a layout background that looks great no matter what dimensions your window is set to.

What is the issue here?

It all comes down to aspect ratio. I'm sure you've all come across this issue at some point or another when developing: You have a container on a layout, and as you resize the layout, the image becomes stretched and distorted:

So here we have a container where we have set it to reduce or enlarge to fit, and we don't maintain proportions (the aspect ratio). This is good in that it fills the entire container, but bad in that the image looks terrible when stretched.

Aspect ratio is just the ratio of width to height of an image. Typical aspect ratios such as 16:9 simply mean that if the width of the image was 16 centimetres for example, then the height would be 9. If the width were 32, the height would be 18, and so on.

So how about turning on maintaining original proportions (aspect ratio):

Now we have the image looking good, but the rest of the container cannot be occupied by anything in order for us to keep aspect ratio. This would be fine if our container was displaying something like a persons photo, or a company logo. However in this article we want a container that is going to be used as a background image. Imagine using the above as a background, who wants massive areas of nothing in the background? Conversely who wants a horrible distorted image. Is there a nice middle-ground here?

Requirements for our background image

First, let's define a few rules for what will make a successful background image:

We don't want the image to zoom if possible (so no pixelation)
We don't want the image to stretch or distort (so no breaking of aspect ratio)
We don't want any large borders around the image (so fill the entire layout object)

Prevention of Pixelation when Zooming

This is an issue that would occur if the dimensions of our FileMaker Window were greater than the original image dimensions. If we wish to satisfy conditions 2 and 3, we can't make the image larger than it's original dimensions, this results in pixelation of the image - you simply cannot make an image bigger than it actually is without sacrificing quality of the image.

The solution to this one then is pretty straightforward, make sure your background image you use has a dimension that is sufficiently large so that it is unlikely your user will be able to resize their FileMaker window larger than the images dimensions.

on iOS this is fine, you know what dimensions you can work with as it's constrained by the size of the device screen. Similarly on monitors you are constrained in window size to the monitor size, however different users can be on different monitors so you must choose wisely.

Prevention of Distortion and Borders

The way we prevent distortion of the background image, while keeping it filling the layout object, is best illustrated with a diagram:

In this example the green rectangle represents the dimensions of our background image. The blue rectangle is our screen dimensions.

Both image and screen have the same aspect ratio of 2:1 and so in order to fully occupy the screen, we simply generate a thumbnail image 1/2 the size of the original image, it should fit it nicely.

This one is a bit trickier. Our screen is now 600x200, which is an aspect ratio of 3:1. To demonstrate how we will scale down our background image to fill this screen size, we'll use this crudely put together FileMaker layout and the GIF below!

http://i.imgur.com/mjf9kCV.gif

PRO DEVELOPER TIP: When resizing layout objects in layout mode, if you hold the cmd+shift keys while resizing, the image is resized respecting it's original aspect ratio. That is how in the above GIF I am able to resize it correctly. (also of note, holding option+drag will constrain the object to the same width and height when resizing...)

We must maintain aspect ratio of the background image, so the first step is scaling the background down to a size where the largest dimension of the screen is matched to that of the image. Our resulting image in green is now still in it's aspect ratio, but sized down.

The second step is to center the image (in green) over our layout background (in blue). This is actually achieved simply by setting the layout object properties to align centered both vertically and horizontally. The final step is to ensure that the layout object is set to crop the image

Here is another example:

Here the height is slightly more than the width of the screen. You might find a user doing this if the layout contains a portal or list and they want to maximise screen height, or if they are using portrait orientation on an iOS device.

Here is the transformation that occurs:

http://i.imgur.com/8Cq58lU.gif

Much like the first example, this one is simply scaling the original image down to the maximum dimension. The difference here is the maximum dimension is the height, not the width. Scaling down stops at the point the height is reached.

With the fact the background image is centered horizontally/vertically and cropped on the layout, the final effect is for the background image to be positioned centered in relation to the original image.

Wrapping it all up in a Custom Function

In order to generate the required thumbnail image, we need to know:

The width and height of the raw image
The width and height of the layout background object
The image to use

The first point can be obtained using the GetContainerAttribute function, we can return the width and height of the image in the container.

The second set of dimensions is obtained using the GetLayoutObjectAttribute function. With it, we can tell the dimensions of the layout background object at any point in time - recall that given the container is anchored and resizing, it's dimensions change as the window is resized.

In the demo file you'll find a custom function called @IMAGE_bgThumbnail. This takes as it's parameters the image to use in the thumbnail, and the object name on the layout that the thumbnail is to be sized for.

If you want to find out exactly what the calculation is have a looksee in the function.

Getting things to work nicely

So you now have a custom function to use, and hopefully an image to use also. You can create a calculation function to produce the desired resulting container field to use for your background. Put this on your layout and you're all set, right?

Well not quite, there is a little matter of having the calculation refresh itself when the screen is resized. The mere act of resizing a screen (and thus the background object) is not enough to force the redrawing of the thumbnail.

To achieve this, we need to use an onLayoutResize layout script trigger. The script that runs will be responsible for refreshing the background layout object.

The script itself is pretty basic, there are a few ways you can refresh the background object:

Refresh Window
Refresh Object
Freeze Window

We use Refresh object in the demo because it allows us to only refresh the background image, and not all other things on the layout.

As an interesting side note, freeze window also works. We assume this is because if a freeze window step is used, then the script when it exits silently does a 'refresh' window to bring the screen back to it's required current state. Quite nice to know!

http://i.imgur.com/TuZSlw4.gif

Here is an example from our demo file. In it, we are resizing the window to be wider horizontally. As we resize, we don't instantly see the thumbnail image resize - this occurs upon release of the mouse after resizing. At this point in time the script to refresh the object runs and we see the change.

The end result image is a thumbnail that is not zoomed in, it is not stretched or distorted either. It is however cropped, but from the center of the image out. If you choose your images wisely the end result is a nice alteration to the background image that the user should not notice much change in.

What's the point?

User experience! If you present a background image to a user with large borders because you don't want to stretch your image, the user will notice. Conversely if you present a stretched image, the user will notice. All of these add to a negative user experience. While background images aren't critical - and most of the time not actually useful - they do have their place in certain parts of a solution if used in a certain way, so you might as well make it the best experience possible.

Demo File

What good is an article like this without a demo file to accompany it right? Well here it is! No username and password, fully unlocked just go for it.

DynamicBackgrounds.zip

Building a Super Slick Search UI

Mon, 13 Mar 2017 11:02:00 +1300

Introduction

Search is an integral part of any solution, and can take many forms. FileMaker provides us with a useful native find mode, along with quickfind. Often though this is unintuitive for users, or just does not fit in with the design of a solution. In this article we present a slick, great looking search box UI design pattern, and explain how it is built. We also incorporate a number of native FileMaker techniques to achieve this (no plugins here!).

The primary focus of this article is on the construction of the UI design for our search box. Other techniques discussed involve using relationship level filtering of results (in a basic way) and having a timed delay on our search filter.

A bit of Search Background

So, what does FileMaker offer in the way of searching? Well there is find mode obviously. Great power, but perhaps a little unintuitive for the average user, especially in this day of age where websites provide pretty commonplace design patterns for searching. Quickfind is a much nicer alternative, combining an automated 'find mode' search of sorts, with a single search box making it easier for users to search.

Both find mode and quickfind rely on results being displayed in a found set. If your solution is setup this way then great, you can stop here :) If you are into building solutions that don't feel like native FileMaker, and feel more like a native application, then read on.

Portals have been used to display search results for a long time, it's no secret. No matter how you end up collating your results for display in a portal, the portal generally allows you to select a record to then navigate to. The benefit to portals is that they can be placed within a layout, for in-line results display. This is perfect for the modern solution where you may have a search box at the top of every screen.

The Search Box Design

The inspiration for this design was partly borrowed from websites and how they achieve search boxes. Two examples that come to mind are imdb.com and tv.com.

When you begin searching at imdb, matching results drop down underneath the search box. The size of the box shrinks or grows depending on the results found. If too many are found, a link at the bottom is provided to view the full results.

TV.com is also very similar. Results drop down displaying an image, information, and a few links to useful pages. The box resizes again depending on results found.

The Goal - Build This in FileMaker

That was the goal. How close to this look and feel can we achieve in FileMaker natively. By that I mean no plugins, but I also mean no web viewers. I want this to be native to the point that making any changes to it's look and feel is achieved through using layout tools.

SO how did we do?

What you are seeing above is all native FileMaker. In order to make this usable on different layouts, it had to be easy to transport anywhere, and hook up for any given search box. A few points on this:

We give the appearance of a results box that shrinks in size as fewer results are found.
We can display the number of results found, or 0 if none are found.
Results are scrollable.
Results dynamically show as the user types.
The results box only shows after the user beings typing.
The results box disappears if the user exits the search field.

Pretty cool huh? We think so!

Breaking it Down into Components

So what is actually going on here? Well, if you like to get stuck in and figure this out for yourself, there is a demo file at the bottom of this article you can grab and dissect til your hearts content. For those who would like a bit more information, read on.

Here is our search box setup in layout mode. We have numbered 6 key components to the search which we'll go through step by step to understand what they are and their role in creating the interface. Briefly what we have is:

The search box
A button bar
A top horizontal line
A middle horizontal line
A bottom horizontal line
A single sliding panel

And of course a portal to show the results.

We make use of the hide layout object condition to create the illusion of a box that shrinks in size as results are refined. Our lines are shown or hidden according to a set of rules to achieve this. The sliding panel is used to enclose all the objects we wish to hide en-masse (it's just an easy way to manage them).

Next we'll look at each object in a bit more depth.

But First Some Naming Conventions

The interface has a number of components, but two of them contain object names which are key. We use a naming convention for these:

The search box can be named anything you want, but we've called it "search"
The sliding panel used to enclose the rest of the search UI is named <searchfield>.panel. So in our case, it is called "search.panel". We use this convention so that scripts can determine what the object panel name is based on the search fields object name. It saves any hard-coding or parameter passing of object names.

The Search Box

There really isn't much to the search box. It's just a global field we placed on the layout to accept user input. We format it to look how we want.

The magic is applied to the search box through script triggers:

Quite a few aren't there? Fear not, only half of the triggers are concerning the user interface. The onObjectEnter and onObjectExit triggers are for deciding whether the results are to be shown or hidden. We always hide when the search box is exited, but we only show once the user begins typing. the onObjectKeystroke trigger is part responsible for searching, and part responsible for refresh of whether to show/hide results.

We will cover how the searching is done later on in the article.

Button Bar Calculation for Results Display

While this isn't absolutely necessary, it's a really nice touch to tell the user how many results are found, and more specifically if nothing is found. We use a button bar so that we can place the calculation for display direct on the layout in this object.

We won't bother showing that calculation here, you can check it out for yourself in the demo. Basically it looks at how many records are found through the relationship to our results, and displays a text string based on that number, pretty simple stuff.

Top Horizontal Line

Now things get interesting! Our interface has 3 key horizontal lines which we'll call top, middle and bottom. The purpose behind all three is to show one of the 3 at any given point in time, hiding the other 2. The lines act as the bottom of the results box. There are three scenarios for when these lines show.

In the case of our top line, this will act as the bottom of our results box if there are NO results. In this case, we just show the "no results found" display text, and our box ends there.

So conversely we hide this line when there ARE results.

Middle Horizontal Line

So now that we know our lines are to show the bottom of the box, can you think of when we would have this middle line act as the bottom of the box? I'll give you a clue, this line sits within a portal row at the bottom of the row.

Got it yet? How about if we only had 3 results found? Or 2? or 1? yes! This line is used as the bottom of our box when we have fewer results found than the number of default rows of our portal.

In our demo file, our portal is setup to show 7 rows. If we only find 3 results, then we want the bottom of our box to end at the bottom of the third row.

So, our rule for this line is that it is to be shown if there are results found, and where there are fewer results than our portal default. Or the converse of this: We hide it when the results are more than the number of portal rows.

Because this line sits inside the portal, we don't need to bother with the condition of whether there are results or not, this is going to be hidden if there are no results. However it will display on every portal row for which we have results, hence we must hide it on all bar one.

Bottom Horizontal Line

Ok so hopefully with top and middle out of the way, the reason for the bottom line should be obvious. If we have lots of results (more than the number of portal rows by default) then we want the results box to be the bottom of the portal. So this line sits just underneath the bottom of the portal.

If there are more results found than the portals default, we show this line, otherwise we hide it.

The Results Panel

This is a transparent, no bordered single panel control. We use this so that we can enclose everything else inside it, and then we can just apply a single hide condition to the panel to show/hide everything inside.

The design for our results panel dictates that if the user is not inside the search box, then we will not show any results display. If the user is inside the search box, we only show results content if they have typed at least one character, otherwise we show nothing.

Showing or Hiding of the results panel is done by way of scripts that execute when the user both exits and enters the search field. Recall our panel has an object name, so showing/hiding of this is performed by simply refreshing the panel object (which triggers it's hide condition to run).

Still with us?

Good! We're almost there. Hopefully you can follow the reason behind the design components and why we show/hide certain elements under certain conditions. But how do we hide things?

We wanted this solution to be completely transportable and applicable to any other search box in your solution with as minimal effort as possible. To that end, we built a custom function in which all logic for showing/hiding UI components is contained.

This is our custom function called @SEARCH_ShowHide. The function takes 4 parameters:

_searchObjectName: This is the object name of our search box
_hideObject: This is a keyword that identifies which of the 4 hiding components we are trying to hide (top/middle/bottom line or panel).
_displayRows: How many rows does our results portal show by default
_resultsKey: This is a reference through to a primary key on our results table, and we use this to determine various bits of information around how many results were found.

When we setup a hide condition on one of our 4 main hiding elements, we simply reference this custom function. Here is an example of the hide condition on the middle horizontal line:

@SEARCH_ShowHide ( "search" ; "line_middle" ; 7 ; Interface_CUSTOMERS__results::id_customer )

We have told it the name of our search box, what component we are hiding, how many portal rows we have for results, and what the results primary key is.

We're not going to post all the code for the custom function here, you can look for yourself within the Demo File, but we'll point out a couple of things:

We count the number of results using Count function. This can often be not ideal especially if large numbers of results are found. You can always replace this with our technique found here in an earlier article by adding a foundcount calculation to your table. We opted to not do this here in order to keep the solution free of needing to add extra fields to your tables.
We make use of the dual nature of custom function parameters being both a value AND a reference to a field (big thanks to Wim Decorte of Soliant for his brilliant and invaluable article on the technique here). Using this technique we can count records within the custom function.

So Putting it all Together Again

Here's what is going on:

User enters into search field. If there is a search, we run a script to show the results panel if not we keep it hidden.
User beings searching. We show the results panel. Hide conditions determine the size of the results box
The user clicks upon a search result to navigate away, or exits the search field. We run a script to hide the results panel.

When you put it like that it's really quite simple. There are a number of components but on their own they're all pretty simple and easy to see what role they play.

Applying to your own Solutions

Building this into your own solution is simple. If you already have results being shown in a portal, then you're all set. Just paste into your solution and change the following:

Change the parameters in the hide conditions on the 4 main objects to suit your solution
Make sure your table has a primary key (a unique value) to use, if not then shame on you!

A note on Portal Filtering versus Relationship Filtering

This demo file has used filtering of results at the relationship level, and we do not use portal filtering. Digital Fusion has always had a policy of using relationship filtering where possible due to substantial performance gains to be had when working with larger data sets.

That is not to say portal filtering is bad, nor we never use it. For this demo, if you wish to use portal filtering then you will need to make a few modifications to the solution. Our demo checks the number of records found through the relationship to determine the number of results, and apply hide conditions accordingly.

The number of results found through portal filtering is a little different to obtain, as the relationship record count may differ from the portal record count. One technique you can use is to add a COUNT summary field to the results table, and place this inside the portal with an object name attached. You can then use GetLayoutObjectAttribute ( "ObjectName" ; "Content" ) to obtain the found count. This can be inserted into the hide custom function in place of where we count records found.

We won't go into much more detail into this here, suffice to say it is a change that can be made to use this technique with portal filtering.

Delaying the Search for Performance

Our search box uses script triggers to carry out when the reevaluation of the relationship occurs. This is a pretty common technique used to produce dynamic search results for years in FileMaker, ever since v10 introduced triggers.

We take this one step further. The traditional approach is to refresh search results after each keystroke. This can suffer from performance issues, specifically when there are many results found, or the user is over a WAN connection. THe user often finds themselves being unable to continue typing their search term while they wait for results to load. This can compound itself when results begin showing immediately after the first character is typed - as often the most results found are at this point in the process.

Our solution is to introduce a short timed delay before filtering occurs. We use an onTimer to control this delay. Every time the user enters a keystroke, we reset the onTimer which resets the delay. Once the user ceases typing, the delay occurs and after that the onTimer script runs, which carries out the search.

To give a basic illustration, consider the user typing the word "David" into a search box:

"D" is typed, an onTimer is started at 0.5 seconds
"A" is typed quickly after, the onTimer is reset back to 0.5
"V" is typed, slower this time, but still only 0.3 seconds after the "A". The onTimer is reset to 0.5
"I" is typed quickly, again the onTimer reset back to 0 .5
"D" is typed, the user is done typing. The onTimer delay expires after 0.5, and the script runs,carrying out the filtering.

If the user stopped typing at the "V", then filtering would occur there. If they continued typing the rest of the word, filtering would again occur 0.5 seconds after the last "D" was entered.

Going back a couple of years now..

We actually wrote an article on this technique a few years back now. You can read it here. The general techniques in that article are exactly the same as they are in our demo file now. In our current demo file we have simplified some things such as script parameters just to make this file easier to understand.

Using escape key as a quick clear

Because this technique uses an onLayoutKeystroke trigger after each keystroke, we can intercept certain characters and change the resulting behaviour. This is exactly what we have done when we detect the escape character is pressed by the user in the search field. In this case, we clear the search field contents. This is a nice intuitive way to clear the field rather than providing an X icon.

What about Relationship Filtering?

This is another one of those "many ways to skin a cat" things in FileMaker. Some prefer using portal filters, others relationship level filtering. At the relationship level, some build big keys, while others opt for exact matches.

Exact matches in this case are pretty useless, and keys that are built are often big and cumbersome.

A few years ago now, Danny Kohn on the webiste FileMakerInspirations.com wrote a very insightful article into this problem, and posed a technique using the ≤ and ≥ predicates of relationships, and the sort ordering of text in FileMaker to achieve a relationship filtering technique that results in a very lightweight key field.

You can read his article in full here. It covers the technique really well and so we won't go into much more detail on it in this article, suffice to say our demo file makes use of this technique.

Demo File

What good is an article like this without a demo file to accompany it right? Well here it is! No username and password, fully unlocked just go for it.

ModernSearchUI.zip

Options for distributing FileMaker apps

Mon, 31 Oct 2016 00:00:00 +1300

One of the coolest things that has happened with FileMaker over the last couple of years is the ability to take a FileMaker App and put it through the SDK (Software Development Kit) treatment. The end result is a standalone iOS app that comes with all the features you would expect out of apps in this day and age.

We have already written on why we think this is cool along with very detailed instructions on how to do this yourself but the missing link was how do you then distribute you app to your clients, co-workers etc.

The following blog post outlines some of the options currently available at the time of writing*

Custom B2B Distribution

Key Points

Custom B2B distribution is exclusively available for purchase through “Volume Purchase Program”
The app is hosted and distributed by Apple
It gives exclusive access for business members that you identify in iTunes Connect
Customers sign in and purchase their apps on the Volume Purchase Program store
There is no minimum price for the app
There is no facility to directly transfer to or from the app store. This means it will always remain a B2B app
Any updates you wish to make are the same as for app store
You may use “Promo Codes”. This way the app can be given to people NOT in the list of Apple ID’s that is used for distribution, for a limited amount of time.
Volume Purchase Program available in Canada, UK, France, Italy, Germany, Spain, Japan, Australia, New Zealand and USA.
Can be used with Mobile Device Management
The general public cannot see the listing.

Costs

The cost associated with getting your app into the B2B programme are $299 per year for an Enterprise Developer Licence and the App store margin is 30%

How it works

After you complete your enrolment in the Apple Developer Program, make sure your tax and banking information is set up in iTunes Connect

(Learn about enrolment)

Next up you need develop and test the application that will solve a problem for your customers.

You then selecting your pricing options which could be free or at any price tier you select.

Once you identify your customers and release date, you’re all set

(Sign in to iTunes Connect)

Finally you need to select the custom B2B distribution option in iTunes Connect. If your app contains sensitive data, provide sample data and authentication for our review team.

(iTunes Connect Developer Guide) (App Store Review Guidelines)

What business customers need to do

Once your customer has a volume purchasing account with Apple, they can easily buy apps that meet their business needs, and get custom B2B apps you’ve built for them

(Learn more about the VPP for Business)

Custom B2B apps will appear in your customer's Volume Purchase Program account. Customers select the app and enter the quantity they want to purchase

(Volume Purchase Program store)

Your business customers can use third-party Mobile Device Management (MDM) solutions to help manage and distribute their apps. Or they can provide redemption codes to their users via email or an internal website

(Learn more about Mobile Device Management)

Technical

You cannot submit the same app to app store. You can generate a new appID for it if you want to do this though.
Must provide test login for Apple
Promo codes must be requested from Apple.
Business needs a “DUNS” number to use the volume purchase program. This is installed by emailed URL or use a licence code
Can be used with Mobile Device Management ( MDM )
This can be installed using Apple Configurator
The configurator can be used to redeem codes against the device, not the Apple ID. This is the only way to do this
If using Supervised Devices, the Apple configurator can be used to activate single app mode ( for iOS 6.0 or greater )

App Store Distribution

Key Points

The app is available to general public
Apple provides the distribution service – The App Store. It is highly available and well understood by users
The App Store promotes your company on a highly visible marketplace
The App Store approval process is required for initial app deployment and app updates. This can often be the tricky part of getting an app into the App Store and it could take you a number of attempts to be successful. The approval process can take a few days or a few weeks.
The App Store provides information about your app including a description of the app’s features, screenshots and an indication when the app is updated.

Costs

You will need to get yourself an Apple Developers Licence which cost $99 per year and like the B2B option, Apple takes a store margin of 30%

Ad Hoc Distribution

This options is predominantly used for testing purposes and can only be distributed on up to 100 iOS devices.

Some of the other details that surround the Ad Hoc option are:

Devices must be manually registered using their UDID
Devices can be removed/replaced once each membership year
The App Store approval process is not required
The general public cannot see the listing, purchase or install the app
The related developer provisioning profile expires in one year - meaning that it can only be used on a given device for a year.

Enterprise In House Distribution

The final option is to distribute it on on an in house enterprise method. This is not curated by Apple and may not be used outside of your business.

*We are in a time when things move very quickly so we have attempted to be as accurate as possible at the time of writing. We can’t offer any guarantee the above options or the processes you go through are accurate moving forward.

A marriage made of dreams, code and custom T-Shirts.

Mon, 17 Oct 2016 00:00:00 +1300

Some say you make your own luck and this story shows there is at least a kernel of truth in that, but I can’t help also feeling that sometimes you just get lucky. This is the story of how I landed my dream job at DF.

From an early stage in my FileMaker development trajectory I had identified Digital Fusion as a standard setting team to watch and learn from. It was a bitter sweet day when I found a job advertisement online for a new developer to join the DF ranks. At least they were hiring so there was hope one day, but I knew I still had too much to learn. However, perhaps my biggest hurdle was that I was based and committed in my home on the outskirts of Brisbane , Queensland, while the nearest DF office is in Sydney.

A Brisbane based, developer, mentor and friend of mine was aware I was looking at shifting my career into full-time FileMaker consultancy. He’d been approached about a project he couldn’t take on and put my name forward.

Enter the T-Shirts. Located near Brisbane Airport, at Eagle Farm, Queensland, QTCo or Queensland T-Shirt Company, is a leading Australian supplier of branded products for business and promotional use. They can source and brand pretty much anything and everything but also have dedicated in-house apparel and screen-printing business units. Excitingly, they also run one of the most significant ‘direct to garment’ (DTG) printing enterprises in the Southern Hemisphere.

The team at QTCo had the kind of problem you hope for in business. A significant international client, offering a large increase in sales , beyond your current system’s capacities to deliver.

The client is an international, web based, marketplace for artists. Products such as T-shirts are produced ‘on demand’ when an order is placed and shipped direct to consumers by local ‘fulfiller’ partner enterprises. They had their eye on QTCo to be the Australasian fulfiller for printed garments, but QTCo needed to develop solutions to integrate with the client’s automated ordering system, manage inventory and print workflow using barcode scanners and automatically create shipping labels and submit manifests to Australia Post for delivery.

I needed help with some of the web integration elements of the project so I reached out to Stuart Woodhouse and suggested Digital Fusion might work with me on it. Along the way, we discovered we work very well together.

One day, while watching the latest bag of printed shirts getting packed and shipped from QTCo, it occurred to me there may be a way to stay in Brisbane AND work with the team at Digital Fusion all the time. So I suggested DF may like to look at taking me on in Queensland with a view to better supporting and growing their client base here. I’m still waiting on my finder’s fee for head hunting myself, but otherwise I think this plan ticks all my boxes.

Sortable - A Developers Journey

Fri, 07 Oct 2016 08:06:00 +1300

What follows is a tale of a developer. Like many tales it twists and turns, guiding the protagonist to embark on a journey of discovery. This journey of discovery is not conducive to a linear tale, but the richest of experiences is always a product of re-evaluation, self-discovery and enlightenment.

One of the great things about FileMaker is its willingness to bring other friends to the party; it doesn’t restrict us to a proprietary end-to-end environment. There are many great ways to introduce integrations and other technologies. The most powerful of which has got to be plugins.

A FileMaker plugin is a file, created in C or C++, given the appropriate extension. The plugin can then be loaded into FileMaker Pro to expand the set of functions available. There are also third party plugins that allow you to develop your own plugins in PHP or Java.

Or, we can develop our own plugins using our very own Reactor! But more on that later...

While the FileMaker platform allows us to build and deploy powerful business applications extremely quickly, it doesn’t give us the degree of control that allows us to build ‘anything’ in FileMaker Pro natively.

But this is a good thing!

Because were that not the case, we wouldn’t be able to build and deploy applications as quickly as we can.

However, FileMaker Pro is happy to hand the job onto someone else. There are two ways to use develop a client-side interface using web technologies; in a WebViewer, and using Reactor.

The Mission

There have been many moments when building portals in FileMaker Pro that this developer wished they could drag around portal rows to re-sort them. It occurred to me that building a portal in HTML+JS could allow me to manipulate the portal anyway I desired.

The WebViewer

I got to work. With a basic knowledge of HTML+CSS+JS I put together a web-based portal, and transformed it into a custom function. The custom function was passed in a Javascript array of IDs and sort orders, as well as the script to run when the sort order changed. The sort order was changed when the portal rows were dragged up or down - using JQuery’s incredible UI Library. When running the script it would pass as a parameter the ordered set of record IDs. It worked.

The Problem

While it worked, it wasn’t very modular. I had to encode the data into a Javascript array, and decode it at the other end. It was working around FileMaker rather than working with it. It would be difficult to take it out of this solution, and pop it into another one.

The Solution

“Why don’t you just use Reactor?” I was asked by one of my fellow colleagues.

That quip gave me pause. While I certainly knew of Reactors existence, I had never had first-hand experience of developing for Reactor and how powerful it truly was.

Reactor? What's that?

fusionplugins.com

At Digital Fusion, we pride ourselves on our Fusion Reactor plugin. Most plugins are developed to perform a certain task or reach a certain goal; be that to integrate with your accounting package, or to perform file operations on a local disk. The Fusion Reactor plugin provides a gateway. What lies beyond that gateway is entirely up to you - the developer.

JavaScript is really the only way to create new and unique UI controls (widgets) for FileMaker applications.

The combination of HTML5, CSS3 and Javascript has provided an almost unlimited palette with which to build web applications; if you can dream it, you can do it. Anything you can conceive of in a software application can be built using this combination of technologies.

Reactor is a plugin developed by some wizards at Digital Fusion Ltd, well before my time. Basically it’s a plugin that allows us to build our own plugins using front-end web technologies. Reactor allows us to install and run these things called BlackBoxes. Far from a flight-data recovery tool (which I should avoid dwelling on - as I write this from 35,000 feet over the Tasman sea) it is a web app. I was able to write the source for the web app, and deploy it into a BlackBox that could then be installed onto any machine that has Reactor installed.

Where’s the Reaction?

So far, no different. We’ve basically done what we did with the WebViewer and custom function. Where Reactor really adds value is the way it can talk with the database. The Reactor toolbox contains a suite of tools that facilitate communication between our Javascript and our FileMaker data. No more did this developer have to parcel up their data in a form the Javascript can understand, and un-parcel it when it’s done. Any transactions with the FileMaker data could take place within the Javascript itself. It was now completely modular and fully portable.

Like all great tales, the Sortable application basically boiled down to three acts:

Act I: Retrieve the data

When the application is loaded it downloads the records - it knows what records to download and display in the portal because we pass through a table occurrence with field name as one of the parameters - this takes into account the relationship to that table occurrence. In the Javascript, we can pull through any fields we wish; such as current sort values, UID, type, value 1, value 2, image, etc. These are all set up as parameters as well.

Act II: Manipulate the front-end

The next step is to write the Javascript, so that an HTML element can be dragged about a list of HTML elements. This is remarkably easy to do using the JQuery UI Library, we just need to instantiate the Sortable class, and tell it what to do when an element is dragged to a different location.

Act III: Preserve the new sort order

So far, all we have done is move objects about a portal. The next step is to actually have it do something. When the element is dragged to a different location, we call an asynchronous function. This is really nice because the users experience is truly seamless. We loop through every item in the portal, updating the FileMaker Pro data with the new sort order. We do this by calling a script, passing through the UID of the record, as well as the new sort order.

Where To From Here?

I emerged triumphant. I had achieved my goal in developing a solution that was modular and portable, and learned a lot of about a powerful tool that paved a new way to a world of exciting possibilities.

In particular, I'm very keen and excited to explore other great front-end augmentations and features that can be made possible with other components of the JQuery UI library. Sortable is just one of them:

https://jqueryui.com

Interactions and Widgets

Draggable - drag object around an area with the mouse
Droppable - drag objects and drop them onto/within other objects, activating an action
Resizeable - change the size of an object using the mouse
Selectable - click-and-drag the mouse to select multiple items (could be an awesome alternative to sortable where multiple rows in a portal can be selected with the mouse)
Accordian - headings that can collapse more detailed information
Auto-complete - predict user input in text fields
Button - enhances buttons, to make them fully customisable
Dialog - produce a customised dialog that can be moved and closed
Menu - create fully customised menus, including disabled items, nested items, able to be navigated by both keyboard and mouse
Progress Bar - customised progress bar of a pending process or action
Select Menu - similar to popup fields in FMP, but with icons and grouping
Slider - customisable slider to set numerical values
Spinner - customisable spinner to increment/decrement numerical values
Tabs - fully customisable tabs. Can open tabs on hover rather than click, can add/remove/sort tabs as user, etc
Tooltip - many awesome customisations for tooltips, beyond what might be termed as conventional

Effects

We can use the JQuery UI suite to add classes to objects, therefore adding effects. For example, we can animate an object to transition from one color to another, animate the easing of an object (gradually show/remove), or animate any effect at all such as bouncing, dropping, shaking, pulsating, etc.

Effects such as these are all over the web to augment the users experience, and using Reactor they can be added to any FileMaker Pro application to do the same!

Introducing Morgan Chance

Tue, 20 Sep 2016 08:49:00 +1200

For a number of years now, Digital Fusion have had a large number of clients in Brisbane and the greater Queensland region.

These clients have been looked after by our sales and development teams, with a short skip and jump up from Sydney.

But now we are pleased to announce that we have a full time staff member based in Brisbane and he will be focusing on just the Queensland region (we feel it's time to repay the love)

Morgan Chance starts with us at the beginning of October and will have many hats to wear.

As well as being our client manager for Queensland, he will be working with clients as our business analyst plus taking on FileMaker development projects.

Morgan comes to us with an incredibly interesting background, so we asked him to write us a bio on what he's got up to through the years....

Prior to graduating with a veterinary science degree, Morgan worked in a variety of industries including food animal production (farming), veterinary retailing and nursing, transportation, merchandising and printing. On completing his studies he began several years of rural, mixed animal veterinary practice in a predominantly beef cattle region of Northern New South Wales.

In preparation for a sea change, Morgan completed a high school science teaching diploma and moved his large family to the Island paradise ‘North Stradbroke Island’ in South East Queensland.

High school teaching led Morgan to engage with a local university marine research station where he settled into a role managing science education field activities. Along the way Morgan established a house call veterinary service for Island residents.

Struggling with his data needs in this service, Morgan discovered FileMaker and found it such a user friendly and accessible platform he started using it to develop solutions at the research station as well.

Recently, he has been working on production floor, order and logistics automation systems for a rapidly expanding international garment printing enterprise.

Morgan enjoys exploring business systems, imagining future potentials and especially loves those eureka moments when a challenging business requirement crystallises into a design solution.

As a footnote, we thought we had done well by employing our first Australian staff member in a while, only to discover that Morgan was born in Auckland. His redeeming grace is he only lived there for the first few months of his life.

FileMaker Certification

Tue, 13 Sep 2016 08:00:00 +1200

With every release of a new version of FileMaker, we like to get our developers certified, both as a way to upskill our team, but also to show our passion for FileMaker.

FileMaker 15 was released earlier this year, and soon after the certification exam was released.

Passing the exam is not easy, it involves quite a bit of study on our developers behalf, and the pressure to pass is high, particularly when you are last to sit the exam.

We are now proud to say that all eight of our developers are FileMaker 15 certified.

As our company motto goes…. FileMaker - We know it. We love it. We live it

Tiki Tour To DevCon

Wed, 13 Jul 2016 00:00:00 +1200

Tiki Tour: New Zealand slang for taking the scenic route to a destination.

A British Experience

About 9 months ago, I made the decision that I needed to be at one of the biggest music festivals in the world - the Glastonbury festival in Somerset. I was also one of the lucky souls of Team Digital Fusion that would be attending DevCon in 2016, so I thought I could make the most of this, and line a personal holiday up with DevCon, which one might term a Working Holiday.

Glastonbury Festival of Music and Mud

Well, I am now on the other side. And I can say that it was amazing fun, I shall always look upon it fondly, and I NEVER want to do it again. EVER.

Getting in was pretty delayed, but people had it much worse. I think it must’ve been worse the day after we arrived. It’s a 3.5 hour ride in from London, and it took about 7-8 hours.

Musical highlights were definitely Coldplay, Madness, Muse and this incredible Beatles cover band I happened to stumble onto on the last afternoon. People seemed to really enjoy Adele, which I did attend, but not really my thing. I left half-way through to see the Bowie Tribute Laser Show.

Festival highlights were just the overall vibe of the festival, it really is incredible. 170,000 people crammed into a farm, which is set up as a commune, but with heavy capitalist influences. Everywhere you turn is somewhere you can buy food and/or alcohol. Any sort of shop you can imagine is represented as well. Moving between the main stages is akin to getting around downtown Sydney or London during rush hour.

The mud. I will never forget the mud. It’s not an object, or even an adjective. It’s a medium through which the whole festival exists. I was expecting there to be some mud around, but in reality, the mud was good enough to host a festival for us. However, I have since learned that due to the torrential rain leading up to the festival, 2016 was the muddiest Glastonbury ever.

And now it’s all over. People I was there with are already making plans to do it all again next year. Nope. Never again. 10 stars.

So on with my holiday. Though I have written tomorrow off for recovery and laundry. Mud is in EVERYTHING.

With Glastonbury done and dusted I still had a couple of weeks before DevCon — this left me with a bit of a dilemma. I would be based in London for the most part, but the thought of keeping my sightseeing to London would be a bit restrictive, and not quite sufficient to fill up two weeks. I was keen to see more of the country, but wasn’t keen on spending a fortune to do it - nor coming up with the logistics of doing so...

Enter Contiki Tours!

Contiki Tours is an organisation that carries out tours for people aged 18-35 of Europe, USA, Canada, Asia, Australia and New Zealand.

It was actually set up by a Kiwi, John Anderson. John Anderson set off for a big OE in England, but found he was too short of money for everything he wanted to see. So he devised a cheeky scheme, and advertised a new tour for Australasians with only a few seats left available. He heard back from 11 people excited to join this very popular ‘tour’, and were more than happy to pay to join the trip. So he worked out the total costs for the trip, charged each applicant an equal share, and bought a van. Having secured himself a free place on this tour as the tour guide, he could now begin his OE. He was completely unable to maintain the facade of being an experienced tour guide, so he quickly confessed his inexperience to the group, and they all shared in the responsibilities and duties - including the driving! It is from this that Contiki Tours grew into the massive operation it is today. However it’s a bit more professional these days, and the trip managers are much better informed!

When I was discussing the gap in my trip with a friend, they floated the idea that perhaps I could do a Contiki tour. I looked into it, and it seemed perfect. I could see England and Scotland in the time-frame I had available, and I didn’t need to do anything beyond paying the fee and turning up. Everything is pre-arranged.

Somehow, I managed to set it up to do a tour of England at a time they were facing dual crises. Not only did the Brexit decision get announced a week before my trip, England were eliminated from the UEFA Euro playoffs - in a shock loss to Iceland. But they are a hardy bunch, and it didn’t impact my trip at all (other than a slight improvement in the buying power of my NZ dollars).

At 6.30am I turned up at the meeting place, and after some formalities (showing passports, travel insurance, next of kin, etc) we were off on the road - the road to Liverpool. What I found remarkable was that most everybody was in the same boat as me. They were travelling alone.

There were very few friends amongst the group - at that stage anyway. Ironically, I believe that creates a friendlier environment, because everybody is that much keener to make new friends. For the first leg of our drive to Liverpool, we were pretty much left to be - or rather to sleep.

Curve Ball

Then after we stopped for lunch, the trip manager pulled out a curve ball I was not expecting. We were to undergo a speed-dating inspired method of getting to know each other. Anybody in the aisle seat would move forward to the next person asking a set of questions to get to know them until the buzzer went off, and they’d move to the next person. The questions were of standard fare; what’s your name, what do you do, is this your first tour, etc. As an introvert, I found this positively terrifying and I just conducted it in a similar manner to the dentist - of just getting through to the other end.

But the energy of the bus completely changed after that. I don’t think it’s because you learn more about the other people in the trip - I forgot everything instantly. But what I think it does do, is just loosen everybody up. I discovered throughout the rest of the trip that most people hated it - but afterwards everybody was laughing and chatting in a way they weren’t doing before hand. Well played Contiki.

So that set the tone for the trip. From London we saw Liverpool, York, Lake District, Edinburgh, Scottish Highlands, West Highlands and Glasgow. The weather was absolutely appalling for the beginning of summer - but living in New Zealand I’ve learned that if you get upset at disjointed expectations about weather you’ll drive yourself nuts. Anyway, it added to the trip - to get the authentic British summer weather.

Roomies

Something I was particularly anxious about was sharing a room. I am a snorer, and like all snorers I have a bit of anxiety about how it affects others. Contiki do offer a single room for the hotels you stay at, but the cost didn’t really make it worth it for me. So I mentioned this to my room-mate the first night, and to my eternal relief he said he too was a snorer. Sharing a room with someone was something I found very strange at first, but after a couple of nights I had totally acclimatised and it didn’t bother me at all. Maybe I was very lucky to get a great room-mate I got along with really well. Also I think having a room-mate sort of stops either of you from sleeping in past the departure time. Two alarms are better than one!

So for nine days we went from town to town, and saw some amazing things and went to some amazing places. Hadrian’s Wall, Edinburgh Castle (as well as countless other castles), the Edinburgh Dungeons - which were absolutely terrifying, the Lake District, York, the Cavern Club in Liverpool, the Isle of Skye, the Loch Ness...

The Loch Ness Challenge

Loch Ness posed the next step 'outside my comfort zone': The Loch Ness challenge — basically to jump into the Loch which might sound fine to those in warmer climes where summer is indeed the perfect time to jump into a lake. And we're pretty sure there is no "nessy" lurking in those unfathomable depths... However this Scotland, and it turns out Loch Ness is the same temperature all year around - a toasty 6 degrees, so being summer doesn't help.

I had told people I’d do it, but the day leading up to it was cold and miserable, and I really didn’t want to. But I went with the flow and ended up jumping in. Then after I got out and dried myself someone said ‘Shall we do it again?’, so I dropped my towel, went back to the pier and did a majestic bomb into the water this time - not like my timid step off the edge I did with the first one. It was a fast recovery with another towel-dry and shot of whiskey.

Before I knew it, the tour had come to an end. I had found that in the short space of nine days - which had gone by in a massive flurry, I had made some awesome new friends - the only stinger being that I’ll probably never see most (if not any) of them again. But that’s part and parcel of it, and can’t dwell on it too much. What made the end particularly difficult was that I had picked a modular trip. This meant that our of around 50 of us, 17 of us were dropping off, and the rest were continuing onto Ireland. I wouldn’t recommend a modular trip as most of the remaining people on the tour are now my friends on Facebook, and I keep seeing photos pop up of their amazing time in Ireland. For example, this came through a few hours ago:

Future Plans...

Unlike Glastonbury, I’m already making plans in my head to do another one - a proper big one, around the main tourist parts of Europe. Unfortunately I am approaching the dusk of the 18-35 year old range, so that leaves me with just a few years. So if you’re curious about it, I would say absolutely do it. And if you want to travel, see the world, and you’re not sure how, it’s perfect. Check their website to see what’s available, and you’ll have an absolute blast.

https://www.contiki.com

They talk a lot about the Contiki Family you develop, and it does sound like marketing nonsense. But it’s true. Even after a relatively short tour such as mine, a group of complete strangers are transformed into close friends over just nine days. I have even caught up with a couple of them since the tour ended, for some sightseeing in London.

FileMaker iOS SDK - Part 4

Thu, 12 May 2016 10:05:00 +1200

Building an iOS App from a FileMaker Database

Welcome to the fourth and final part of the FileMaker iOS App SDK series. In the final part of the series I will take you through building and compiling the iOS App. If you haven't yet read through parts 1, 2 and 3; now would be a good time to go take a look.

Building the iOS App

We will start by opening the WindowFurnishing.xcodeproj file that we created in part 3. In the Xcode project window we’ll click the disclosure triangle next to Custom Application Resources and again next to Solution Files. The Solution Files directory is where the iOS App expects the FileMaker files to be.

It’s important to note that each iOS app has its own documents directory in addition to the Solution Files directory. When the WindowFurnishing app is launched for the first time on iOS, the files from the Solution Files directory are copied to the WindowFurnishing app documents directory, from there the user adds / updates the data in the app documents directory files. When an iOS device is plugged into a computer with iTunes installed you can access the App documents directory by selecting the iOS device >> Apps and the app name in the File Sharing section.

We will remove the PlaceHolder.fmp12 file by selecting it and pressing delete. We can copy our files into the Solution Files directory by dragging and dropping on the folder in the Xcode window.

With our files in place we need to tell the iOS App what file to open at launch. In the Custom Application Resources folder Click on the configFile.txt file and change the following line

launchSolution = PlaceHolder.fmp12

launchSolution = WindowFurnishing.fmp12

If we try and specify a file name in launchSolution that doesn’t exist the iOS App will fail to build. The launchSolution file name is also case sensitive, if we don’t get the casing correct the build will succeed but the iOS App will not launch the FileMaker solution.

There are two further options in the config file that can be changed:

helpURL - this is the URL to your apps support or help site, if this is left blank the help menu is removed from the app. If your custom files are being opened in Kiosk mode the help menu will not be available.

alwaysOverwrite - this specifies whether the Solution Files are copied fresh into the apps document directory when the app launches. If this is set to 1 everytime we launch the WindowFurnishing app the Solution Files will be copied into the documents directory. This means that the files will “reset” at each launch. Setting this value to 1 is only recommended for testing purposes.

We'll save our changes to the config file and continue on.

Creating and Adding images

We’ll now create and add some icons for our iOS App, icons and images need to follow the Apple guidelines for icons and image sizes.

Adding icons to our App is very straight forward through the drag and drop interface provided in Xcode, to access this interface click on the CustomAppAssets.xcassets folder. We can see there are three icons sets available for changing: AppIcon, LaunchImage and ObscureIcon.

AppIcon - The app icon is the icon that we see on the iOS home screen. iOS devices will have different icon size requirements depending on model.

LaunchImage - The launch image is used as a splash screen while the iOS app launches

ObscureIcon - If our FileMaker app uses the fmreauthenticate extended privilege the iOS App will display a security shield over the content when the iOS App is moved into the background.

Let's start by clicking on AppIcon and dragging our icons in for each of the devices and sizes required. Xcode will show a warning triangle in the title bar if we have used any incorrectly sized icons. Clicking on the warning triangle will present a dropdown showing the list of warnings. We will be able to build and test our iOS App with these warnings but there is no guarantee the icons will look as expected on all devices and versions of iOS.

Changing the Settings of our iOS App

Before we can build and test our iOS App we need to change some settings. Our iOS App requires Data Protection to be enabled, a version number and a build number.

We’ll start by enabling Data Protection. Click on the WindowFurnishing project and then click on capabilities in the main project window. We can see that Background Modes has already been turned on for us, we’ll find Data Protection in the list and click the toggle to turn it on.

Next we need to specify the version and build numbers for our iOS App, we’ll click on the General tab in the main project window to bring up these settings. In the Identity section add the version number and build number.

Optionally we can specify a URL scheme for our iOS App. FileMaker Go uses fmp for its url scheme, we will have to use a unique URL scheme. We'll start by selecting the Info tab in the main project window, click on URL Types to open the drop down. We will create a URL scheme by clicking the plus button and entering mcw into the URL Schemes box, other apps and websites will be able to use mcw:// to interact with our app.

Other optional settings

Under the General tab in the main project window we can see there are a few other options that can be set, a few of these options can be safely changed. In the Deployment Info section we can make changes to the following options to suit our needs:

Devices - We can choose the iOS devices our app runs on (iPhone, iPad or Universal).

Device Orientation - We can choose to restrict which orientations are allowed for our iOS App, note that on devices that support full screen this setting will be ignored.

Status Bar Style - We can choose to have the default style or use the light style status bar (this is the bar where the cell info, clock etc is located)

Hide Status Bar - We can choose to hide the status bar in our app completely

Requires Full Screen - If this option is checked our iOS App will not be able to be used in Slide Over or Split View.

On the info tab in the Custom iOS Target Properties section we can also change the “Application supports iTunes file Sharing” option. This is set to Yes by default, if we change the value to No users will be prevented from accessing the app documents directory through iTunes.

Compiling and testing the iOS App

We are now ready to compile and test our iOS App. First we need to ensure that our device is plugged into our computer and unlocked. We will specify which device we will be testing on by selecting it in the Xcode window. Click on the device menu to bring up the dropdown. The devices menu lists the devices plugged into the machine as well as any iOS simulators that are installed (the latest devices are installed along with Xcode). We can use the simulators to test our app on device that we may not have physical access to.

With our device selected we can go ahead and push the play icon in the title bar. A progress indicator will be displayed in the centre of the Xcode title bar indicating the Apps build progress. Once Xcode has finished building the iOS App it will be installed and launched automatically on our iPad.

Xcode immediately puts our iOS App into debugging mode, we can stop Xcode from debugging our App by clicking on the debug menu and selecting the detach option at the bottom of the list. If we wish to re-enter debugging mode we can simply click on the debug menu and in the “Attach to Process” submenu select WindowFurnishing, it can take a few seconds for the process list to load.

Congratulations, we have successfully compiled and built an iOS App from our custom FileMaker solution.

FileMaker 15 released

Wed, 11 May 2016 11:02:00 +1200

Earlier today FileMaker released their latest version, FileMaker 15

This is the first time that FileMaker have moved to their annual release pattern so you will start to see updates and patches more frequently.

Firstly, this is a new full release right across the FileMaker product range. This means there is now FileMaker 15 for Server, Pro, Advanced, Go and WebDirect.

Looking at some of the changes across these products….

FileMaker Pro

There is now a new licensing model called - FileMaker for Teams (FLT). This is way licenses are shared across Pro, Go and WebDirect, all connecting to Server. Further details will come from FileMaker around this but there could be use cases where it’s advantageous for you to switch licensing plans.

With FileMaker 15 there is now an improved way to update an application. It is now much simpler to now update your version of FileMaker to the latest patches/versions, this can all be done within the application when a new version is available, just click the prompt to download and install in a single step. You no longer have to go to the FileMaker website and download very large update files.

One of the big gains in FileMaker 15 is around performance. - solutions will perform better than ever. Information in portals will now load independently of the rest of the screen you are viewing, so you can continue to work while portals load their data.

FileMaker Go

Touch ID - Allows you to use the Touch ID scanner to log into your FileMaker Go solutions

iBeacon support - FileMaker Go can now support interaction with iBeacons, useful for detecting when your device is close to a beacon, which beacon is closest, and designing your solution to make use of this information, for example your solution could know whereabouts in a large warehouse you may be at any given time. If you are new to iBeacons check out the following article ... iBeacons explained

Better integration with other apps on the device, the ability for things such as images, movies, music, to be shared amongst other applications on the device, e.g. DropBox, PDF readers, printers, email etc.

FileMaker WebDirect

More refinements and improvements to the platform including better performance. FileMaker WebDirect now offers support for Android browsers meaning WebDirect now works across most platforms (via browser)

FileMaker iOS SDK - Part 3

Thu, 28 Apr 2016 09:47:00 +1200

Building an iOS App from a FileMaker Database

Welcome to Part 3 of the FileMaker iOS App SDK series, in this article I will take you through creating the project directory that will house our app settings and files. In part 1 and 2 we highlighted some considerations that need to be made when developing our solution for iOS, setup our Apple Developer account, added an App ID, created a provisioning profile and setup Xcode ready for developing our App.

We will be building an iOS App from the WindowFurnishing solution we have built for McKenzie and Willis. You can read a case study on the McKenzie and Willis project here.

Signup for a FileMaker Developer Subscription

Before we can create a project directory we need to purchase a FileMaker Developer Subscription and download the iOS App SDK.

Create a Project Directory

The iOS App project directory contains the required files and iOS frameworks for our App. We’ll start by extracting the iOS App SDK to the desktop on our Mac. Once that's done we’ll open the terminal application located in /Applications/Utilities/ or by typing terminal into a Spotlight search. Using the terminal we will change our working directory to the iOS App SDK directory, the easiest way to do this is to type cd followed by a space then drag and drop the iOS App SDK folder in to the terminal window, pressing return / enter will execute the command.

Now that we are in the working directory for the iOS App SDK we can create our project directory by running the makeprojdir command with the required parameters:

./makeprojdir <NewAppDir> <appName> <bundleIdentifier>

NewAppDir - This is where we will store the files required for the iOS App
appName - This is the name we will give our iOS App
bundleIdentifier - This is the identifier we used in Part 2 Registering our App ID

The command we will run in terminal to create our WindowFurnishing project directory will look like this:

./makeprojdir /Users/james/Desktop/McWApp/ WindowFurnishing com.mckenzieandwillis.windowfurnishing

Once the command has completed an iOS App directory named McWApp will have been created for our Window Furnishing App. We'll take a quick look inside the project folder and examine its contents. The folder contains four items:

app.entitlements
iOSAppSDKResources
WindowFurnishing
WindowFurnishing.xcodeproj

Do not modify the app.entitlements or iOSAppSDKResources, these contain important files required for the iOS App.
The WindowFurnishing folder will be used to store our custom App files (along side other automatically generated files).
The WindowFurnishing.xcodeproj is the Xcode project file, we can double click this to open our project in Xcode.

Continue reading with the fourth and final part in the iOS SDK series.

FileMaker iOS SDK - Part 2

Fri, 22 Apr 2016 09:55:00 +1200

Building an iOS App from a FileMaker Database

Welcome to Part 2 of the FileMaker iOS App SDK series, in this article I will take you through setting up Xcode and creating a provisioning profile for an iOS device. In part 1 I highlighted some of the considerations that need to be made when turning a custom FileMaker solution into an iOS App.

Register in the Apple developer program

First things first, we need to register in the Apple Developer program. Head over to the Apple Developer Program page and click the "Enroll" button on the top right of the page. Log in with your Apple ID and follow through the prompts to enroll.

Download Xcode

We will need to download and install the latest version of Xcode, which is available from the Apple Developer website.

Setting up Xcode

Now that we're enrolled in the developer program we can start registering our App ID.

Launch Xcode, click on the 'Xcode' menu and open the preferences dialog.
Click on the 'Accounts' tab. In the bottom left hand corner of the window click the plus icon and select 'Add Apple ID...'
Sign into your Apple Developer account
Once signed in select the 'Team Name' and click on the 'View Details...' button
In the Signing Identities section click the 'Create' button next to iOS Development.

Registering our App ID

Registering our App ID with Apple will allow us to create a provisioning profile which will be used in building, testing and distribution of our iOS App.

Log into the Apple Developer Member Centre
Click on 'Certificates, Identifiers & Profiles'
Under the iOS Apps heading click on 'Identifiers'
Click the plus button to register a new app ID, enter the App ID Description, Prefix and Suffix.
In the App Services section tick 'Data Protection' and ensure 'Complete Protection' is selected
Tick the box to enable iCloud.
Click continue to review our App ID, finally click the 'Submit' button to create the App ID.

Registering our Device for testing

If we want to use an actual iOS device for testing we need to register the UDID (Unique Device Identifier) with Apple.

Under Devices click on 'All' and then click the plus button in the top right corner
Enter the device name and UDID. We can copy and paste the UDID from Xcode.
Ensure your device is plugged in to your Mac
Click on the Window menu and select 'Devices'.
Select iOS device and copy the Identifier, paste this into the UDID field on the Apple Developer site.
Click continue and then register to add your device

Create and download the Provisioning Profile

Now that we’ve created our App ID we need to create and download our provisioning profile.

Under Provisioning profiles click 'All' then click the plus button in the top right corner
Select 'iOS App Development' and select the 'Distribution' method required. Click continue.
Select the 'App ID, Certificate and Devices'. We’ll give our provisioning profile a name and finally click the generate button.
Switch back to Xcode and open the preferences dialog
Click on 'Accounts' then click on 'View Details'
Click the 'Download' button next to our newly created provisioning profile

Continue reading on to Part 3

Subscribe and Ye Shall Receive

Wed, 20 Apr 2016 10:07:00 +1200

Be you a lover of Weetbicks blog posts on how to do fun and funky things using FileMaker or you want to keep up with news on the happenings at Digital Fusion we now have a way for you to keep up to date.

You will see we have added an email subscription to our blog section.

Add your email address and we will keep you in the loop when we post a new blog.

We generally add a new post once a month so we promise you will not be bombarded with too many emails, we hate spam as much as you.

FileMaker iOS SDK - Part 1

Mon, 11 Apr 2016 11:13:00 +1200

Building an iOS App from a FileMaker Database

As you may be aware FileMaker Inc have given developers a toolset ("SDK") for creating standalone apps for iPhone and iPad, from FileMaker databases. The process is a little tricky and there're plenty of things to be aware of...

But it's worth it!

The key thing is that once you've got a standalone app, it's much easier for users to have your database as an app just like any other app, as an icon sitting on the iPhone or iPad rather than buried away under FileMaker Go.

The other advantages are that it just looks and behaves like a standard native app. It opens quickly, with it's own splash screen and it's easier to install. In fact you can even sell (or give it away) through the App Store if you've built something that you want to distribute widely. More on deployment and distribution options later.

We've turned several existing iOS solutions we've built into standalone apps and based on that experience I've put together four articles that go through the technical "nuts and bolts" of the process. As this is all still very new I may not have everything perfect - let me know if I’ve missed anything and I will update the article/questions as we go.

Things to be aware of

Before you start it's worth keeping in mind that there are things that will not work as they do in FileMaker Go so you may want to make a few changes to the solution...

No Exit

The Exit Application script step in FileMaker Go usually takes us back the files interface. In our custom iOS App the files interface does not exist. The effect that the Exit Application script step has is that it will still close our current file (and any hidden but referenced files) and immediately try to re-open the main file. The user will automatically be logged back in if they've saved their password to the keychain or if the file is set to automatically log in with a specified account name and password, otherwise we are presented with the Log in dialog. Any OnFirstWindowOpen script triggers will run again once the login process has completed successfully.

App Version?

The Get ( ApplicationVersion ) function in FileMaker Go returns the string “Go_iPad 14.0.4”. When we run the Get ( ApplicationVersion ) function in our iOS App we were surprised to see it returned “Go_iPad 1.0.1”. 1.0.1 is a version number that is specified in the Version Number field in Xcode. This makes it difficult to determine if our Custom App is running in FileMaker Go or as our own iOS App. A simple work around is to use the Get ( ApplicationPath ) function and parse out the application name.

App Name

Using long application names will cause them to be truncated, for example the app name WindowFurnishing gets truncated to WindowFurni... iOS does not have a fixed maximum for the length of an app name, instead it will display as much of the name as it can. Using wide letters such as C, W, Z etc will reduce the available amount of space for our app name whereas using letters i, j, l etc will maximise the number of characters our app name can have. This limit differs depending on the device, an iPad allows for more visible width in an app name compared to an iPhone or iPod. A quick and easy way to see if an app name will fit completely on screen is to create an app folder and name it the same as our app.

App Updates

The FileMaker files within a custom app are not automatically updated when the app is updated. The files are either left untouched or they are overwritten with the solution files included with the iOS app. Ideally the app should update leaving the users data intact. This can be achieved by using an additional helper file that downloads the updated FileMaker files and transferring the user data from the old version to the new version.

Open URL

As we know the FileMaker Go app has a url scheme that can be used to open files, run scripts and set variables. We do this by creating a link with a prefix of fmp. Our native app can take advantage of the url scheme as well; however, we can not use fmp as our prefix. When we setup our project in Xcode we have the ability to specify a prefix of our own choosing.

Continue reading

Part 2 on how to setup Xcode and create a provisioning profile.

Part 3 on how to setup your project directory.

Part 4 on building, compiling and testing

Sending Email from FileMaker Using SparkPost

Sat, 19 Mar 2016 08:58:00 +1300

A bit of background

Back in 2014 we published this article about a new service at the time called Mandrill. Mandrill is an email web service that you can use to send thousands of emails per month. The great thing about Mandrill was that although it had paid subscription options, their free offering was perfect for most FileMaker solutions required to send email. Because email was sent through an API, it also avoids many common SMTP issues that developers come across when trying to setup emailing from FileMaker.

Recently however, Mandrill has announced that it is incorporating Mandrill into its Mailchimp service, and it will become a paid add-on to MailChimp accounts. This change will take effect from April 27th, 2016 and will affect all existing Mandrill users, and any FileMaker integrations that rely on it.

How does this affect me?

If you are not a Mandrill user, there is no effect, and you can read this post at your leisure. If you do use Mandrill in your FileMaker solution you have cause for taking some urgent action. Here is what is changing:

Mandrill users will be required to have a paid monthly MailChimp account

The separate service known as Mandrill will cease to be its own standalone service and will become incorporated into MailChimp by the end of April. To begin this process, MailChimp is requiring you sign up for an account if not already, and link your existing Mandrill account to it.

This in itself is not really a difficult task, sign up is very easy at mailchimp.com and linking your account is easy too. You have until 27th of April to do this. The following is from Mandrill:

The MailChimp team built Mandrill in 2012 as a transactional email tool. It was a startup within MailChimp that functioned as a completely separate product. Mandrill is now becoming an optional add-on to paid MailChimp accounts. This is a strategic change we’re making to close the gap between the two products. MailChimp is designed for marketing, and Mandrill is designed for transactional messages. Each is powerful on its own, and offering Mandrill as an add-on makes MailChimp even more powerful for our small business and e-commerce customers

The real gotcha with the change is that your MailChimp account will be required to be a paid monthly account by 27 April. Any free accounts will no longer be valid once your Mailchimp and Mandrill accounts are merged.

Pricing is set to change and is not yet finalised on the website. The blog article on the subject details that you will pay a single consolidated monthly fee for both Mailchimp and Mandrill, and Mandrill credits will be sold in blocks of 25,000 emails at $20 per month starting price.

Your sending domains will need to be verified

Mandrill allowed you to send emails from any sending domain. A sending domain is the domain name that comes after the @ part of your email address. This made setup easy but it did mean that the service could be abused by spammers and spoofed email addresses acting as senders.

MailChimp will require that all senders verify their domains. This is actually a good thing and not too difficult to do. Normally verifying your sending domain is done by adding a record into either your SPF or DKIM entries in your domain setup. Your domain provider will be able to assist and provide documentation on how you can do this.

One thing to note here that is important is that you'll need your own verified sending domain and you will be unable to use public domains such as Gmail, Hotmail or Yahoo. For users of free email services such as these it may mean you are out of luck.

SparkPost to the Rescue!

This is where SparkPost comes in. SparkPost is a new web service sending emails much like Mandrill, but SparkPost has a free email plan and is a great alternative for those who wish to not pay for Mandrill. SparkPost is recommended by Mandrill as the alternative for those who wish not to move to MailChimp, that's a good endorsement!

Better still, SparkPost offer a Mandrill Migration Guide which will help anyone with the transition.

SparkPost offers a free 100,00 emails a month plan (capped).

They have a great and fully complete API and excellent developer support.

A couple of Points about SparkPost

Sparkpost will require you to verify your sending domain using SPF/DKIM records, or verification through email. This is the same verification that Mandrill is enforcing, so Gmail/Hotmail/Yahoo users will be out of luck, but those with a legitimate sending domain will have no problem with this.

SparkPost can send emails of up to 20mb in size (with attachments) which should pose no issues for most people.

SparkPost also has a very in depth web based dashboard interface for tracking all mail sent, much like the Mandrill dashboard, and a number of features of Sparkpost are very similar to Mandrill.

Even JSON for formulating an API request is very similar to Mandrill so you should have no trouble with the transition.

Migrating to SparkPost

To give some information about the migration from Mandrill to SparkPost, we have used our old Mandrill example file as the basis, and have modified it to work with SparkPost. You can download the old file below.

The new file is also available here. Below we'll outline some of the important differences between the two that you'll need to be aware of when migrating.

Mandrill Demo

SparkPost Demo

Authentication Differences

When authenticating with Mandrill, your API key was passed as part of your JSON request posted to the API endpoint.

With SparkPost however you must first authenticate using your API key by way of setting a custom POST header prior to sending the JSON request. You also need to specify the content type of your request. SparkPost will use XML by default so you must specify whether your request is to be in JSON or XML.

To do this, we use the BaseElements plugin from Goya once again. This contains functions for setting your custom headers.

BE_HTTP_Set_Custom_Header ( "Authorization" ; <APIKEY> )

BE_HTTP_Set_Custom_Header ( "Content-Type" ; "application/json" )

Using these two functions, you can authenticate and specify JSON. These can be combined into a single "Let" statement when posting your request, they need not be specified in separate script steps, or as separate variables, just as long as they're defined prior to posting your request.

Request Differences

While the JSON formatting is very similar to Mandrill, SparkPost has slightly different naming for certain parts of the request such as recipients, but overall it is incredibly similar in how a request is formulated. The demo file contains an equivalent example to the Mandrill demo file, in that it is a template for sending an email to a single recipient with attachments and rich text.

The SparkPost API documentation is great and gives you all the information you'll need to customise the request to suit your needs. The key parts of the documentation around sending emails for you will be the "Transmissions" area and "Recipients" areas. The API can do all kinds of things such as manipulation of your settings, profile, recipient lists, webhooks etc, but a lot of that is not required for simply sending email.

Above is a basic template for sending a SparkPost request. There are only minor changes to that of a Mandrill request, mainly around the structuring of recipients into an array. The attachment code is basically the same.

Parsing the Result Returned

The format of the result returned by the API is different to that of Mandrill and so you will need to modify any functions you use to parse the response. SparkPost responses come in one of two varieties. The first is an error that will be returned along with an error code and message describing the error. You will normally see this if you have an improperly formed JSON request, or are missing vital information in your request.

If the JSON request is correct and an email is sent, you will receive a response that gives information about the number of recipients sent to successfully, or number that failed, along with the ID of the request.

An example of an error message:

{ "errors": [ { "message": "required field is missing", "description": "content object or template_id required", "code": "1400" } ] }

This is a JSON error object containing an array of errors. Each object within the array contains 3 attributes about the error. "Message" is the name of the error, and "Description" will give you more information about what the problem is. "Code" is an error code you can use to look up more information on the error in the API documentation. If you have multiple errors you will receive this in an array.

For a successful response, the format is:

{ "results": { "total_rejected_recipients": 0, "total_accepted_recipients": 1, "id": "84290312071045307" } }

This is a results object that contains the total number of rejected recipients, total number of accepted, and the SparkPost ID.

In our demo file we have included a very simplistic parsing function that will transform this into a return delimited list for easier FileMaker parsing. You can nominate which attribute to return, or passing an empty parameter to the function will return the full result. This is similar to the original parsing function in the Mandrill example file.

Rules around what is and is not Spam

If you find that your emails are not being delivered by SparkPost, it may be due to the rules around what SparkPost deems as suspicious or spam emails, and these may be different to Mandrill. SparkPost is quite strict around checking emails for potential spam. Subject lines, email content, recipients etc all contribute to whether the email will bounce or be delivered.

Originally, our demo file had a test email with the subject line "Hello There!". While this worked fine in Mandrill, SparkPost considered this email spam. We have had to change the subject line for this example file as a result. We recommend testing sending various emails after you switch to SparkPost to ensure they are successfully delivered, especially if you use preset templates.

Sending Email using the "Insert from URL" script step

In the Mandrill example file, reader and developer Michael Sloper found a means to send requests to Mandrill in a URL format which allows you to use the Insert from URL script step. this was great because it removed the need for a plugin.

We have been unable to find a suitable means to achieve this using SparkPost - to be fair we haven't really tried very hard! We welcome anyone who can find a suitable means to integrate with SparkPost using the Insert from URL script step!

In Conclusion

SparkPost is our preferred alternative to Mandrill because it offers the same free plans that Mandrill used to offer, and is very easy to switch to. Our Mandrill article was our most successful ever in terms of reader feedback, and we hope that this article prompts a similar level of discussion and sharing of ideas when it comes to SparkPost integration.

Good luck!

An important note on the API Key and Account used in the Demo file

Because SparkPost requires a valid sending domain for each account, the provided example file has been setup with a preset key on a demo SparkPost account we have created. This demo account has been verified to the sending domain "weetbicks.com" and we have setup a test email address "sparkpost@weetbicks.com" to act as the sender.

You may find that your emails will not send if you use the demo file with a different sender email address. If you wish to do this you should create your own SparkPost account, and obtain your own API key and verified sending domain to use in the example file.

Example File

We've included a Demo file to help you get started on your road to SparkPost integration. You can download using the link provided.

Click here to download the Sparkpost example file.

You can also check out our Mandrill example file for comparison below.

Click here to download the Mandrill example file.

Custom App Success Guide - Number two

Tue, 08 Mar 2016 10:08:00 +1300

Carrying on from Craig's post last month, FileMaker have now released their second guide in their Custom App Success series.

This one takes you through a step by step guide on how to develop your own custom app.

It makes for great reading with some awesome ideas particularly as it follows the 'plan guide'. We are big believers in spending a lot of time in planning, the changes of success are greatly enhanced if you put the effort in at the beginning.

This time FileMaker now require you register for the download, check it out here..

Custom App Success - Create

And as always, if you need a hand with either creating or planning your app, the team at Digital Fusion are always here for support.

The DIY Approach - Is it for you?

Wed, 24 Feb 2016 14:57:00 +1300

Firstly, FileMaker is a fantastic tool that allows you to develop your own apps and use them in your workplace/workspace. There are thousands and thousands of businesses throughout the world that run on ‘homemade’ apps, which is awesome because it goes to show the power of FileMaker.

There is also a plethora of help out there for you, including our own blog where we give tips and tricks to get your over any hurdles you might find as you progress through development. FileMaker themselves are bringing out ‘how to’ guides on the process of developing apps, starting with the very awesome ‘planning your app'

But sometimes the DIY approach doesn’t make sense.

And this is where I hark back to my previous life as an account manager at British Airways.

As you can imagine, working for British Airways, we were locked into the ‘beast’ of all systems when it came to IT (although I will say they were ahead of their game at the time)

Being an outpost in NZ we thought there must be a better way to do some things, starting with being able to report on clients based on a monthly basis.

We had the data but we just couldn’t pull it out of the system in a legible manner, nor display it in a way that made sense.

So off to Excel I went, building a fairly crude ‘database’ that allowed us do things ‘our way’.

This fairly simple database took me three solid days, with much frustration plus many interruptions of others to get their thoughts.

If I look back now, what I achieved in three days would have been knocked off pretty quickly by our developers in a matter of hours.

To look at this from a financial perspective, because at the end of the day tha'ts the thing to weight up between the DIY/Paid approaches…

Three days of my time = $2000
2-3 hours of developer time = $400-500

There's also the fact that a developer will have done a far better job, the interface will be so much nicer, the structure of the app would withstand further development in the future, and the stress levels of myself would have been greatly removed.

Case in point...

The point of this post is not to persuade you from giving the DIY approach a crack, by all means buy your FileMaker licenses, start developing and see how you get on.

All is not wasted if you then come to us to have us add-on or develop a new app, we can use your work as a proof of concept and a template for our development.

20 Years Already

Tue, 23 Feb 2016 00:20:00 +1300

Time Flies...

In February 1996 I took the plunge and left a perfectly good salaried job to go and ‘do my own thing’. To be honest it was pretty scary — I remember the day I told my boss I was leaving, then having to go round to a friend's place to have a few drinks to settle the nerves.

Well, there was no looking back and 20 years on I have to say it’s been a very exciting, very challenging, very rewarding… very silly idea.

So I figure we’ve still got a lot to achieve but at 20 years now it’s probably a good point to take a moment to reflect on what happened and how we got to where we are.

WTF Was I Thinking?

In 1995 I reckoned that the internet, and in particular the “World Wide Web”, looked like a fairly promising development that might become popular. So I set out to create a company that brought technology together - that melded Content (in those days, “multimedia”), Software, and People… thus was born the name “Digital Fusion” and our stylish logo:

The FileMaker Accident

While I set out to do web development, there actually wasn’t a huge demand for it at that moment, so when presented with an opportunity to create a business database in FileMaker I figured “Why not?” I had seen FileMaker a couple years earlier so I knew the basics, and as a programmer full of confidence, not knowing the language was no barrier whatsoever.

I took on that job and built a document management system in a couple of days. Deployed it, and to my astonishment the solution was pretty much bug free… Happy Client. This is good I thought.

I’d been programming in much more powerful languages and I’d never taken FileMaker seriously: but it had just become a proper relational database, and it was beautifully consistent cross platform – so I could develop on a Mac and deploy to the masses of Windows 95 heathen.

More importantly I had a bit of an epiphany: in FileMaker I suddenly had a platform that did less, but was better: faster to develop with, more robust and predictable… basically something you could count on and bet your business on.

So on Day One, I had set up as a web developer and on Day Two I added FileMaker Development to the menu. We’ve had a few sidelines along the way, but to this day that’s what we do…

This Is 1996

But before I go too far let me reflect for a moment on the state of play in 1996:

No broadband - internet was via dialup and clobbered your phone line
There was no iPhone, iPod or iPad
In fact there was no iMac even…
and Steve Jobs was some pillock who'd been tossed out of Apple long ago
There was no “Cloud” computing
No FaceBook or Instagram or Twitter
No TradeMe or eBay
No Google!

We did however have:

HTML v2.0 (with tables for positioning, oh joy)
Internet Explorer v2.0 - for both Mac and Windows!
FileMaker v3.0
Fax machines
Michael Jackson

You’ve Got To Have A Steve

For a start it was just me… I’ve always believed in a fair bit of reading to both help with self development and for inspiration. After studying the history of Apple and watching what happened when Steve Jobs came back to Apple, it became clear that you need to have a Steve onboard: in August 1998 I hired my first employee, Stephen Baker, fresh out of university after a career change from making showers to IT… and two weeks later I headed off for a holiday and left him in charge.

Steve, quietly spoken, resourceful and smart, held the fort with aplomb and was pivotal to those early days of growth. The first employee is essentially the doubling of your workforce, and as a startup with no capital to speak of, there isn’t time for a lot of training or any room for error. Steve’s a legend and a guru among clients and colleagues to this day; he’s even earned a certain reputation in the global FileMaker community…

(Credit to Richard Carlton Consulting)

Growing Up

From there we grew steadily with my wife Raewyn joining the fun (now we had no external income!) and other staff gradually adding to the mix. Paul and Cath joined in 2002, and Julie came on as an administrator in 2004 when I finally realised developers make useless organisers and hate doing important things like sending invoices for the hard work we’ve done. Again we landed on our feet with good keen people who stayed the distance through the highs and lows, and who picked up the pieces I couldn’t get right. Eh Julie?

I won’t bore you with the entire history of this little company but suffice to say over the years we’ve achieved some very fun things and built up some awesome friendships with the team (including the few who’ve managed to slip away from DF), the development community and with many of our clients—the loyalty of both clients and staff is pivotal for the long game and everyone benefits because we’re not having to pick up the pieces. The depth of those longer relationships and the knowledge is so very valuable. To you all a big Thank You!

Team DF, circa 2008:

Spinning Out

Perhaps the most disruptive thing we’ve done in this business is split it into two—kind of ironic for a business with “Fusion” in it’s name—but it’s been another challenging exciting change.

Basically we became known for our FileMaker prowess and it stands out as a point of distinction, yet we’d also built up an incredibly capable web development team that was proving much harder to showcase and find recognition for. So… I decided that it was at a point where it needed to be a separate company, something far more than the web development arm of a FileMaker consultancy.

This would enable the team on that side of the business to become a powerful web app design and development company in their own right, helping businesses transform the way they work through online tools and services, realizing the full opportunity of the web where form AND function changes the way we do business. Enter Custom D.

Onward and Upward

So what now? Well… onward and upward. I’ve got high hopes for the web team at Custom D — it’s a challenging market to differentiate ourselves in but the opportunities are huge and as was the case in 1996 it’s where the most disruption and change is coming from, albeit on a totally different level now.

Meanwhile at Digital Fusion the focus on FileMaker now gives us an unprecedented sense of purity and purpose. And with FileMaker Inc doing a most excellent job of evolving the product from “desktop database” to a powerful “Business App Development Platform”, the opportunities to help more businesses operate more effectively have expanded hugely. It still astounds me 20 years on, just how many businesses run on spreadsheets and paper with a fair bit of smoke and a few mirrors to make it all “work”!

Anyway… I’ll update you on progress in another 20 years. At that point I fully expect we will have:

Autonomous, electric cars (combustion engines are obsolete)
Hyperloops
Prototype Fusion Reactors
Home automation: robots, smart everything from your fridge to your lights
Screens on walls. Anywhere and everywhere.
Lightsabers
FileMaker v35 will be nearing release with AI to do the development for you
The Web will now be the "vWeb", a virtual reality where we can live our entire lives without fear of sunburn

and of course:

Retirement will have moved out to 85

See ya there.

Custom App Success Guide - Available Free

Wed, 10 Feb 2016 23:57:00 +1300

Thinking of building your own database app?

Or wanting to know more about the process, especially what sort of things should be tackled in the design and planning stage?

FileMaker Inc have published a very well put together "How to" guide. In fact this is the first in a 3 part series and is available now free from the FileMaker web site.

FileMaker, AppMaker

Fri, 29 Jan 2016 01:40:00 +1300

This Is Cool.

Earlier this month FileMaker Inc released a toolset to allow us to turn databases built for FileMaker Go into standard “apps” for iPhone and iPad.

That is to say we can now turn a database into a standalone app which, just like any other app, can be downloaded and installed in one step. No FileMaker Go app needed.

So What?

Well, what does this mean for you, in your business?

If you’ve got an FileMaker Go solution, or considering having one built, we can turn it into one of these apps with a fairly modest amount of work so that you can set up new devices by simply installing a single application. No more needing to install FileMaker Go, then the database; no more creating an icon shortcut that jumps through Safari before opening your solution. Basically:

Simplified installation and setup
Proper identity with your own app icon, lock screen
Launching apps is fast and clean

There’re a few subtleties too like, the fact users can’t close the database and end up back at some dashboard of database templates that come with the standard FileMaker Go install. And if you’ve been using a special launcher icon, you might have noticed that iOS puts a link back to Safari in the top left of the screen – that can be confusing and users sometimes hit that by mistake and end up leaving the app.

All round it’s just a big improvement in usability and deployment.

App Store?

But there’s something else this also means, and the implications could be huge…

You can now create an app using FileMaker that can potentially be sold through the Apple App Store.

Granted, you’re going have to ensure it meets Apple’s strict guidelines for usability, design, content and so on. And it’ll need to work out of the box, whether or not the buyer has a FileMaker Server, at least to some degree. And turning something you’ve built or had built for your own use into a standardised solution takes a lot more work.

But this opens the door for FileMaker apps to be distributed and used much more widely. And yet users may not even know they’re using something built with FileMaker—which is as it should be, after all, you don’t know what platform or programming language your current apps are written in do you?

So with this SDK (Software Development Kit) there’s now an opportunity to productize FileMaker based solutions as apps like never before. And while I don’t think we should just jump in and try and produce every solution, there may be some nice opportunities.

The Thing I Love Most…

The very fact that FileMaker Inc have put this out reinforces the recognition that FileMaker is a software development tool — no, sorry that’s old school, I mean, “app development” tool and not just a “desktop database”.

And I think the best term for it in our industry speak is, “Platform” - a platform for development, a platform for business solutions, a platform for innovation. It’s powerful, robust, flexible and offers true rapid development unlike anything else.

iPad Pro and FileMaker Go - A Marriage Made in Heaven

Sun, 03 Jan 2016 14:39:00 +1300

A few weeks back Apple announced the iPad Pro and Apple Pencil which is both big in size but also processing power. At the point at writing, we are still a few weeks away from seeing these in in-store.

This got us to thinking what will the ‘use cases’ be for our clients in terms of both developing for and using the Pro version of iPad.

For a number the iPad mini is perfect but this mostly relates to the form factor, size really does matter when you are climbing up on people roofs or working in a panel shop.

So conversely what will the additional real estate of the Pro offer clients and these are the four areas we have identified:

1. Complex apps where you’re working with a lot of data - A number of our clients are required to entered and collate a large amount of data, think measuring a six bedroom house for all window coverings (curtains, blinds, curtain rods etc). Each room has to have exact measurements taken and stored. Having the larger screen will mean things are more tactile and the smaller details are not missed.

2. In house displays - One of our clients has iPads running FileMaker Go on the ‘shop floor’. Once again, with the larger display the visibility of items not the screen will be greatly enhanced. There’s also the option of having a split screen, so both Go and another app are visible at the same time.

3. Apple Pen use - Where being able to draw or annotate is important or adds a lot of value. Think medical solutions where there’s an x-ray or body diagram that’s annotated or photos of damage or work to be be done where you can draw over the photo.

4. Smart Cover with Apple Keyboard - Apple are to produce a cover and keyboard that will essentially make the iPad into a tablet come laptop. It will give the user the best of both worlds and we can see that this will have some interesting areas for use with FileMaker. At the moment a number of clients have both a FileMaker Go and FileMaker Pro solution, potentially (and we say potentially, it will be interesting to explore) a solution can just be built in FileMaker Go.

We are always amazed by what clients want and need iPads to do. With the addition of the Pro this will only advance the opportunities for us to develop, and our clients to use FileMaker Go on the iPads.

iPad Pro and FileMaker Go - A Marriage Made in Heaven?

Fri, 06 Nov 2015 00:00:00 +1300

A few weeks back Apple announced the iPad Pro and Apple Pencil which is both big in size but also processing power. At the point of this writing, we're still a few weeks away from seeing these in in-store.

This got us to thinking what will the ‘use cases’ be for our clients in terms of both developing for and using the Pro version of iPad.

For a number the iPad mini is perfect but this mostly relates to the form factor, size really does matter when you are climbing up on people roofs or working in a panel shop.

So conversely what will the additional real estate of the Pro offer clients and these are the four areas we have identified:

2. In house displays - One of our clients has iPads running FileMaker Go on the ‘shop floor’. Once again, with the larger display the visibility of items not the screen will be greatly enhanced. There's also the option of having a split screen, so both Go and another app are visible at the same time.

14 for 14: Reconnect with your Databases

Wed, 15 Jul 2015 00:00:00 +1200

Introductions first...

This is the first article written for Weetbicks by Craig Saunders - our Director and master chief (be nice in the comments section, he pays my wages! - Daniel)

Let's Stick Together

New in FileMaker 14 is the automatic “reconnect to server” feature which I particularly love.

Basically FileMaker reconnects you automatically if you’ve lost your connection to the server, such as when you close your laptop then open it up again some time or place later... With ‘reconnect’ FMP will carry on where you left off without the need to log in all over again.

FileMaker Go has always had this great feature but as of FM14 it’s now in the desktop products too, i.e. FileMaker Pro 14 and FileMaker Pro Advanced 14. And it works with Server 13 or 14 so it’s an instant win even if you’re still running a 13 server.

Reconnect might not sound like a major feature but it makes huge difference to performance over the internet and the resulting end user experience. Let me explain...

FileMaker is a Distributed Database

When you first connect to a solution the FileMaker Pro client downloads a large deal of information about the solution including the database schema (tables, fields and relationship graph) and layout and record information for the layout you first land on. Then as you browse records the data itself is also downloaded and ‘cached’ locally. Scripts, value lists, indexes and of course the layout information are also cached as you use the system.

You see this quite dramatically when you run a report: the first time, a moderate report might take a minute or two to run. Run it again and it can be almost instant, such is the magic of caching.

When you log out or disconnect, all that hard earned cache data is deleted—it’s a “temporary” working copy after all, right? But what if you could keep it...?

Essentially reconnect does just that–allows you to keep the cache. In other words if you don’t close the database at the end of day or when you unplug, then FileMaker keeps the cache and can carry on at a later time — i.e. when you have an internet connection again.

FileMaker’s distributed database technology handles the changes to... it could be a week or a month later when you reconnect, and FileMaker always knows which records, layouts etc, have changed and will update your cache as need be when you reconnect.

Bad Behaviour

In practice it’s not entirely “graceful” how this happens but it works fairly well and with a trick or two and some education for users it works like magic.

Here’s what happens: When the connection is lost FileMaker will try to alert the user—on a Mac, the dock icon bounces a couple of times and this horrific message will confront you:

(I can see why the good folks at FMI felt the need to explain what’s going on here but that is a lot of information for a user to wrap their head around. It’d be a lot better if the message was worded according to the user privileges—if you don’t have access to Layout editing etc then that detail isn’t needed so it could be kept very simple.)

Anyway the correct answer is “Reconnect” which basically means “Yeah, carry on, as you were.”

Actually if you just leave it alone the dialog will go away and it’ll reconnect by itself if it can or just keep trying quietly in the background ad nauseam.

In fact if you hit “Reconnect” and it can’t reconnect, the files will close giving you no further choice in the matter. Whereas, say you’re on a plane (with no internet), if you just leave FileMaker alone it will:

display the wordy dialog
try to connect and fail
dismiss the dialog
connect when you get the connection back

So the moral of the story is that you’re better just to wait and see what happens!

Too bad FM had to bother the user with the dialog in the first place—to my mind that should only be necessary if the user tries to actually use the database before reconnection is sorted. And perhaps it should just say “This database can’t be used until you’re connected to the internet again.”

Ideally the database should be “paused”, dimmed out or something, allowing you to use FileMaker for other things like working on any local databases.

In fact the ultimate answer is that FileMaker should never throw out the cache (unless specifically ‘asked’ to) so that even if you do close the database, when you re-open the same database the cache should be able to be used again. With the cache encrypted and inaccessible there’s no harm in keeping it around. Go lobby for this feature if you agree... :-)

Another Catch

The reconnect works great with a single file solution, however there’s a problem when you have multiple files or interface / data separation (e.g. where the initial interface or main file is the one you log in to, then other files are opened using the same credentials in the background).

The problem is that during reconnect those credentials are not passed on to the background files in certain circumstances and the user will be bothered by an authentication dialog:

Have I mentioned that I despise dialog boxes? A dialog is a slap in the face for the user, so general tip: Don’t Do Modal Dialogs!

Anyway there’s another great feature missing here which is the ability to store the credentials in the keychain. Compare the above dialog with the standard authentication dialog when opening a solution:

See the difference – there’s an option to store their user name and password in the keychain so that provided the user is logged in on the device, the solution will open and authenticate completely automatically.

I first noticed this with Go where the ability to store the user name and password creds in the keychain is a real boon (though it begs the question, what sort of security practices should we have around this?)

Certain Circumstances

During the writing of this article I figured out that this authentication issue doesn’t always happen in multi file solutions - only in “certain circumstances”...

In the end I nailed it down to the fmreauthenticate extended privilege, which exists for the purpose of dictating how long FileMaker Go can be switched out before requiring the user to re-authenticate.

Turns out in 14 fmreauthenticate also affects FMPro but not quite as you’d expect: it doesn’t dictate how long before you have to re-authenticate, rather it will force re-authentication if it’s not the same in all files. In other words:

All files in a multi-file solution must have the same fmreauthenticate privilege for any given privilege set.

However it doesn’t matter what value it actually has, so it could be fmreauthenticate0 or fmreauthenticate10 or whatever.

Go behaves a bit more as you’d expect—i.e. if you set a big fmreauthenticate number (which is the number of minutes since the app was used before requiring re-authentication, then users won’t need to re-authenticate provided they come back within that period.

The maximum number for fmreauthenticate is 10080, i.e. fmreauthenticate10080 which is 7 days. So anyone returning to the app after more than 7 days would have to manually enter their user name and password again.

Still Not Entirely Happy

So that’s the easy solution.

However I’m still not entirely happy: given that FileMaker has given users the means to store their credentials in the keychain for automatic log in, any file that is thus opened (whether directly or indirectly) should never ask for the user name and password even if it is a week or a more later since it was last used, and indeed the main file won’t but any background files will.

One option is to not allow the creds to be stored in the keychain for your solution. You can do that in the File Options settings:

Still not happy though—there are legitimate cases for allowing this so why disable it? A better answer seems to be that we’d need to provide an easy means for the user to store the user name and password for the other files in their keychain. This is going to be a slightly annoying step to have to do but it’s one-off and workable as long as there aren’t many other files (e.g. separation model solutions typically have only 2 or 3 files).

I haven’t worked out the best way to tackle that type of solution, but you basically you’d want to make automate the process so that users could elect to “Store Authentication Details”, and then be prompted for each of the files. To do that they have to be opened directly (as opposed to indirectly from a main file that has access to them).

I can think of 2 possible solutions for having this function built into the front end or main file:

At start up before any of the secondary files are referenced, use Open URL to directly open the secondary databases. You can’t use the standard Open File command because the file you’re on has the same credentials and an external reference to that file so passes on the credentials automatically.
Create a standalone “Authenticator” file which has no credentials in it: you can then use the standard Open File command and will get the full authentication dialog with “Store in Keychain” option. There’re a number of ways of instigating the process but the key thing is that the actual solution files must be closed for the Authentication process to work.

One More Thing

For all of this to work we need to encourage (or prevent even) users from closing the solution: there are a number of ways of doing that:

Tell them not to: e.g. “A kitten dies if you close this database.”
Or you could just use the window controls to give the user a window with the close control disabled:

Daniel suggests a variant on this which provides for "a per user approach" by putting twink or tape on the individuals screen where the close control appears.

Either way this approach could be a confusing and frustrating—you’re taking away an expected behaviour so another alternative would be:

Intercept the script trigger for “Last Window Close” and do something like this which lets the user decide whether to actually close or just hide the solution

Mind you I did say that dialogs are evil, so you could just Hide the solution by default and give users a more explicit “Close Solution” button or control within the solution itself: if your users are the kind who hit the close box just get the solution out of the way then this is the probably the best answer.

(I tried the dialog approach on one of our own databases and found that it works really well especially with Hibernate as the default in the dialog so 9 times out of 10 you just hit return to accept that action.)

Official Information

Finally, here’s what FileMaker have to say about this feature:

http://help.filemaker.com/app/answers/detail/a_id/14232

(Note that although the automatic reconnect attempt gets longer, it will attempt to reconnect instantly if the user “opens” the database again or clicks onto it at all.)

All Good then?

I know this all sounds fiddly and is a distraction from your main focus of building features and functionality into your solutions, but if the solution is being used over the internet then get this process sorted your users will love it.

14 for 14: Developer Assistant v3.0 Review

Mon, 06 Jul 2015 00:00:00 +1200

Introduction

Developer Assistant is an application produced by Chris Dragon and his company Dracoventions. It has been around for a couple of years, and version 3.0 has recently been released. This is the version we will be reviewing.

The Developer Assistant application is bundled with a nice easy to use installer and essentially is a plugin. You can choose to install it for just yourself or for all users, across all versions of the FileMaker platform (7v3 to 14).

As of writing this review, it is not currently available for Windows platform given a recent change from win32 to .net - but a windows version is expected soon and you can download beta versions as they come out.

So what is Developer Assistant?

The name is a good start! This tool is for developers first and foremost. It is a tool for searching your schema: fields, scripts, functions, relationship graph and so on. In addition to this it also contains a couple of other very cool developer-centric features which we'll cover. In essence this that missing allen key in any developers toolbox.

So why would you want to search these areas? Perhaps this is best illustrated with a demonstration.

Fixing Broken References

Imagine a solution with hundreds of scripts. In these scripts are numerous broken field references that need fixing. In FileMaker, a broken field reference generally contains the string <field missing> if any script step references a missing field.

So how can we find all of these? There are a few ways to this point that developers have done:

Print all scripts to PDF and search the PDF
Run your solution through BaseElements and look for missing references
Manually go through every script - only for the patient!

Developer Assistant gives you a really quick way to not only find missing references, but to work your way through them fixing each.

This is done by first opening the script workspace. Developer Assistant searches in whatever your current context is - be it the script workspace, field definitions dialog, an individual calculation, or a specific script.

Here in the Developer Assistant window we can type in our search string. We have a few options here. First we can choose to just find references to the search value, or replace (more on this later). We can choose to step through results one at a time using the next/prev buttons, or we can just choose to 'Find All' to list every script step where this search string is found. This is the option we are going to run now.

This is what you get after finding all. The search process can take a little time depending on how many scripts you have. This is because it will iterate through each script, opening it in the script workspace and searching, before moving onto the next (currently you cannot have it search a specific subset of scripts)

Each result is a single script step found where its contents matches the search string. As you can see we have quite a lot! The beauty of this now is that you can double-click on any result to take you directly to that script, and that script step so you can fix. You don't need to locate the scripts yourself, Developer Assistant does all this for you.

In fact, when it comes to missing references, Developer Assistant has thought of it and given you an option to do this:

By clicking the search icon you are given a number of useful options. You have some powerful search options when it comes to how you conduct your search query. The most powerful of these being the ability to use regular expressions. The 'Find Missing References' is a shortcut way to achieve what we did in our example. You also have a history of previous searches.

Consider the possibilities:

Finding missing fields
Finding all instances of something such as the database name, if you wish to replace
Find everywhere a global variable is used

This is so great! Because it is happening right away, you can very quickly address issues in your solution without producing a DDR or PDF of your schema.

Not Just Scripts..

As we mentioned earlier, Developer Assistant can effectively search most schema dialog boxes for a given piece of text, examples include:

Scripts (all or selected)
Fields (all in selected table or specific field)
Calculations
Value Lists (names and values)
Custom Functions (names and parameters)
The relationship graph (table occurrence names)

This last one gets us particularly excited!

Relationship Graph Searching

Previous versions of the Developer Assistant have allowed you to search the graph but this was somewhat limited. It relied on you entering the entire TO name if you wanted to go direct to a table occurrence, otherwise it worked much like the normal search on the graph where you have to cycle through matches.

With Developer Assistant 3.0 introducing a list of search results, we can essentially produce a list of all of our table occurrences for easy selection of any TO on the graph - perfect for large relationship graphs or legacy solutions where you are tasked with untangling a spiders web!

Above is a search on one of our solutions relationship graphs. Because we use a naming convention where every table occurrence contains an underscore, by simply searching for an underscore we produce a list of every table occurrence on the graph.

Double clicking on a result takes you directly to that occurrence on the graph with no visible cycling through results, it is brilliant! You can then rename the TO or do whatever you want. When it comes to tidying up graphs or managing large graphs this is an invaluable tool. If you use an anchor-buoy structure then with consistently named anchors you can turn the results into a list of your anchors for easy access to table occurrence groups.

Replacing Text - Ultimate Power!

Version 3.0 of Developer Assistant has introduced a powerful replace function to complement the find function. This function is available in the Advanced version of Developer Assistant only, but is well worth the cost of the upgrade!

Effectively you can update any piece of text in the schema area you are searching. Scripts is the obvious candidate. Imagine you are tidying a solution and wanting to rename some variables. You can use this to find all occurrences of a global variable and change its name to something else.

Here in this example we are looking for 'Daniel Wood' and replacing it with the text 'Weetbicks'. We are just searching one script and the name has been found as part of a comment line. Just hit the replace button to update the text, it's that simple!

Evaluate - the hidden gem!

The core of Developer Assistant is searching your schema and having easy access to the results for editing or replacing. A hidden gem in Developer Assistant however is this little button in the lower left corner:

Welcome to your in-line, evaluate-anywhere data viewer! This little beauty allows you to evaluate any selected calculation no matter where you are in your solution. Imagine you are editing a complex calculation in a field definition. If you want to test it to make sure it is working you can always copy it, save changes, and paste it into the data viewer. Doing this generally means you have to adjust some field references so it works in the data viewer, not to mention you have to save all your schema changes before testing.

Not anymore!

Using the Evaluate button you can instantly evaluate your calculation without ever leaving your calculation dialog!

This little feature alone will save you enough time over a while to justify getting Developer Assistant! You can use this in any calculation dialog, so custom functions, scripts, field definitions etc. You'll quickly find that the data viewer plays second fiddle to this little tool.

Plus Much more!

Developer Assistant does more than what we've covered in this review. Windows users get a few other nice features such as the ability to move multiple selected fields with a click of a single button.

All features of Developer Assistant 3.0 are listed on the Dracoventions site here.

The bottom line, how much does it cost?

Developer Assistant 3.0 will cost you $195 USD for a single license ($395 USD for advanced). They also offer 5 and 10 license plans where you can save up to 60% per user if buying in bulk. Finally they offer an unlimited license for $1,995 USD which would be perfect for large development companies.

In Conclusion

We think the price is fully justified by the product and what it can offer. For developers time is money, and if you can save 30 minutes here and there by using Developer Assistant as opposed to alternate methods then the product will pay for itself in no time. The Evaluate function alone is worth the price of admission! We highly recommend this product. We use it ourselves and has become a valuable tool here at Digital Fusion.

You can download a free 30 day trial from the Dracoventions website - try it out and you'll be hooked!

14 for 14: Ditch those Cartesian Joins, Use Refresh Portal Instead (maybe!)

Mon, 29 Jun 2015 00:00:00 +1200

A bit of background

Back when we first started writing this blog one of our first articles was around portal refreshing and how sometimes complex relationships simply couldn't be refreshed without a forced flush cache as part of the refresh window script step. Normally these complex relationships were based on unstored calculations, related data, or the relationship in question was more than one relationship away from the base table occurrence.

We wrote an article on a technique you could employ to bypass the need to flush the cache and merely "flush the relationship" instead. The end result was refreshed relationships without the need to flush away all record data that had been sent from server to client during the session.

You can read the original article here

The technique is still solid and we have used it all these years for certain relationships that just won't refresh nicely.

How FileMaker 14 changes the game

FileMaker 14 has changed the game by introducing the "Refresh Portal" script step to address this issue. The script step is very simple and looks as follows:

Refresh Portal [ Object Name: "ObjectName" ]

It's very simple and just requires the object name of the portal to be refreshed. This forces the update of displayed records in the named portal, effectively refreshing the relationship

*Disclaimer!

We put a big fat "maybe" at the end of the article title because we don't necessarily recommend you switch (that was just trying to keep the same article name format as our earlier article on the subject!) Whether you switch to this technique or not depends on a number of factors which we'll outline below.

Benefits of switching from Cartesian to Refresh Portal

So the question is why would you want to switch to this if your cartesian join relationships have been working fine? Well, the answer is subjective. For some, there is no benefit, and for others there will.

First benefit would be removing "hacks" from your solution. We still consider the cartesian join technique a hack and it may no longer be supported in future versions whereas Refresh Portal will.

Secondly is that relationships that use a cartesian join cannot have records created via them. If you have a portal where you want to achieve this, then you may be better off using the Refresh Portal step if records don't correctly refresh.

Lastly, you remove the need for a field in your database to act as the portal refresh (however you gain a script step!)

Benefits of staying with Cartesian Join

It's the old saying - if it ain't broke, don't fix it. If there is no visible benefit in removing cartesian joins to refresh a relationship then why bother. Both methods appear to work exactly the same - the Refresh Portal script step doesn't do anything significantly different to a cartesian join refresh that we can see.

Another big benefit of a cartesian join refresh is that it can be triggered without a script. Because the refresh occurs when the value of the field used in the cartesian join is changed, this can be triggered using an auto-enter calculation on the cartesian join field that refreshes when any referenced field changes - no need for a script trigger.

In a lot of cases this is quite elegant and better than relying on script triggers

There is also another big benefit of keeping with Cartesian Joins. The Refresh Portal script step requires an actual portal on your layout to refresh! Cartesian Join refresh operates at the relationship level, whereas the Refresh Portal step acts at the portal level (but still technically is refreshing the relationship). If you are using cartesian join purely to update a relationship and not a visual portal, then you would need to add this portal to your layout. Fortunately it can be added on the right edge of your layout so is not visible to the user, but you still need it there for this to work.

In Conclusion

If you are using cartesian joins to refresh your relationships and portals and it works fine, we don't think there is any reason to change. If you are concerned about it working in future, it may be best to switch now to the Refresh Portal step. Either way you now have 2 great options!

Example File

We've built a new example file that shows both the Cartesian Join refresh technique from our earlier demo, and now the Refresh Portal script step technique also. You can compare both for yourself and see what will work best for you.

Click here to download the example file.

14 for 14: Setting up cool looking buttons just got easier

Thu, 18 Jun 2015 00:00:00 +1200

Buttons that just keep getting cooler

Buttons in FileMaker 14 are cool! So cool in fact that they got their own bar (more on that in a later article). For now we'll focus on just the button object, what is new, what's the same, and what you can do to take them even further.

The new button user interface

The first thing you may notice is the button setup has dramatically changed from FileMaker 13. Gone is the modal popup dialog and procedural setup. In its place is a more stylish looking non-modal popup where you can determine specifically what aspect of the button you want to setup.

The button setup comprises of four main sections...

Button type

You can define whether the button has just a label, icon, or both. You can also define the position of the icon relative to the label. Icon options are only displayed if your button type includes an icon.

FileMaker has 140 built in icons. These icons cannot be removed or modified. You can use the slider to scale the icons in size. This is possible because button icons are scalable vector graphics (SVG) format.

When you insert your own icons you can choose to insert either png or SVG format icons. PNG format icons can be scaled (though not as well as SVG, it's just a basic resize) whereas SVG icons can not only be nicely scaled, you can make use of styling and have full control over the icons colour in a range of different states, including conditional formatting.

Also when inserting icons you can choose to insert as many icons as you want in a single operation. Icons are stored with the file. Note also that icons cannot be added to a file while that file is hosted, it must be local for icons to be able to be saved with a file for future use.

We recommend you check out http://www.flaticon.com for a huge selection of great free SVG icons you can add to your solutions.

Currently custom icons added appear in a darker grey colour which is not actually a bad thing as it allows you to distinguish between what is a custom icon and what is a native icon.

There is also another quite cool way to automatically add custom icons to your solution. If you paste any button into your solution which itself contains a custom icon not already stored with your solution, then upon pasting that icon will be added to your icon list. With this technique you can create your own icon sets by creating button bars with sets of icons associated. Simply paste them into any solution you wish to add the icons to (more on button bars later!)

Button text.

While not definable by calculation (probably for backwards compatibility) it is now so much easier to change a buttons text when a script is attached.

Prior to FileMaker 14 you would have to select the text tool before clicking a scripted button otherwise you would launch the button setup dialog. Now just double click the button and edit the text right away - no need for text tool selection. However you can still use the text tool to directly edit a buttons label if you wish to bypass the button setup popup.

While calculations are not supported, merge field and merge variables are still supported.

Button Action

Action allows you to choose one of three options: Do nothing, single step, or script While these three options are the same as FileMaker 13, the method in which you use them is different.

For a single step you use the script workspace engine to define the step, rather than selecting a single step from a list. This allows you to make use of auto-complete in scripts or show a list of steps.

The real cool feature is being able to change your single step into a script. Often buttons are defined but you realise you need a second step, or need to flesh it out a bit into a script. You can now do this direct from button setup by clicking the "Convert to Script" button:

When you do this you are prompted to enter the script name. Upon clicking OK the dialog will change to that of an actual script, and the new script is placed in a created folder called "Scripts for Buttons"

Button Options

At this stage the only button options are to show a hand cursor over a button. It seems a little odd for there to be only one option under options, and even more odd you have to expand this area by default in order to set the option - but maybe they are anticipating more options in future who knows!

Example File

To supplement this article we have provided a demo file in which you can see how buttons can be setup, and how custom SVG icons can be added and used in a solution. The demo file includes over 400 custom icons already added to button setup to demonstrate. All custom icons are from the freeicons.com website, and we have included a sample set with the file.

Click here to download the demo file.

Further Resources

SVG Helper Tool from Richard Carlton Consulting

Icon Manager FileMaker database from Indats (recommended!)

FileMaker Pro 14 SVG Grammar Guidelines

14 for 14: What is a Navigation Part?

Fri, 12 Jun 2015 00:00:00 +1200

Why add a new part now... and for navigation?

Good question, to answer that we first need to understand the properties of the navigation layout part and once those are clear the reasons for having it become quite obvious.

The setup of a layout part couldn't be easier, in fact there are no additional options for a part, it's either top or bottom navigation.

We have identified 4 key features of the navigation part that make it a really great UI enhancement for your solutions.

Navigation Parts remain fixed to the top/bottom of screen

This is the most important aspect of a navigation part, and what makes it truly feel like navigation (if used for that purpose).

Take a look at the above picture of a layout. Notice anything? There is something about this layout that was never before possible. I'll give you a second......... got it? Yes? No?

There are a few clues here:

The layout is in form view
The layout is in browse mode
The layout is scrolled
yet the header and footer remain visible

Well, the last point basically answered it. When in form view (or any view for that matter) navigation parts remain fixed to the top and bottom of the screen. Headers and Footers on the other hand do not remain fixed. They remain fixed in list and table views but scroll in form view.

So why does this matter? Well, it opens the doors for us to build sweet layouts that are scrollable, whilst not losing our top/bottom navigation. FileMaker developers have always been sticklers for putting everything on screen and avoiding scrolling anything that isn't a list layout.

This is quite a paradigm shift, but it draws parallels with websites. Most websites are scrollable and retain their navigation at the top visible to the user. Data-entry forms online also benefit from scrolling by allowing you to build long single data entry forms instead of relying on tabs or multiple screens. This is all now really easy in FileMaker 14. With the rise of FileMaker WebDirect this will be more important than ever as users will be expecting an experience similar to their normal web experience.

Last note on this - if you wish to use top/bottom navigation parts in table view, make sure you mark them as visible via the table view setup:

Navigation Parts do not zoom

Look at the below picture:

That is 10pt text with the layout zoomed to 400%. The navigation part however remains unchanged. Indeed both the top and bottom navigation parts are will not zoom with the layout zoom.

On some level we can understand why this is the case - it's for navigation not actual data so is there any real reason to zoom it? We think not but we can understand if people are a bit confused by this one. Hopefully FileMaker will give us an official reason ;)

Navigation Parts do not print

Now this feature makes perfect sense! The part is to be used for navigation, not printing - nuff said! If you use it for its intended purpose, and place inside it navigation such as links or a button bar then why on earth would you want to print that? You should use a header and footer for printing!

The beauty of this is it allows you to build a layout that might also print quite nicely such as a list view. You can easily print it without all the UI navigation stuff.

(Perhaps) unfortunately you cannot have both a top navigation and a header on your layout and choose to use the header for preview mode, and navigation part for browse mode - you must choose one or the other so if you want a proper printed list with header and footer you will still need another layout.

Navigation Parts have nice animation effects and are stylable

This last one is not functionally necessary but so damn cool (and fun) we included it. Navigation parts have a nice animation effect associated with them when using a trackpad or iPad device and are scrolling a layout. When you scroll to the top or bottom, the navigation part header/footer "bounces". It's a little difficult to illustrate but you will have seen this effect on iOS for a couple of years now. You can scroll past the top of the layout essentially.

While we have not yet figured out how to alter the underlying fill colour you see (we'd love to know how) it is a nice little animation that ties it in nicely with the feel of iOS.

Navigation parts can also be styled in the same way as headers and footers. You can define a background fill for the navigation part system-wide by turning it into a style of the theme you use.

Example File

To go along with this article we've done a sweet demo file you can download below. This shows you the setup of a navigation part and an example of a scrollable form-view layout that uses navigation parts so you can get a feel for the usage and benefit. Note because this uses a FileMaker 14 feature it obviously will only work nicely in 14, but you can try opening in 13 at your own risk :)

Click here to download the demo file.

Update!

Reader LaRetta pointed out that the colour you see when doing the "bounce" effect for the navigation parts is actually the layout background, of course! You can change this by clicking off the edge of the layout to set the inspector to layout background and then alter the colour from there, thanks LaRetta for the tip! LaRetta also kindly attached a modified example file to illustrate this which you can download below.

Click here to download the modified demo file.

Integrating FileMaker with Xero

Wed, 10 Jun 2015 00:00:00 +1200

Xero remains the number one piece of software our clients want their FileMaker solution integrated with.

This has been the case for nearly five years now, but what we are finding is that clients are keen to integrate FileMaker and Xero in different ways, and for different business reasons.

Traditionally the request was to ‘push’ all invoicing (including invoice contact details) from a FileMaker solution through to Xero.

Now clients are wanting more than just the invoice contact details pushed through, and they are keen for the information to flow both ways, from FileMaker to Xero and back again.

To follow are some of the requests and work we have performed by using the Digital Fusion Xero plugin. We have also listed the business case as to why this is important:

Push of invoice and contact details from FileMaker to Xero

As mentioned above, this is the most requested form of integration. Depending on how well your FileMaker solution is developed we can get this working reasonably quickly, but sometimes it does take additional work to make sure FileMaker is setup correctly.

Business use: Integrating FileMaker with Xero in this way allows for a seamless experience for your staff. They are able to raise invoices in FileMaker and all this information then flows through to your accounting package, in this case Xero. The integration works behind the scenes so once an invoice is finalised there is nothing more that is needed to be done.

Information moving both ways

This is becoming a more sought after requirement for integrations we perform. As above, invoice and contact information is pushed from FileMaker to Xero but in this case account updates are pulled back from Xero into FileMaker. This one has a few more things to take into consideration, the main one being how often the information needs to come back from Xero into FileMaker. Xero has a limit on the number of daily ‘calls’ that can be made to and from their software, so we can’t have an endless pull of information back from Xero to FileMaker (although we have some cunning ways to get around this)

Business use: The big gain with a two way flow is that this allows all your staff to see how a client account is looking without having to give them access to Xero itself. Now sales staff can see if a client has their account up to to date, or they can now be the ‘prompter’ when discussing outstanding accounts with clients. Although Xero now offer ‘limited access’ to the software, having all this information in FileMaker makes for a seamless experience, with all client information contained within one solution.

Push all contacts through to Xero

Typically we have only pushed contact information through to Xero when an invoice is raised. Xero then looks to see if the client already exists and if not, it adds it as a new client.

Recently we have been asked to integrate all contacts that are in FileMaker with Xero. This can include contacts such as supplier, staff etc, essentially any contact that you believe will need a reference in Xero.

Business use: The big gains here are around reducing double handing, you know longer need to key in details in both solutions, increasing the overall accuracy of data.

As you can tell from the above, there are a number of options to consider when integrating FileMaker with Xero. Each come with varying degrees of complexity but all are possible and becoming more the norm.

We like to think of ourselves as the experts in integration with Xero so if you requirements match the above or differ in any way, please get in touch we would love to discuss your requirements.

14 for 14: New Layout Object Formatting and Styling Options

Wed, 03 Jun 2015 00:00:00 +1200

Better than ever!

FileMaker just keeps getting better! With 14 we have more flexibility than ever before when it comes to creating gorgeous looking solutions. A number of a new layout styling options help make this possible. In this article we cover some of the new layout object styling options.

Placeholder Text

Not so much a new style property as it is a new feature that can also be styled. Placeholder text is fully styleable in the same way a text label is. Check out this article on placeholders for more information and other cool applications of placeholder text.

Touch Keyboard Control

With FileMaker 14 you now have total control over which keyboard to use for any layout object on iOS devices. You can specify a keyboard that is most relevant for the field type. This option is on the data tab of the inspector.

You can also now disable the touch keyboard programatically using the new script step:

Enable Touch Keyboard [ Off/On ]

This is useful in read-only solutions, or fields where you want the user to be able to enter it and scroll (think large text boxes) but not edit. A script trigger could be utilised to turn the keyboard off when entering (and on when exiting).

Better scrollbars for portals and fields

This is one of my favourite new features for creating beautiful solutions. Both portals and fields now have additional scrollbar options. These allow you to not show the scrollbar unless the portal/field is being scrolled. They look much more like native OS scrollbars and it means you need not show FileMaker's standard scrollbar all the time. The scrollbar only appears when scrolling, or when the mouse is placed over the scroll area. This option is on the data tab of inspector under control style.

Easier Tab control styling.

Tabs have been improved when it comes to easier styling. You can now define style properties that are automatically applied to each individual tab. Prior to 14, each tab of a tab control object was styled individually and you had to select every tab if you wanted to style them all at once. This inevitably led to tabs being setup with different styles.

Now it is simply a case of ticking an option in the tab control setup to allow you to define one style for all tabs.

Field control over button & Icon

Fields that use the control style of popup, drop-down or calendar now have more formatting control over the button area and the icon:

The button area is the right hand side section that is clickable to initiate the drop-down or calendar. This area has full styling options now in all of the states.

The icon can have its colour changed in all of the states such as hover, in-focus and pressed.

Using these new formatting options you can build some very nice looking fields.

The icon is also styleable through conditional formatting, this means you can impelment some cool features such as having the icon appear grey/disabled if the field is not required. You could also utilise icon colour to indicate an error with the field.

Consider a date field where you want to visually indicate whether the entered value has expired:

The icon can be conditionally formatted as such:

This creates a really nice visual cue for expiration as opposed to filling the entire field red, or any extra labels.

Icons cannot currently be changed - you are restricted to the standard arrow/calendar icons, but hopefully this will change in future given the new icons we can setup for buttons.

Checkboxes and Radiobuttons

There have been some additional styling options added to both checkboxes and radiobuttons.

The first thing you may notice above is that the checkbox actually now shows a tick. This is a customisable option via the control options and is available for checkbox sets only:

Check is the new option, and the default is "X".

Checkboxes and radiobuttons also now have full styling for the "button" and "icon". In the case of these controls, button refers to the square checkbox, or the circular radiobutton. Icon refers to the contents of those - either the tick/X for a checkbox, or the inner circle for a radiobutton.

Buttons and Button Bars

Both of these are topics we'll cover in other 14 for 14 articles, but it is good to reiterate here that buttons now have more customisation options available with the introduction of icons. With a standard button you can control the icons colour (providing the icon is either a standard FileMaker icon, or an SVG inserted).

With button bars you can control all the style options that buttons have, with a couple of additions:

The Segment and Icon areas are the main formatting options for the buttons on a button bar. Dividers are literally just the dividing lines between segments, and button bar has styling options common across all segments such as the border outline, outer shadow and rounded edges.

Example File

We have included a demo file with this article so you can check out all of the new formatting options for yourself.

Click here to download the demo file

14 for 14: Building a Navigation Button Bar

Thu, 28 May 2015 00:00:00 +1200

Previous Navigation Articles and our own Navigation

This is the third navigation article we have done and it has been quite some time between drinks. The first one - Starting out Simple - covers building a basic navigation bar using repeating fields. In the second article - Taking it Further - we extended upon the first by introducing selected screen highlights and a navigation script.

It may surprise you to know that we here at Digital Fusion still use this method for our navigation bar with some small tweaks. Repeating fields are still utilised and have been abstracted to the point the navigation bar setup can be customised per-user and all of the formatting can be done via a combination of styles and editing the repeating field contents. It is robust, works well and highly flexible.

So why consider the button bar?

It's a great question. The button bar on its surface seems to be very similar to our navigation method in regards to how it can be styled to look, and how it functions. Each segment can run a script for navigation, and you have total control over how it looks - sounds like a perfect substitute!

And for most applications it is, but there are some small limitations as we'll get into later.

One of the biggest benefits of the button bar over other methods is that the button bar is simply a layout object without a fixed context. If properly setup, it can be built to be entirely generic and contextless, and therefore able to be copy/pasted across multiple layouts.

The components of a button bar we need to setup

So you've decided you want to use a button bar for your navigation - how do you now make it entirely generic and contextless? If we look at the button bar setup we can identify areas we'll need to abstract:

The first we will cover is the label. Fortunately labels can be defined for a segment based on calculation so that is perfect, we can have a different calculation result for each segment.

Next we need to be able to run a script to carry out the navigation. The script needs to know which segment was pressed by the user in order to carry out the correct navigation. Fortunately we can pass a script parameter that differs for each segment, so that takes care of that.

What about if we wish to highlight the current screen segment the user is on? Fortunately once again we can specify what the active segment is via calculation so all good there.

The last thing is icons. Ahh, now we have a little issue. To this point everything could be abstracted into a calculation, and thus alterable outside of the button bar object, but can we change the icon? The answer at this point is no. If your navigation bar is to use built in button icons, then once you define an icon for a segment that's it. You cannot programmatically alter this icon in the future, meaning if you wanted to change it you would have to copy/paste the button bar across all your layouts again.

No icon? Perfect! The button bar is a great tool for a text based navigation bar.

So how do we abstract?

There are a number of ways in which you can abstract the information needed by the button bar. In our example we are going to build a simple navigation table to store our information. We'll then build a custom function to obtain this information for the button bar to use.

Above we have our navigation table. It has three fields:

Segment - just a number. It will correlate to a segment of the button bar.
Label - what we wish the label to be in the button bar
Layout - what layout will the navigation take the user to when clicked.

And here is our example navigation bar:

As you can see we have 5 segments. Each label correlates to the segment defined in the navigation table. If we were to for example swap the segment numbers for Penguin and Phone in the navigation table we end up with:

The button bar automatically responds to this change and reorders the Phone and Penguin segments.

Notice anything unusual though? The icons! We cannot have control over these so this type of dynamic reordering of a button bar is prone to problems if you use icons unfortunately :(

Getting the Navigation information to the button bar

It's all fine and well to setup this information in a table but we need to deliver it to the button bar in a way such that the button bar does not have to deal with context.

To achieve this we have built a simple custom function which we call @NAV_GetProperty

This custom function takes two parameters:

_theNumber: This is a segment number for which you want information.
_theProperty: This is a keyword that tells the function what information you need.

And that's it. As an example, what if we needed the label for the third segment:

@NAV_GetProperty ( 3 ; "Label" )

The result of this function will be "Phone".

The custom function is used in three situations:

To define labels - @NAV_GetProperty ( 1 ; "Label" )
Navigation script to obtain layout - @NAV_GetProperty ( 1 ; "Layout" )
To determine active segment - @NAV_GetProperty ( "" ; "Active" )

The last situation there is a slightly different case where we do not pass a segment number. In this case the custom function returns a segment number that corresponds to which one should be the active segment.

Using ExecuteSQL to abstract

The custom function is able to return this information, and determine active segment, through the use of the ExecuteSQL function.

For obtaining the layout or label, it simply is carrying out a SELECT query based on the passed segment number, and property. Note: The property corresponds to the field name in the navigation table - so if you decide to change these field names you must also update the custom function accordingly.

Defining what an Active Segment is

In order for us to show an active segment, we must first understand how FileMaker defines what the active segment is for a button bar.

We can either define the active segment explicitly, or via calculation. If defined explicitly we have no control over dynamically altering this, so it is useless for our navigation bar.

What needs to be returned by our calculation in order for the result to be treated as the active segment? The answer is an object name. Each segment can be assigned an object name via the Inspector, and FileMaker compares the calculation result to object names in order to determine active segment.

What are the implications of this? Well first you need to ensure every segment in your button bar has an object name. In our example we have given each the following:

nav_X

where X is a number from 1 to 5, in order.

Active segments are determined by first looking at what layout the user is on. The custom function will perform a SELECT query to obtain the Segment number for the navigation record whose layout matches the current layout. This tells us which segment number our layout is for. We can then simply prefix it with "nav_" to return an object name that corresponds to the button bar active segment.

Putting it all together

We have now a single custom function that we can use to define the active segment and segment labels and layouts.

Our active segment calculation is thus:

@NAV_GetProperty ( "" ; "Active" )

Our label calculation is:

@NAV_GetProperty ( 1 ; "Label" )

and our Navigation script is passed a segment number from which it can obtain the layout:

@NAV_GetProperty ( Get ( ScriptParameter ) ; "Layout" )

Very elegant, very simple, and very flexible!

Taking it further

Because ExecuteSQL is used to obtain navigation information, you can do some pretty cool things with your navigation bar setup.

Perhaps you added a new table called "UserNavigation" which acts as a join table between Navigation, and your Users table. Each record has a user ID and a navigation ID. Basing your navigation bar on this table, you could have different navigation bars for users based on things such as their access privileges, or role. Simply add a record for a user to give them screen access via the button bar.

Another cool feature of the button bar is that text formatting functions will override the styles. You can therefore conditionally format labels to appear disabled if you wish to prevent user access to certain screens as opposed to hiding that screen from the button bar. Using the TextColor function you can achieve this.

Button Bar limitations

We have already covered some limitations around abstracting icons, but there is another property of button bars that may mean they are not suitable to your needs. Each segment of a button bar is the same width as all other segments - you cannot define an individual segments width. This means segments with a long label will wrap its text as opposed to extending the width of the segment:

Sometimes this may not look that bad, but icons will be offset to accommodate.

In conclusion

Button bars are a great FileMaker 14 tool and can be used for a number of applications, one of which may be a navigation bar. As far as making them totally abstracted goes, they work best without icons but if you can live with the icons being fixed to the object then they look great with icons.

Compared to our older articles around navigation bars the button bar comprises of only a single object as opposed to multiple objects for the repeating field implementation. Button bars should also work great in WebDirect and FileMaker Go.

We are strongly looking at whether it is worth making the switch from our repeating field based navigation to button bars. At this point the jury is still out and icon abstraction is a big limitation that will likely see us keep to repeating fields for now.

Example File.

All the screenshots and examples in this article are from our demo file that you can download below. Obviously being a FIleMaker 14 feature this works best in 14, but you can still open it in 13 if you need to.

Click here to download the example file

14 for 14: Shortcuts for Quick Script Step Entry

Thu, 21 May 2015 00:00:00 +1200

Introduction

One of the coolest overhauls in FileMaker 14 is to the scripting area, now known as the Script Workspace. There are many cool new features here but the one we will focus on in this article is the ability to type script steps directly into a script. Further to this, we cover how FileMaker 14 attempts to auto-complete your entry to find the corresponding script step.

With a little practice and habit, you can find the best shortcuts to use for every script step that will allow you to type either the shortest, or the most intuitive shortcut to find the specific script step you wish to add.

Please Download our Reference File Provided

There isn't really much to this article itself because the real benefit will come in downloading and viewing our associated reference file. In this file we have provided a number of shortcuts that can be used for every script step.

We provide what we believe to be the most intuitive shortcut you can use to auto-complete a script step. We also give you the shortest shortcut (in terms of characters required) to enter any script step. Finally, we give any useful variations on these that can also be used.

We hope this provides a useful resource for you starting out with FileMaker 14 and ease some of the burden of discovering these shortcuts yourself :)

You can click here to download the Reference file

Please Note: While this particular reference file will work in FileMaker 13, it works (and looks) best in FileMaker 14!

How does the Auto-Complete work?

FileMakers auto-complete for script steps follows a couple of rules that help determine which script step(s) it finds as matching results to what you type.

If you are typing a word, then it will match any script steps that contain any word that begins with what you type. For example if we enter "insert" into the script workspace we get:

Every single script step with a word that begins with "insert" is found. Now this is quite a lot, and so trying to isolate a specific script step just with "insert" is not very useful, as it will require you to mouse/keyboard through the results.

Ideally what we want is a word that is used in a script step that better identifies that step. Let's say we wanted to find the "Insert from Device" step. Let's try the word "from":

Better, but not perfect. The next logical choice is to enter "Device":

Bingo! That is exactly what we are after - a single result. We can now just press return to auto-complete. You will find there are a large number of script steps that have an "intuitive" word in them that only exists in one script step, and can be used to isolate that step.

What about script steps that are more common? How about the classic "set field" ?

Ah, we have a problem here. There are a lot of script steps with the word "set" in it. Now, we can just continue typing "set field" and that will find our result, but can we type something else even quicker? How about just "field"?

Ah, well that is actually worse! What has happened here is all matches for the word "field" are shown, but the sort order here is interesting.

FileMaker will sort the results alphabetically starting from the first word, moving onto the second word, and so on. Export Field Contents is the first matching step that is first alphabetically, and so is the first result.

You will find that this sort order is both helpful and a hinderance depending on what script step you are trying to auto-complete, which makes it even more important to know how to best find the step you are after.

Auto-Completing using the First letter

So far we have covered searching using keywords, and how FileMaker orders matching results. For most steps, simply entering an intuitive word, or typing enough of the step so that it is the only match is enough to find the right match.

There are some however that are a little trickier given their use of common words, or their length. There is another way we can find results using the first letter of script step words.

lets use the classic "Go to Related Record" as an example. Using our methods so far, we could find this step using the word "Related" because this is the only step with this full word in it.

However quite often people know this step as its abbreviation "GTRR". We can actually type this to find the step also as this follows the rule of using the first letter of script step words.

Something interesting has happened here! It has found the right script step, but we are also seeing "Go to Record/Request/Page" also, why? Well if we follow the rule, both script steps actually have words that begin with the letters "GTRR" in that order. If we followed the rule even further we could use "GTRRP" to find just the first step. Now, there are actually easier ways to find that step but the first letter rule can also be applied here (or to any script step).

Sometimes this first letter rule works nicely, other times it does not. There are a couple of things to note about using the first letters:

It works in order of the step. So "RRTG" will not find the Go to Related Record step.
If multiple matches are found for an abbreviation, the alphabetical rule applies

Below is an example of the alphabetical rule being applied:

All three steps have words that begin with G, T and R in that order. Note however that "Go to Portal Row" is the first match. This is because if we view them alphabetically the word "Portal" comes before "Record" and "Related". This seems odd that GTR would find this result, but based on the rules it is correct. A better abbreviation to use to find this step would be "GTP". It matches all of our rules, and there is only one script step whose words begin with G, T and P in that order.

Reference File

You can download the reference file here

14 for 14: Working with the Script Workspace

Tue, 19 May 2015 00:00:00 +1200

What the Script Workspace looks like

Below is our reference image of the script workspace that we will use in the article, just click on it to enlarge.

1. Running a Script

These two buttons allow you to either run the selected script directly, or to run the selected script in the debugger. Being able to run direct in debugger is a great new feature and saves you having to open and close the debugger while working on a script.

The + button is for creating a new script. The new script is placed underneath the selected script (if any) otherwise it is placed at the bottom of the list of scripts.

2. Working with the Scripts Menu

The script workspace is divided into three main sections. The first we will deal with is called the Scripts Menu and this always appears as the left-most section.

The first button is for showing/hiding the "Show in Scripts Menu" checkbox. When ticked, a script appears in the scripts menu. This button is not for setting this checkbox, merely to show or hide it.

The next icon is for creating a script folder.

The last icon is for adding a separator. In the Script workspace, separators are no longer blank scripts, they are actual separators.

3. Script Search

This is for locating a specific script or scripts in your list. The search works in the same way as previous versions - it will search from any point in the script name but only sequentially. In the screenshot above we have scripts named Script A through Script D.

A search for "Script" will find all scripts. A search for "Script A" only finds that script. A search for "ript A" will also find this script.

It is important to note this search differs from the way the script workspace and data viewer now carries out auto-complete on your text, you can learn more about these in other 14 for 14 articles

Folders are also shown in search results for the matching script.

4. Script List

The list of scripts will show folders and script names. We have already covered the show in scripts menu checkbox.

There are two other icons that can appear beside a script:

This icon indicates the script is run with full access privileges

This icon indicates the script is in an unsaved state.

5. Open Scripts

There is more to this one than meets the eye. The script workspace now has tabbed scripting meaning no longer will you have separate windows for open scripts.

Now, there are some interesting things to note about how the tabs work. To demonstrate this lets start with no scripts selected:

Without a script chosen we get a nice icon of a script, how lovely.

Now lets single click on a script. Note here single as opposed to double click.

When a single script is chosen using a single left-mouse click you'll notice the script name appears in blue text. The blue indicates that this script is the "active" script, and the one that we shall call "unlocked".

If you now click through other scripts using a single click, this will change the active unlocked script to the one you choose. The end result is only one script tab open at any given time.

Now lets go back to nothing selected and this time we will double click the same script:

The script tab is now entirely filled blue as opposed to the text blue. A blue tab indicates the active tab. In this case because we double-clicked Script C it is now locked into its own tab. If we now select another script, we will open that in a new tab, with Script C now locked into its own tab:

Script B is now the active tab, but because we single-clicked script B to open, it is not locked to its own tab, and choosing another script will replace Script B with the new script.

This will be an important distinction to learn. In situations where you want to keep a script open in the workspace remember to double-click. If you do not need it locked single-click instead.

You can also still open scripts in their own standalone windows if you need to. This is not a shortcut feature, nor is there a button for it. You can access this via the contextual menu or the View menu while in the script workspace:

Note also the feature to select scripts in the scripts pane. This is useful if you have lost your context in the scripts list, for example if you have searched for another script in the mean time.

You can directly edit a scripts name by double-clicking its open tab:

6. Scripting Area

This is where the core of your scripting occurs. There are a number of great features here to help you write scripts fast.

One of these is auto-completion of script steps you type. This is covered in a separate 14 for 14 article where we give you all the shortcuts you can enter to enter specific script steps.

One thing you may notice first is there is some colour now to scripts. Colour can be defined for the following:

The above menu is accessible via the View -> Syntax Coloring... menu.

This script step has been disabled, but how do we disable steps? In FileMaker 13 there used to be a big disable button at the bottom of the script, but this is now gone.

The answer is to use a shortcut key, this is by far the quickest way. On a mac the shortcut is cmd+/ , on windows this is ctrl+/ . You can use this to toggle enabled/disabled. The option is also available via the Edit menu.

A blue line indicates that line is selected. How might we go about inserting a blank line into a script? In the example above lets say we want to put a blank line between these two steps.

The answer is simply the return key.... with a couple of gotchas to look out for. A script step may be selected such as above, but there is a difference between a selected line, and an active script step. When no step is active, the return key will create a blank line.

We can now also define whether to insert a blank line below or above the selected line. Hold the shift key with return to insert a line above the selected line.

Back to active steps. How can we tell if a script step is active? The surefire giveaway for most steps is either the settings cog icon appears blue, or any part of the line appears in a blue outline:

Both of the above steps are considered active. For active script steps the return key does not create a blank line but has the action of activating the step. This normally means either toggling a setting, opening the script step setup, opening a popup menu, or directly entering the step for data entry as is the case with an IF script step.

Initially this may cause the greatest source of frustration for you when trying to work with scripts. More often than not once you finish setting up a script step your next action is to insert a blank line, however your script step may still be active in which case you will go back into its settings.

There are two ways to resolve this issue. The first is to use the command modifier key with return (ctrl on windows). By using cmd+return, this will always insert a blank line beneath your active script step.

Another way we have uncovered during development is to simply save your script using cmd+S. Saving a script will deactivate any active line.

Working with Script Step Settings

Once you have an active script step, return generally will open its settings in whatever form that may take. For control steps such as IF and LOOP it will depend on what is visually the active element of the step:

These steps have two possible active elements - the direct data entry component, or the Fx button which will open the calculation engine. The great thing about this script step in 14 is you can directly enter the code for a basic IF statement without the need to enter the calculation engine. The tab or arrow keys can be used to toggle between the active areas of the step, and the return or space bar will activate that area.

We won't cover all variations on steps but suffice to say the vast majority of script steps will no longer require the user to reach for the mouse to setup which is great. There are still some steps that are going to require you to reach for the mouse, such as Set Variable, or set field (if you need to specify via calculation) or the setup of a Custom Dialog. We think these will slowly become a thing of the past and in future everything will be mouse free.

Knowing when to use space bar versus return

Not all script steps work quite the same, and different steps have different amounts of settings. Sometimes you will find using the space bar to setup a step is much faster than return. We will use the common "Set Field" step as an example here.

First thing we do is type "set f" followed by return to create the step:

The step is selected, and the settings icon is activated. This means we can use the return or spacebar to open the settings:

For all intents and purposes it looks like the 'specify target field' option is selected. It is, but the return key will dismiss the settings popover we are looking at, which is not what we want.

Instead, the spacebar more often than not will open the selected settings area, and from there we can setup the target field (albeit having to reach for the mouse most likely!)

Once we select the field, we are presented with the above. Now it looks like no setting is highlighted so what do we do? Well, return key will dismiss the dialog so that's no good. The spacebar does nothing because no setting is chosen.

In this instance arrow keys become our most useful keys. A down arrow press will reselect the specify field option. Pressing down a second time selects the calculated result option, and then spacebar will open it.

While it may seem odd, we guarantee you will get into the habit of using a combination of return, space and arrow keys to navigate these various steps with ease, it just takes a little practice!

What about comments? Well in 14 a comment is still a script step, but it is very easy to add. simply enter a hash symbol to directly enter a comment. Alternatively a quick way is to use space+return in sequence. Space will initiate the drop-down of auto-complete steps. Comment is the first step in this list as shown below. Now just hit return to add that. Some may find this easier than reaching for the shift+3 shortcut. (note that compatibility shows in auto-complete how nice!)

The final thing we'll mention about the script area are line numbers.

While they serve no real scripting benefit, they are useful if you are referencing a specific point in a script to another developer or user. Breakpoints can still be set by clicking on a line number as shown above.

There is so much more to the scripting area but we will leave it up to you to explore!

7. Manage workspace and compatibility

The first of these three buttons is for nominating a specific compatibility platform:

Lets say we only want to show Server compatible steps:

Incompatible steps appear here in red in both the script itself, and the list of script steps. This colour is a customisable colour, but red is pretty clear !

The other two icons are for expanding/collapsing both the scripts list, and the script step lists. We think that you'll actually end up never showing the list of script steps when you become more proficient at working with the new script workspace. Once you learn your favourite shortcuts for auto-completing script steps there really becomes no need to show a list of steps, and it can be hidden to free up more space for the script.

8/9/10. Script Step List

If you do feel the need to list all of the script steps, there is a nice new feature that allows you to mark specific steps as your favourites. These appear in the top group of scripts so that they are readily available (Think Show custom Dialog!!)

To add an item as a favorite, click the star icon with the step selected - and do the same to remove it from the favorite list.

The a/z icon is for showing the script steps as a full list alphabetically as opposed to grouped by category.

If not sorting alphabetically the grouped option is really much better now as you can collapse groups that aren't frequently used to keep your list of steps shorter.

Script steps can also be right-clicked to reveal the following contextual menu:

A useful option here is to look up the step in documentation, useful for beginners (or developers who have forgotten a thing or two!)

11. Selected Step Information

Another good feature for beginners. This panel displays some information about what the selected script step does. You can also click the little question mark icon to go to the documentation for that step.

Contextual Menus and Script Menus

It is worth also exploring contextual menus and the script menus for additional options and shortcuts. There are a number of contextual menus in the script workspace.

The folder contextual menu has options that are normally achieved through shortcuts, however we think the Print option is pretty cool. this will print all scripts within that folder. This has been a useful tool in the past if you need to locate a given item in a script. Print the scripts to PDF and then search the PDF for what you want.

Most of the items in the script contextual menu are again fairly straightforward but you'll notice here you can choose to open a script in a new window. This is not a shortcut feature so you will have to use the contextual menu on either the script, scripts open tab, or the View menu. Note that a script in its own window does not have the scripts list:

The edit menu in the script workspace has all the usual suspects, but just take note that this is where the disable/enable script step option and shortcut lives:

The view menu contains the syntax coloring option which is not accessible from anywhere else, and has no shortcut attached.

Note the different shortcuts for closing items. We don't think closing all tabs will be used much as holding down the close tab shortcut for a second or two seems to do the same job. It will be important though to distinguish between closing a tab and closing the workspace. In FileMaker 13 we only had the ability to close a script - there was no workspace. Now you'll need to learn to hold shift to close the whole workspace.

It is also interesting to note that if you close the workspace with scripts open, those scripts will remain open once you reopen the workspace, a really nice feature. Even cooler is that this persists even after the file is closed for files both local and hosted!

The scripts menu has all the usual suspects. Ones to note are the shortcut for opening a script directly into a new window when selected. If you have a script open in a tab, then using the "Open Script in New Tab" has the effect of locking that script tab open.

In Conclusion...

The script workspace is awesome, embrace it and love it!!!!!

14 for 14: The Power of the Placeholder

Fri, 15 May 2015 00:00:00 +1200

What is a placeholder label?

Sometimes also called an in-line label, a placeholder is a field label that appears inside a field when that field has no value. For the rest of the article to make things less confusing we'll call it a placeholder label.

A placeholder label is a valuable UI tool. Firstly, it frees up space on your layout by having the label occupy the same space as the field. Secondly, there are some fields which don't constitute the need for a label to be visible at all times. Consider an e-mail address. When a valid e-mail is entered into the field, it is obvious to almost everyone what that data represents, so to tell users that it is an e-mail address is somewhat redundant. Using a placeholder label for this field will free up space otherwise occupied by an unnecessary label.

Sometimes placeholder text can help further describe a field in addition to a label that is always visible. Lets take a date field on a layout labelled "last contact" :

This field is to have a date entered for the last time the customer in question was last contacted by the individual. Simply taking "last contact" alone is not enough information to know what should go into the field. Is it the last contact who worked for the customer? Is it the name of the last person who someone spoke to? Or does (as in this case) contact refers to a date communication was made? Sometimes a placeholder label can supplement the primary label to give additional information as to what should be entered in the field. Once the information is entered, the primary label is sufficient to describe the value.

FileMaker 14 Makes them so much easier

Prior to native placeholder text in FileMaker 14, placeholder labels were possible, but nowhere near as easy to implement, nor did they function in such a nice way. The standard way to do a placeholder label was to overlay a text label on top of a field, and either conditionally format it (pre FileMaker 13) or hide it (in FileMaker 13) when the underlying field was not empty. This method suffered from a couple of problems. First of all the label would disappear as soon as the user clicked into the field. If you were able to resolve that issue through some transparency trickery, then the next issue was the label would not disappear as you began typing (again this could be resolved through script triggers), but what a hassle!

In FileMaker 14 it is so simple. Placeholder text is defined as part of the layout object, and can be specified on the Data tab of inspector:

The text appears in browse mode (and find mode if you use the checkbox option) when the associated field is empty.

You also have full styling control over the placeholder text via the appearance tab:

You can even reveal the placeholder text while working in layout mode by placing your mouse over the new placeholder badge on the layout object (note this actually now works in 14 for all types of layout/object badges, try it!):

An awesome secondary usage - a layout calculation display engine!

You may have noticed above the little edit icon next to where you define the placeholder text. This will open the calculation dialog allowing you to specify the text to be whatever you want.

Boiling all this down to its core - you can define text to display in a field via calculation. What if that text was not necessarily a label, but instead a summary value, a text display, a warning, an error check, and so on? Why not use placeholder text as a means to display calculated values direct on a layout?

Why not indeed!

To do this all you need is a global field that is non-enterable and will never have a value. In this state, placeholder text will always display. Then simply define your text using the calculation, and format it how you want using the styling options, it's just that simple! Style the field itself to be visually hidden to replicate a calculated piece of text.

Why would you want to do this, what's wrong with calculation fields?

Nothing is really wrong with a calculated field to achieve this, and it will still work in FileMaker 14. There are however a number of benefits to your solution for using this method:

Fewer UI related calc fields in your schema, keep your tables for data only
Keep display where it belongs, on layouts
works great with executeSQL and portals, define placeholder within portal contexts
Text formatting functions work great with it, alter colour of your display within the calculation

Overall we see the biggest benefit is simplifying your tables and removing UI related fields and relationships. Just be careful of overusing this when it comes to FileMaker WebDirect solutions!

Example File

To accompany this article we have produced a lovely demonstration file to give you some ideas as to how you can use placeholder text and how it can be setup.

Please note that because this file is demonstrating a FileMaker 14 feature. While we have not restricted access to the file to FileMaker 14 only, if you try to open it in FileMaker 13 don't be surprised if you don't see much of any use :)

Click here to download the demo file.

Introducing the FileMaker Weetbicks 14 for 14 Series!

Wed, 13 May 2015 00:00:00 +1200

We're all about 14!

FileMaker 14 is here! To celebrate, FileMaker Weetbicks has written 14 articles all about FileMaker 14. Over the next few weeks we will be releasing these articles to the community. We cover all the cool new features (and some hacks!) and take things further as we usually like to do :) Stay tuned!

A Sneak Peek at what we'll cover

14 articles means a lot of great content on a number of different topics, some examples of what you can expect:

Button bars and what you can do with them
Script Workspace and making the most of it
Calculations and schema
All the little hidden features you may miss
All the cool new layout stuff and examples of putting it to good use
Features that can be used for more than their original intended use ;)

and more! Keep checking back for new articles, or sign up with your e-mail address to receive notifications when new articles are released.

A number of the articles also have sweet 14-ized demo files to go along with them that look great and are a handy compliment to the articles.

14 is as cool as it sounds

We have loved writing these articles and playing with FileMaker 14 - it really is an awesome release chock full of awesome new features to make development easier and more fun than ever before!

.... I'm just glad I decided on 14 for 14 instead of 30 for 30 years of FileMaker!

(by the way this counts as #1, nya nya!)

FileMaker 14

Wed, 13 May 2015 00:00:00 +1200

We are pleased to announce that FileMaker have today released version 14 of their software for desktop and iOS.

We are all incredibly excited by this release. It brings some new features that the developers have wanted/needed and we can see areas where we can further enhance your solutions. FileMaker WebDirect and FileMaker Go make some big leaps forward and both products are starting to ‘mature’ really nicely.

For all the good stuff in it this is a major change so we recommend you don’t upgrade just yet.

As there are a number of system requirements that surround the upgrade, we believe it is best to wait and we will give you some more details in the next week or so.

In terms of showing off some of the new features, our own Daniel Wood has written 14 blog posts that will be released over the coming weeks. These get into the real specifics around FileMaker 14 features, so if you have a technical bent, it would pay to regularly check back on Daniels blog at http://www.weetbicks.com

For those who want an idea of what to expect, here’s a bit on each of the different FileMaker 14 platforms:

FileMaker Pro
The flagship desktop product has a raft of new design and user interface tools that makes it easier than ever to create even more beautiful solutions.

FileMaker WebDirect
FileMaker’s WebDirect technology for web based deployment has been vastly improved in terms of performance and support. It now supports mobile browsers on tablet devices such as the iPad and Samsung Galaxy, and other Android based tablets. FileMaker have invested a lot in this method of deployment so you should check it out and see whether it is right for you.

FileMaker Go for iOS
FileMaker Go has a number of great user interface and performance improvements. These new features such as improved touch controls and gestures will make databases feel even more like native iOS applications than ever before. Combine that with a number of user interface and usability improvements and the future looks bright for mobile deployments.

FileMaker Server
FileMaker Server has had a security overhaul and it is now more secure than ever to host your solutions with FileMaker Server to keep your data safe and secure. If 100% uptime of your solutions is important to you then you’ll love FileMaker Servers new failover server feature that will allow you to switch to a backup standby server (with a little help from IT support!).

As always we are here to support you with all things FileMaker so if you do have questions or need our assistance do get in touch.

Change Containers from Files to Interactive Content in an Instant

Tue, 21 Apr 2015 00:00:00 +1200

File versus Interactive

If you are wondering what we are meaning when we talk about files and interactive content it is rather simple. There are two ways in which data can be stored in a container. The first is simply as a file. This is done using the "Insert File" option or script step (without interactive settings chosen).

Items inserted into containers as files are unable to be used as interactive content, and they display as an icon and filename only. In the past before FileMaker 12 this was the primary method of inserting items into containers, and when it comes to older solutions you will find most have files stored in this manner.

FileMaker 12 introduced interactive containers - a means to make container data more "interactive" funnily enough. It gave the ability to scroll PDF documents, listen to and stream both audio and video direct from containers (and the server). The problem with this new method of container display was that it did not play ball nicely with container data that was inserted as a file. Interactive containers on layouts were unable to detect the type of file in a container whose contents was added as a file, and so contents could not be rendered interactively. Below is an example of what a container looks like with a file inserted.

How do we make use of Interactive Containers?

This dilemma arose primarily out of the fact interactive containers can nicely render PDF documents that can be scrolled, opened in preview, printed and saved. We wanted to use this new feature, but all our existing client solutions prior to FileMaker 12 had their PDF documents inserted as files, and as such were not compatible with interactive containers.

Our initial methods for making the fix were rather crude and involved writing scripts that would loop through records, exporting container contents to the temporary folder on disk, and then re-importing that back into the same container, albeit this time as a PDF, such that it could be displayed interactively.

The process was tedious and time consuming, not to mention hard to setup for multiple containers on a large solution!

Introduce Stephen the Bright Spark!

Recently our most experienced developer Stephen was musing over this very issue for one of his clients solutions that house literally thousands and thousands of PDF's, which by the way are all hosted on remote volumes.

How could he display these PDF's as interactive content, without the hassle of exporting and re-importing? and then it hit him!

Actually, we're not quite sure how it hit him, but it's a little bit of luck, combined with a little stroke of genius, and he cracked it!

Base64 Encoding and Decoding is the key!

Stephen tested and showed that if you use FileMaker 13's Base64Encode and Base64Decode functions, you can convert container data into interactive container data, here's how it works:

Base64Decode ( Base64Encode ( Container ) ; Filename )

That's it! He realised that the encode function simply encodes data with no knowledge of its file type. The decode function however requires you to specify a filename with extension. This is the key thing, decode function will turn the encoded text back into a file of the nominated stream depending on the extension you choose. All you need to do is make sure the filename is the same as the original files name and you're all set!

In fact if we look at the definition for Base64Decode we see:

Base64Decode ( text {; filenameWithExtension } )

It explicitly requires an extension for this very purpose.

Putting it to use

There are a number of ways to make use of this. in Stephens case, he wanted to keep the files exactly as they were untouched so did not replace the container data. However he created an unstored calculation on the table with the container, and set it to the above function. He now had a calculation that can render the container as interactive content that he could use on layouts where needed.

You can also write a very simple replace script that can update all container data in a single step.

The example file attached below illustrates this. Here we have abstracted it all into a single custom function called "Interactivate" that is passed a container as a parameter. The output of this is the container data turned into interactive content. Simply run this function over any container you want to update to interactive content.

Example File

Please find attached an example file. This file is provided to help you fully understand what is going on in the rest of the article above. Note that FileMaker 13 is required to view this example file as it uses FileMaker 13 specific functions.

Click here to Download the Example File

Integrating FileMaker with Xero

Wed, 18 Feb 2015 11:18:00 +1300

Xero remains the number one piece of software our clients want their FileMaker solution integrated with.

This has been the case for nearly five years now, but what we are finding is that clients are keen to integrate FileMaker and Xero in different ways, and for different business reasons.

Traditionally the request was to ‘push’ all invoicing (including invoice contact details) from a FileMaker solution through to Xero.

Now clients are wanting more than just the invoice contact details pushed through, and they are keen for the information to flow both ways, from FileMaker to Xero and back again.

To follow are some of the requests and work we have performed by using the Digital Fusion Xero plugin. We have also listed the business case as to why this is important:

Push of invoice and contact details from FileMaker to Xero

Information moving both ways

Push all contacts through to Xero

Typically we have only pushed contact information through to Xero when an invoice is raised. Xero then looks to see if the client already exists and if not, it adds it as a new client.

Business use: The big gains here are around reducing double handing, you know longer need to key in details in both solutions, increasing the overall accuracy of data.

We like to think of ourselves as the experts in integration with Xero so if you requirements match the above or differ in any way, please get in touch we would love to discuss your requirements.

What I've learnt about FileMaker WebDirect

Tue, 17 Feb 2015 00:00:00 +1300

Okay I’m an account manager so please don’t hold your breathe for any technical wonderments in this article. What you will read is what we have experienced in terms of developing FileMaker WebDirect solutions.

We have been lucky to work with two clients over the last few months where we have developed WebDirect solutions (we also have another three WD projects on the go).

Both are very different, one we haven’t touched their main database, we have added a WebDirect element to the solution (in fact we have replaced the old Instant Web Publishing solution). The other is a new project, where we have developed a FileMaker Pro solution that can also be used via WebDirect.

So what have we found:

First up, get someone with WebDirect experience to develop you solution. The wealth of knowledge our team has built up over the past twelve months now makes us experts in how to tackle your development requirements. Along with this we have fantastic design skills, so it’s a seamless experience in terms of designing and developing for FileMaker WebDirect

If budget allows, use different design templates, and separate layouts (screens) for FileMaker Pro and WebDirect. Although you can ‘get by’ in using the same template for both, the user experience is not always ideal.

Be prepared to make refinements. WebDirect (particularly as we are only in version one) is not going to be perfect ‘out of the box’, there will need to be small tweaks made to get it to a tip top level of excellence.

Although WebDirect works in Firefox, it’s not a supported browser. We have discovered that it throws up the odd curly issue but on the whole the experience is not to bad, just not perfect

You need to install a custom SSL Certificate specific to your domain, otherwise your users will always have to authorise your browser to go to the domain name

WebDirect is not meant for the masses or the more intensive users of a solution, it’s a perfect solution for a discrete user group who don’t need the level of access that FileMaker Pro gives

There are some cool features we can now use, that were only previously available if you developed in native web. This includes being able to incorporate great design elements, plus the benefits of giving users a ‘web like’ user experience

It’s only going to get better. As we mention above, this is only version one (as part of FileMaker 13), with subsequent releases we have high hopes that FileMaker will continue to grow this product.

So all up, we love WebDirect, it’s a great product and solution and something all of us at Digital Fusion are incredibly excited to develop in now.

FileMaker announces the end of support for FileMaker 11

Mon, 02 Feb 2015 00:00:00 +1300

At the end of last year FileMaker Inc announced the end of support for FileMaker 11 - that doesn't mean it will stop working, but it does mean they will no longer be doing updates such as bug fixes, compatibility and security patches.

So maybe now is the time to make the leap?

Moving up from FileMaker 11 is pretty simple despite the fact that under the hood the changes in FileMaker itself are huge. Databases convert very simply and quickly.

The big change in FileMaker 12 was the layout 'engine' - that is the underlying way that FileMaker draws screens and reports are changed - in fact it is now based on CSS, the same standardised technology that the web uses. As a result when you upgrade you might see one or two small rendering issues - some objects on layouts might appear slightly different in size or positioning - generally not a problem and easily fixed if need be.

FileMaker 13 is the current version, and you can upgrade directly to it from 11 (or even earlier versions). FM13 builds upon the FileMaker 12 changes - it's faster and better again. It also adds some nice new user interface controls such as pop-overs and slides. They also added WebDirect in FM13 which provides a relatively quick way to make your database accessible in a web browser.

The biggest downside to FileMaker 13 is the introduction of connection licenses - FileMaker Go and FileMaker WebDirect use these. You need to purchase concurrent licences for both, which essentially is how many people you think will be accessing the database at any given time i.e. you might have 100 users in total, but only 20 of these are expected to be accessing the database at one time, meaning you purchase 20 concurrent licences.

On the plus side, FileMaker is getting faster over the internet and more web savvy with each version - this means FileMaker are staying current especially if you are using publishing to web or connecting over the internet i.e. cloud based hosting.

As always, we at Digital Fusion always recommend using the annual licencing option given by FileMaker. The main reason behind this is the ability to upgrade free of charge to the latest version of FM.

FileMaker to Xero Plugin

Fri, 16 Jan 2015 00:00:00 +1300

Bringing together our love of FileMaker and Xero (we are a Xero approved developer) was always going to be a natural fit for Digital Fusion. We use Xero ourselves and when we come across clients using FileMaker and Xero we get excited—it's a brilliant combination for running a business.

We are now at a point where we can say we are the experts in terms of custom integration for the two pieces of software, with a very robust plugin.

We do need preface this by saying that no two client requirements are the same so although we do have a plugin, it’s not one that we can package up and sell as an ‘out of the box’ product. We do however offer this as a solution offering here at Digital Fusion so if you ever do want to discuss this please get in touch.

This plugin fully automates processes so there's no importing or exporting. That means maximum efficiency and high integrity.

What the plugin does offer is:

It’s works on both Mac and Windows
The ability to Push contacts, invoices and credit notes to Xero
The ability to Pull contacts, invoices and credit notes from Xero
Can be installed on either the FileMaker Pro client machine or your FileMaker Server, and is handled automatically.
Supports Get and Post so we can develop features around any API endpoints that support these methods (Contacts, Products etc).
It queues invoices for processing into Xero either instantly or at a later date/time.
It works in both FileMaker 12 and 13. When using 13 you can leverage the Perform Script On Server command for instantaneous results.

We have also had experience in pushing products, collecting payment information for invoices and pushing or pulling payments themselves. At the end of the day linking with Xero allows you to both synchonise transactions and pull out information for reporting.

The plugin provides a simple framework that can be integrated with most FileMaker solutions and expanded to support any feature of Xero available through the API.

As Xero release new features we will continue to explore opportunities for ways we can integrate these with FileMaker.

Unlocking Hidden Error Messages in the ExecuteSQL Function

Wed, 07 Jan 2015 00:00:00 +1300

EDIT - Simpsons did it!

Well not quite the Simpsons, but maybe you get the cultural reference. Turns out this technique has been referred to previously on the custom function site fmfunctions.com here. Thank you to readers for pointing it out, and Andries Heylen for submitting the function! That is not to say the rest of the article is not interesting, so please carry on reading :)

A Simple ExecuteSQL Query as Illustration

Below we have a very simple query using ExecuteSQl. This query is asking for the field Tasman_URL from a table occurrence named zdev_Settings. This table only has a single record, so we do not require a WHERE clause in the query.

As you can see, when we use the data viewer to evaluate the query, we are given the resulting field value as output, all pretty standard stuff.

Next, lets break the query. To do this we are going to change the field name to Tasman2_URL.

Because this field does not exist, we have a syntax error in the query. Anytime there is an error in our query, FileMaker returns a solitary question mark as output. Oh how useful this is! The question mark tells us something is broken, but most of the time knowing what is broken is hard to track down, particularly in very large queries involving things like joins, where clauses, ordering, aliases etc.

Here's where things get interesting...

So recently I have been developing an internal solution and making more use of ExecuteSQL during development. While testing queries in the data viewer, I happened to enter a particular query in a Let statement. The idea was that if "?" was returned, I wanted the result to be nothing instead of the question mark, eg:

IF ( Query = "?" ; "" ; Query )

When I put this into the data viewer and pressed 'Evaluate' what I saw was quite interesting:

Where did that come from!! The evaluated result of the calculation - which was meant to be nothing - instead was showing as a nice descriptive error message telling me exactly what was wrong in my query.

When I went back into the data viewer calculation, the message was still showing. However as soon as I hit "Evaluate" it disappeared and the expected blank result was shown.

So when does the message appear?

After (not so) extensive testing, I have been able to only reproduce showing the error message in the data viewer, after the "Monitor" button is pressed. Once you go back into the calculation the message remains, but using the "Evaluate" button will cause it to disappear.

The error message does not appear to actually be a result of the calculation, as using the Let statement in scripts and other calculations never yields the message as a result, it appears confined just to the data viewer, which is actually quite a nice place for it to stay.

You can actually get the messages to appear by simply returning blank:

To make good use of it in practice I have created a simple custom function called "SQL" which simply takes the query as input, and outputs blank if the query yields a question mark (otherwise the query result is outputted).

What types of error messages can it return?

Again I have not gone into huge testing here (hopefully the community reading this can do that ;) but I've found a few messages it can return so far. After searching round the internet these may be standard SQL error messages, though not 100% sure on that. Below are three examples of errors produced so far:

The first one results from an incorrectly named table occurrence. The second is an error in the query syntax - in this case I incorrectly spelt the keyword 'FROM'.

The last example is of a data type mismatch. In this example the field 'type' is a text field, but we are comparing it to a number.

Further testing and discovery

I did some searching round the internet but was unable to find any references to this coming up in the community before. If anyone has come across this peculiarity before I'd be keen to hear it. Also it would be good to know if there is an easier way to extract these messages, and whether they can be obtained by means other than the data viewer. I look forward to hearing peoples results!

Example File

Sorry, I didn't think there was much worth in producing a demo file for this given it is so simply reproduced and FileMaker Pro Advanced is required for the data viewer.

Designing and developing a 'Proof of Concept' using FileMaker

Wed, 26 Nov 2014 00:00:00 +1300

Over the past twelve months we have been approached by a number of clients to develop a solution as a proof of concept. What a client deems a proof of concept can sometimes vary but in essence it’s to develop a solution as a ‘minimum viable product’

Why would someone want to take this approach:

For some it’s around reducing their risk, they invest at the lower end of the spectrum and then as the solution develops they can see whether it’s going to work out the way they expected.
Another is to demonstrate different technology options. A number of clients approach us as they are not sure as to what platform will work out best in the long term. To develop a proof of concept in both allows then to assess things and then make the right decision.
To demonstrate that a solution can be a viable resource. A prime example of this is a client that we have developed a FileMaker WebDirect solution for, they have now demonstrated to their peers that what they proposed is possible. Custom D will soon start developing them a web application that will replace the WebDirect solution, this can then be broadcasted to a far larger audience around the world.

What we tell clients before they head down the POC path is that what we deliver won't be perfect and on the whole it will not be good enough for full client/public consumption. What they do get is a working model of their concept, enough for them to go away and decide whether it will be a viable option.

A proof of concept frees the client up from feeling like they need to build out the whole system and therefore just focus on a implementing a key idea - it really helps people focus on true minimum viable product (MVP) unlike a ‘real’ project.

To demonstrate what we mean, the donut below is your MVP. We could certainly add to it by sprinkling sugar on top, adding icing, but at it's core the donut is the proof of concept, once you have mastered that you are away.

On the whole we find clients that have gone down the proof of concept path come back for more. They generally see that what we have developed is something that will work in the business and they are keen to extend it further.

So if you have an idea or thought around a solution you would like to see developed, do get in touch, we would love to discuss it with you.

Announcing Custom D - our new web company!

Wed, 15 Oct 2014 00:00:00 +1300

Hi,

I'm absolutely thrilled to introduce "Custom D", a new business that we're creating to focus on building more engaging web sites and applications.

Custom D is a brand new business spun out from the web team at Digital Fusion - it's the logical way to get a clearer and more powerful message out there about extent of our capabilities and experience.

Custom D inherits all the goodness of Digital Fusion and will focus on all things web. And the crew at Digital Fusion will now have a clearer mission — being one of the best FileMaker development teams on the planet.

We’ll be sharing resources, knowledge and the coffee machine, working as closely together as ever. There will be plenty of combined projects that span FileMaker and web, and for the time being we'll keep things in one place for you through Tasman and our billing processes.

Julie will be heading up the new company as Managing Director, with Sam as Technical Director, and Matthew taking charge of new business and looking after all our existing customers. The other members of the team are Tim, Robert, Phil, Josh, Glen and Cindy. While I won't personally be involved in the day to day running of Custom D, I'll still be a significant shareholder and a Director of the new company.

It’s early days but the team are up and running in their mission to help you 'rock the boat' in your industry or just do things better online. The new web site is online at www.customd.com, there are new contact numbers and you'll start to see communications from Custom D.

Everyone here is excited about the change - Custom D has that 'start up air' to it, but with the benefit of plenty of work on the books and a team that well and truly know what they're doing.

For the most part it'll be business as usual, but drop us a line or give us a call if you've got any questions...

Cheers
Craig

Proper Printing in WebDirect [Updated]

Fri, 15 Aug 2014 00:00:00 +1200

[Update 26/9/14]

Thank you to some readers who pointed out a few bugs in the example file affecting windows users. The issue was in the "RoboPrint - Process Print Jobs" script. Interestingly, this script runs in the context of a popup window, and we were using a third off-screen window to carry out individual print jobs. When this off-screen window closed, the script focus was actually returned to the main window, not the popup which launched the off-screen window, a bug if ever I saw one! We have modified the example file to explicitly change context back to the RoboPrint popup once processing of print-jobs has been completed. You can download the revised example file at the bottom of this article.

Introduction

For those not familiar with WebDirect think of it as Instant Web Publishing enhanced. Whereas IWP was fairly static, the goal for WebDirect is to be more dynamic and responsive to user interaction. Most FileMaker Pro functionality is there in WebDirect and the overall experience can be made to feel very similar to FileMaker Pro. One of the key features it lacks though is the ability to print reports and this is quite an important feature if WebDirect is to be used as a substitute for FileMaker Pro as a deployment platform.

The implications of no printing in WebDirect

Because the Print script step is unsupported in WebDirect, the only other way to print is through the browsers print function. This however is a very poor substitute as the browser will only print the visible window contents. Any lists of records or any layout that cannot fit entirely in the visible window will not print. Without Preview mode we also have no ability for producing complex sub-summary reports or sliding of records. Basically, it just dun work!

Side note: when we say printing in this article what we really mean is preview mode and all that goes along with that (such as printing).

Okay so it doesn't print, so what can it do?

One thing WebDirect does do quite well is displaying interactive container data. What has that got to do with anything you ask? Well, it means displaying a PDF within WebDirect is pretty nice, so if we could generate a report as a PDF and display that to the WebDirect user instead, then this should allow them to scroll through it, preview it, and subsequently print it via printing of the PDF.

How will we generate a PDF for the WebDirect user?

This is at the heart of the entire framework. Unfortunately FileMaker Server is unable to natively generate a PDF. The only two FileMaker platforms capable of generating a PDF is FileMaker Pro and FileMaker Go. Go is obviously not an option so lets use FileMaker Pro! What we need to do is have a copy of FileMaker Pro responsible for the PDF generation of WebDirect user initiated reports.

This is not an uncommon technique and is something that sometimes is used when reports need to be e-mailed to users on a nightly basis. Because FileMaker Server cannot produce the PDF, we instead call on the help of a Robot copy of FileMaker Pro to do the effort of PDF generation. FileMaker Server can then attach and send the reports via a scheduled script or the copy of FileMaker Pro could just do this itself.

We shall call this copy of FileMaker Pro from this point on RoboPrint !

What is the basic framework outline?

In the framework we refer to the WebDirect user as RoboUser and the robot copy of FileMaker Pro tasked with producing report PDFs as RoboPrint. The basic process of events is as such:

RoboUser initiates a print job
RoboPrint is polling for new print jobs and detects the request from RoboUser
RoboPrint then runs the report on behalf of RoboUser.
The resulting report is saved as a PDF document onto the print job and marked as done.
RoboUser now sees their report has been generated and is able to view the PDF.

That is it in a nutshell. Now how this all actually works is a little more in-depth so we'll cover the process in a little more detail below and how this relates to the example framework file.

... For those who just want to get stuck in and see how it works...

Technical jargon and explanations of how it all works are below, but if you want to just fire up the example file and see what it's all about then you will need to do a few things first:

Example file needs to be hosted on FileMaker Server (because WebDirect is FMS only).
A copy of FileMaker Pro must be running the database logged in with username RoboPrint (no password), and the RoboPrint procedure must be running by clicking the launch button.
In WebDirect open the hosted database with username RoboUser. You can then click on any of the 3 report buttons to test.

If all goes well you should see the WebDirect RoboUser wait for the PDF to be generated. In FileMaker Pro you should see RoboPrint retrieve the print job, process it and mark it as done. Then back in WebDirect you'll see the resulting PDF displayed in an interactive container.

You can also test as RoboUser in either FileMaker Pro or FileMaker Go - this does not require WebDirect to test with. If you do not have access to WebDirect then so long as you can access the database (shared) in 2 copies of FileMaker Pro you will be able to test the demo.

Still a work in progress

This framework at this stage is by no means perfect. It was built out of necessity for a large WebDirect deployment and has so far stood up to the test and been a reliable means of generating reports in WebDirect which is why we have turned it into an article :)

There will always be improvements that can be made to the framework and the intention is that others in the community will take the general method and build upon it for others.

Example File

Please find attached an example file. This file is provided to help you fully understand what is going on in the rest of the article below. Note that FileMaker 13 is required to view this example file.

The example file is intended to be a demonstration of a framework. This is not a modular style implementation currently so to use in your own solution you would recreate the functionality found within the file.

Click here to Download the Example File

The geeky stuff on how it works

Still with us?

Good. You have made it through the first part of the article - congratulations! If you are still here then perhaps you have downloaded the example file and had a look and are curious as to the technicalities behind how it works. It's not that complicated really! Below we'll just cover the basics of the framework so you can feel confident if you need to implement into your own solutions or to make any adjustments or improvements.

The idea of a print job

In the framework is the idea of a print job. Because RoboPrint runs in FileMaker Pro, and RoboUser can be on any platform, there needs to be a method of communication between them in order to convey the type of report RoboUser wants to run, and any criteria around running it. We do this by way of a table funnily enough also called RoboPrint (just to confuse you!).

Each record in this table is an individual print job that is generated by a user for example lets say in WebDirect. The record contains a number of fields that will tell RoboPrint all the information it needs to generate the correct report. Most fields are self explanatory (you can check the comments on the fields for more info).

When a WebDirect user runs a report the script that is run will generate one of these records, populate it with the required information, and sit back and wait until the record is marked as either complete or in the event something went wrong marked with an error.

The request initiation script

When the WebDirect user wishes to run a report the generic script they run is called "Robouser - Initiate Print Job".

We pass 3 key parameters:

Type is a keyword that will tell RoboPrint what type of report the user wishes to run
Parameters is a text string of parameters that may be required to produce the correct report output.
Timeout - this is a period - in seconds - which will be used for how long the WebDirect user will wait for the report output to be delivered. Default is 30 seconds.

The rest of the script will launch a new virtual web window and go to the RoboUser PDF layout. It creates a print job and then simply sits and waits until the process if finished, or expires.

The nice thing about using a new window is that on WebDirect this acts as a 'virtual' window which from the users perspective looks like they have gone to a different page entirely. We can just use an onTimer at this point for the timeout. The user can also click a "Done" button on this screen which will delete their print request and close the window - taking them back to their original layout.

Custom Functions for parameters

The framework makes use of 4 custom functions for managing multiple script parameters and results. It's not terribly important you know how they work, but it is important to know how to use them for script parameters.

To pass multiple parameters to a script we use the SetProperty function. If you look at the initialisation script above it is taking three named parameters. We would pass these to the script in the following format:

The SetProperty function can be strung together with & to pass multiple named parameters.

In the property called "Parameters" , we can nest further multiple parameters here if need be.

The script uses the GetScriptProperty function to parse out this data. This function is basically a helper function that calls the GetProperty function, but will automatically pass through the Get(ScriptParameter) function, saving us having to do this bit.

Finally, GetResultProperty is exactly the same as GetScriptProperty with the difference that it will automatically pass through Get(ScriptResult), so is useful for parsing multiple script results.

RoboUser has sent a print request, what happens now?

RoboPrint should be initiated and running in a copy of FileMaker Pro. This is where print jobs are dealt with. RoboPrint is launched using the script RoboPrint - Initiate Process.

Again a fairly simple script. It takes one optional parameter called Duration. This tells RoboPrint how many seconds it should wait between checking for new print jobs. The default is 2 seconds.

RoboPrint operates in a popup modal window which is completely locked down. We use a loop where processing occurs after the duration pause. The loop carries on forever until the process is stopped.

At each check, the script RoboPrint - Process Print Jobs is run.

Processing print jobs

This script is responsible for checking for new print jobs, and for any found making sure the correct report is run. It is also responsible for generation of the resulting PDF, and any tidyup after that.

I won't go and post a big screenshot of the script here, you can check it out for yourself. The following are key points in the process flow of the script:

It will immediately exit if it finds no new print jobs
Two windows are utilised in processing of print jobs. First is the main RoboPrint window which controls print job processing. The second is a helper window created off-screen. This special window is where the report itself is generated and the PDF is produced. The reason we use a second off-screen window is one of niceness. It ensures that the main RoboPrint window never changes context, and the dirty work of producing the report never gets seen. The helper window is created and used for all print jobs being processed in this batch.
RoboPrint must ensure it can get a record lock on a print job record before it will process it. The reason is that it ensures a user may not be in the act of creating or deleting their print job.
The script will branch off and run a report-specific subscript whose responsibility is to correctly find the report records, set sort order, page setup etc. At this point in the script the $Type variable passed as a parameter is utilised. This is the only part of this script that a developer will need to modify when new reports are added.
At any point in the process if any errors occur, these are marked on the print job record and that job is then considered processed. The user will see that an error has occurred and the reason for the error. Errors can be at the FileMaker level (eg could not produce PDF) or at the report level (user tried to run an invoice report but no invoices matched their criteria...)

Branching to run report specific subroutines

As mentioned above, there has to come a time in this process where a script is run for the specific reports, as each report is different.

You can see this part of the script pictured below. Each print job is tagged with a type keyword that is set into the local variable at the start of the script. Here is where you check the type and run your appropriate subroutine script, passing through the parameters that script will require.

Drinks Break!

How you should configure your report specific scripts

Okay back to it. There are a few rules that need to be followed when you setup your specific report scripts for use with RoboPrint.

Make sure there are no script steps that will pause the script, such as custom dialogs.
Make sure error capture is on - we cannot have any FileMaker dialogs appearing here as RoboPrint ain't gonna dismiss them!
In the event of an error, or a reason why the user can't run the report (e.g. no records, or no access) you should return a script result using the Setproperty function with the property name "Error". This will be set back onto the print job as an error that the user will be informed of.

Once done, your script just needs to exit without error. You needn't do anything regarding PDF generation, that is handled elsewhere, just finish!

Production of the PDF

The Process Print Jobs script is responsible for calling another sub-script to produce the PDF once the users custom report script has been executed. This script is called "RoboPrint - Produce PDF"

The script again is pretty straightforward. We pass it the type of report simply for the purpose of the PDF filename. By default the PDF filename is a combination of the current timestamp as a number, and the report type. This ensures a good chance of a unique PDF filename for the report. You could change this here to whatever you wish the format to be for your solution.

The script will either return an error if for some reason the PDF could not be saved or the path to that PDF on disk.

Finally...

The process print jobs scripts final task is to take that PDF path and insert the PDF into an interactive container on the print job. Once it does this, the print job is marked as completed, and the script will go onto the next print job if there is one, otherwise it is done.

The user has been waiting a while, what are they up to...

As soon as that PDF is inserted onto the print job, the user will see it magically appear in front of them

They will be able to scroll through the PDF and depending upon the browser they are using they will se some PDF controls that will let them print, save, zoom etc..

Print job statuses

We show the print jobs status both on the users screen, and in RoboPrint so that at all points of the process the user is kept notified of the status of their request. Statuses include

Waiting: Print job not yet picked up for processing by RoboPrint.
In-Progress: RoboPrint has got the lock on the job and is now processing.
Completed: RoboPrint has finished and put the PDF onto the print job.
Error: Something went wrong. RoboPrint has put the error message onto the print job.

Some important information on SSL

Certain browsers such as Google Chrome and Firefox have security features that will mean you may notice some unusual behaviour when it comes to the PDF in the interactive content container. These browsers cannot display the content when secure connections to FileMaker Server (SSL) has been turned on within FileMaker Server. The reason is WebDirect will in this case use HTTPS protocol, however external container data will still use HTTP. In the event a secure site has insecure content within it, these browsers will flag it as such and prevent the content from displaying.

What you will see instead is either the icon/filename for the file (which you can actually still right click and export to view) or you will see a link in some cases which you can click to view the PDF.

While not ideal, there are possible ways around this but may involve accepting security dialogs when used first time.

This FileMaker knowledgebase article better documents the issue

Example File

Click here to Download the Example File

Creating New Records in a Portal With a Twist

Thu, 24 Jul 2014 00:00:00 +1200

Introduction

When it comes to creating child records records in FileMaker we have a couple of different options available. The first is to enable “Allow creation of records via this relationship” on the relationship graph. This displays an empty set of fields in the last portal row so that the user can enter data and create a record. The second method is to create a button located outside the portal that creates a new record ready for the user to enter their data.

A new feature that we have been using extensively in FileMaker 13 is the ability to conditionally show and hide objects. In this article we will talk about combining the creation of records in a portal row and the conditionally showing and hiding of objects. This will allow us to create a nicer way for users to create records.

How did this come about?

Recently we built an iPad solution for a local company; whose sales consultants do onsite visits measuring windows for new curtains and blinds. It’s not unusual for the consultants to measure a window that is much larger than the size of available tracks. The consultant can combine up to eight tracks to cover the required window.

We had to come up with an elegant solution that would allow the consultants to specify the number of tracks to join and at what lengths. We also have limited real estate outside of the portal for an add button. What if we could have a button in the last row of the portal that allowed us to create records?

What was our solution to the problem?

Using a combination of showing / hiding objects and allowing creation of records through the relationship we can show an add button that appears only in the last row of the portal. Tapping on this will create a record for a length of track. Once we have reached our maximum of eight records the button no longer appears.

How do we go about setting this up?

First we setup the relationship that we will use for the portal, ensuring that “Allow creation of records in this table via this relationship” is ticked on the portals table occurrence. Next, we define the portal using the relationship that we just setup, adding the fields we want to display into the portal. At this stage the last row will show our fields and allow the user to enter into them to create records.

Hiding the contents of the last row

We can now specify a simple calculation to hide the contents of the last row. We select all the objects that we want to hide in the last row and specify the “Hide object when” calculation to be:

IsEmpty ( Tracks::Track ID )

We could select any field that will have a value auto entered at record creation (eg a record ID). All objects in the last row of the portal with this hide condition defined will now be hidden.

Adding a button for creating a record

We can now add our button for creating records to the portal. We only have to make one small alteration to our calculation we used to hide the contents of the last row. Simply adding not to the beginning of our calculation will have the desired effect. Our calculation now becomes:

not IsEmpty ( Tracks::Track ID )

Creating the record

Creating the record is simply a case of attaching a script to our visible object. The script simply sets a value into the related field creating a record.

Set Field [Tracks::Interface ID; Interface::Interface ID]
Commit Records/Requests []

Limitations

This technique works nicely when you have a fixed number of child records. If you have a large number of child records your users will be continually scrolling to the bottom of the portal to create new records.

Taking this technique to the next level

You could use this technique to hide a delete button that would otherwise appear in the last row of the portal (a technique we have demonstrated in the example file). You could also show labels on the second to last row of the portal to aid users in entering the correct data into the fields.

Example File

Please find attached an example file. This file is provided to help you fully understand what is going on in this article. Note that FileMaker 13 is required to view this example file.

Click here to download example file

Popovers that Open and Close on Mouse-Over

Mon, 07 Jul 2014 00:00:00 +1200

Introduction

In our last article, we introduced a generic technique that could be used to replicate a mouse-over effect. This used a combination of a custom function, script, plugin and tooltips to allow the user to expand and collapse a sliding drawer control without the need for a mouse-click.

In this article we take the technique and modify it to be suited toward opening and closing the popover object upon mouse-over. Popovers are a new feature in FileMaker 13 and are like a balloon tooltip. They are great for revealing additional information on a layout such as actions, information, checkboxes etc (just like a sliding drawer).

If you have not read the the article on sliding drawers, it is recommended you check it out before reading this article, as we'll assume a knowledge of the technique for this article.

Differences between sliding drawers and popovers

In our sliding drawer article, we only dealt with a single sliding drawer on a single layout. The demo was not built for multi-window, multi-layout, or even multi-panel within the same layout. If a user wished to have two drawers on a given layout, then they would have had to replicate the required functionality for the second drawer, hardly efficient!

Popovers fortunately are a little simpler. FileMaker imposes a restriction on a layout that there can be only one open popover per layout per window. The benefit for us is this makes tracking open/closed popovers much easier - we don't have to know which popovers are open or closed at any given time (because only one can be open) we just need to know which one is open on a given window.

Now, in reality tracking open popovers for multiple windows is a bit overkill for popovers. It would be much more important for sliding drawers however. However we have introduced multi-window support in this articles demo file - the same technique could be back-applied to sliding drawers if need be.

The layout setup is very similar to sliding drawers

Because we are borrowing the same technique from sliding drawers, the layout setup for popovers is very similar.

What you are looking at here is a screenshot of the demo file. There are a few components here:

A layout object with a tooltip to initiate the popover. In this case it is clippy!
The actual popover object. We have placed this underneath clippy (more on this later).
The popover panel which will have a nominated object name (in this case "ClipOne").
A large object placed over the layout to close the popover. This will contain a tooltip that calls the HoverPopover custom function, with no parameter passed.

So much like a sliding drawer, our tooltip on Clippy will be used to open the popover, and the layout overlay tooltip is used to close

A little note about the popover panel

There is a little gotcha to beware of here when it comes to the activated popover. Take a look at the picture below:

Here we have highlighted in green an area that sits between the popover panel, and the popover button. We shall call this the dead zone. Within this area you are not in the popover - it is just like regular layout space.

This means that in normal circumstances if you were to place your mouse in this area, then the "Close" tooltip would be evaluated and the popover would close.

This is not desirable because after you place your mouse to open the popover, your normal behaviour is to move the mouse toward the popover. If your mouse crosses this zone the popover will immediately close before you get there!

This is why we don't actually use the popover button as the object that contains the initiating tooltip. Instead, we use the clippy object. The clippy image object is large enough that it occupies this green space, so as the user moves the mouse toward the popover, they remain on the clippy object, preventing the popover from closing.

Unfortunately we have no control over the positioning of the popover panel, it is always in the same relative spot to the popover button, and we cannot close this gap.

Changes to the tooltip custom function

As mentioned earlier, we have modified the custom function that is run on tooltips to be more specific toward popovers. The function now also has some multi-window support built in, so lets take a look.

Whereas in the sliding drawer example we used a single variable $$CurrentState to determine the open or closed state of the drawer, here we are going to dynamically generate and clear variables to determine state.

Each variable is defined on a per-window basis. We are using the current windows name as part of the variable name.

VariableName = Lower ( "$$" & Substitute ( Get ( WindowName ) ; [ " " ; "" ] ; [ "-" ; "" ] ) & "_popover" ) ;

Here we establish the global variable name, removing some common illegal characters that may appear in a window name (more work could be done here).

We next immediately evaluate this variable into a Let variable called CurrentPopover which will tell us (if any) what the currently open popover is.

The outcome to the function is one of three scenarios.

When we need to close popovers

This scenario occurs when we are passed a blank popover name to the function. Recall our layout overlay was calling the function with no parameter. The script responsible for closing popovers only has to be run if there is actually an open popover - otherwise we would be running it many hundreds of times unnecessarily. This is why we also check the CurrentPopover variable to determine if any popover is open right now.

BE_ExecuteScript ( "Popover" ) & Evaluate ( "Let ( " & VariableName & "=\\"\\";\\"\\")" ) ;

The above code is what is run in this scenario. It comprises of two parts. The first is our plugin call to execute our script.

The second part is how we are updating our global state variable dynamically. We use the Evaluate function to clear our dynamically named variable.

When we need to open a popover

This second scenario occurs when we are passed a popover name, and it is determined this is not the one that is currently open by way of checking the CurrentPopover variable.

BE_ExecuteScript ( "Popover" ; Get ( FileName ) ; $name ) & Evaluate ( "Let ( " & VariableName & "=$name; \\"\\")" ) ;

In this case, we are again calling the Popover script, but this time we pass a parameter to the script. The parameter we pass is the popover name passed to the script - the one we wish to open.

The second part is similar to what we do when we close popovers, but this time we dynamically set our variable to the newly opened popover name.

When we need to do nothing

If we need to do nothing, then we do nothing ! This occurs when either popovers are closed and the users tooltip is to close popovers, or when a specific popover is open, and the users tooltip is telling the function to open that same tooltip. In both situations there is absolutely no point in running our script - this would just be a hinderance to performance of the system.

The popover script

This script is much simpler than that for the sliding drawer.

The script is passed a parameter which can either be blank (in which case we close popovers), or it will be the object name of a popover that is to be opened. Depending on the value of the variable, we run the appropriate steps - simple !

Multi-Window

With the additional of dynamic generation of the global variables to manage popover states, we are able to extend this to work across multiple windows. This is a little hard to test given moving the mouse anywhere off a popover area will close it, but for those users who have FileMaker Pro Advanced, fire up the data viewer and check out the Current tab as you move your mouse around the layout. You'll notice state variables being created & cleared instantly. If you open multiple windows then you'll see different variable names being created and cleared also.

The benefit of multi-window support would be far better suited for sliding drawers than popovers, but hopefully this article gives some ideas as to how the drawer file could be extended to be more powerful.

Some limitations and unresolved issues

The file works pretty reliably but there are a few situations that could arise. They are nothing major and will likely go unnoticed, but they are worth mentioning.

The first is the fact that while our script is responsible for closing popovers via tooltips, the user can still close the popover with a click of their mouse somewhere that isn't on the popover button.

If the user does this, then it will not clear the state global variable, so the system thinks the popover is still open. This isn't a huge deal because as soon as the mouse goes somewhere else on the layout, the variable is reset. Other things such as on-timers may cause popovers to clear without clearing their variable, but again these are minor issues.

Example File

Please find attached an example file. This file is provided to help you fully understand what is going on in this article. Note that FileMaker 13 is required to view this example file. The file also contains both windows and mac versions of the BaseElements plugin from Goya, and has been set to install silently on startup if you do not already have this plugin installed.

Click Here to Download the Example File

A Proper Printing Framework for WebDirect

Fri, 04 Jul 2014 00:00:00 +1200

Introduction

For those not familiar with WebDirect, think of it as Instant Web Publishing enhanced. Whereas IWP was fairly static, the goal for WebDirect is to be more dynamic and responsive to the user. Most FileMaker Pro functionality is there in WebDirect and the overall experience can be made to feel very similar to FileMaker Pro. One of the key features it lacks though is printing, and this is quite an important feature if it is a larger solution to be widely deployed to a number of users.

The implications of no printing in WebDirect

Because the Print script step is unsupported in WebDirect, the only other way to print is through the browsers print function. This however is a very poor substitute, as the browser will only print the visible window contents. This means any lists of records, or any layout that cannot fit entirely in the window will not properly print. Without Preview mode, we also have no ability for producing complex sub-summary reports or sliding of records. Basically, it just dun work!

As a note, when we say printing in this article what we really mean is preview mode and all that goes along with that (such as printing).

Okay so it doesn't print, so what can it do?

So how will we generate a PDF?

This is at the heart of the entire framework. Unfortunately FileMaker Server is unable to generate a PDF. The only two FileMaker platforms capable of generating a PDF is FileMaker Pro, and FileMaker Go. Go is obviously not an option so lets use FileMaker Pro! What we need to do is have a copy of FileMaker Pro responsible for the PDF generation of WebDirect user initiated reports.

This is not an uncommon technique. This is something that sometimes is done when reports need to be e-mailed to users on a nightly basis. Because FileMaker Server cannot produce the PDF, we call on the help of a Robot copy of FileMaker Pro to do the effort of PDF generation. FileMaker Server could then attach and send the reports via a scheduled script, or the copy of FileMaker Pro could just do this itself.

We shall call this copy of FileMaker Pro from this point on RoboPrint !

What is the basic framework outline?

In the framework we refer to the WebDirect user as RoboUser and the robot copy of FileMaker Pro tasked with producing report PDFs as RoboPrint. The basic process of events is as such:

RoboUser initiates a print request
RoboPrint is polling for new print requests and detects the request from RoboUser
RoboPrint then runs the report on behalf of RoboUser.
The resulting report is saved as a PDF document onto the print request and marked as done.
RoboUser now sees their report has been generated and is able to view the PDF.

That is it in a nutshell. Now how this all actually works is a little more in-depth so we'll cover the process in a little more detail below and how this relates to the example framework file.

... For those who just want to get stuck in and see how it works...

Technical jargon and explanations are below, but if you want to just fire up the demo file and see what it's all about, you'll need to do a few things first:

Demo file hosted on FileMaker Server (because WebDirect is FMS only).
A copy of FileMaker Pro must be running the database logged in with username RoboPrint (no password), and the RoboPrint function must be running by clicking the launch button.
Fire up WebDirect and open the database with username RoboUser. You can then click on any of the 3 report buttons.

You should see the RoboUser wait for the PDF to be generated. In FileMaker Pro you should see RoboPrint retrieve the print job, process it and mark it as done. Then back in WebDirect you'll see the resulting PDF displayed to the user.

You can also run as RoboUser in either FileMaker Pro or FileMaker Go - this does not necessarily require WebDirect to test with. If you do not have access to WebDirect, then so long as you can access the database (shared) in 2 copies of FileMaker Pro you will be able to test the demo.

Still a work in progress

This framework at this stage is by no means perfect. It was built out of necessity for a WebDirect deployment, and has so far stood up to the test and been a reliable means of generating reports via WebDirect, which is why we have turned it into an article :) There will always be improvements that can be made to the framework and the intention is that others in the community will take the general method and build upon it for others.

The idea of a print request

In the framework is the idea of a print request. Because RoboPrint and RoboUser are run on different platforms, there needs to be a method of communication between them. We do this by way of a table, funnily enough also called RoboPrint (just to confuse you!).

Each record in this table is an individual print request that is generated by a WebDirect user. The record contains a number of fields that will tell RoboPrint all the information it needs to run the report. Most fields are self explanatory (you can check the comments on the fields for more info).

When a user wishes to run a report, they will generate one of these records, populate it with the required information, and sit back and wait until the record is marked as either complete, or in the event something went wrong it will be marked with an error.

The Initiation script

When a WebDirect user wishes to run a report, the generic script they run is called "Robouser - Initiate Print Job".

We pass 3 key parameters:

Type is a keyword that will tell RoboPrint what type of report the user wishes to run
Parameters is a text string of parameters that may be required to produce the correct report output.
Timeout - this is a period - in seconds - which will be used for how long the WebDirect user will wait for the report output to be delivered. Default is 30 seconds.

The rest of the script will launch a new virtual web window and go to the RoboUser PDF layout. It creates a print request and then simply sits and waits until the process if finished, or expires.

A Sliding Drawer that Opens and Closes on Mouse-Over

Tue, 01 Jul 2014 00:00:00 +1200

Introduction

The slide control is an exciting new layout tool introduced in FileMaker 13. Because of it's primary function of sliding via a swipe, it is built with FileMaker Go in mind. However it is quickly finding it's place in FileMaker Pro with a number of cool uses for it being introduced into the community.

The slide control is one of the first UI tools that has animation built into it. The action of moving from one slide control panel to another can be animated (or not animated) by way of script. We can also script the navigation between slide panels. For these two reasons the slide control becomes a good candidate for a number of other UI patterns, one of which is a sliding drawer.

What is a Sliding Drawer

A sliding drawer (also known as a Navigation Drawer) is a control which expands to fill a larger portion of the screen when either pressed, hovered over with the mouse, or swiped with the finger on a touchscreen device. They generally appear on the left edge of a screen, but can be on any edge if desired.

The drawer is most useful when the screen does not have enough room on it to contain further functionality and actions. These can be placed in the drawer and the drawer can be opened when required to give access to the additional functionality.

Here is an example of a website that contains a sliding drawer. The first image shows the collapsed drawer. When the mouse is placed over the drawer, it expands with an animated effect, revealing the full contents. Moving the mouse off the expanded drawer will collapse it.

So what is this article all about?

In this article we are going to build a sliding drawer, but not just any sliding drawer. This is one that will also animated, but also be activated upon hovering the mouse over it. The drawer will also collapse upon moving the mouse off the drawer, just like in the website example above.

The demo file for this article has been in progress for a while now and I had been tinkering with it from time to time but never ready to publish. Recently, there have been a couple of great articles concerning sliding panels which prompted me to get my arse into gear and publish this one too.

One of those was from John Sindelar from Seedcode who published this great article in which he presents an animated sliding panel example. In his demo, the user initiates the slide panel by clicking a button to reveal it, and another click to hide.

This is a great demo for showcasing what can be done with slide panels in FileMaker Pro, how to structure a panel object for this sliding effect, and how can it can be implemented.

I wanted to take this one step further however and remove the need for the user clicking a button to initiate the drawer expanding - wouldn't it be cool if you could just put your mouse over the draw to initiate it, similar to the web?

Wait a minute, did you say mouse-over?

Yes that is correct. The mere act of placing your mouse cursor over the panel will expand it. So how is this possible? FileMaker has no native mouse-over functionality, and in order to expand and collapse the drawer we obviously have to run a script. So how can we initiate a script based on where the mouse is?

The answer is tooltips.

The method we are using to determine where a mouse cursor is on the layout is to place tooltips on the layout. The calculation within the tooltip will be evaluated whenever the mouse cursor falls over the tooltip. This evaluation of the tooltip occurs almost instantly and repeatedly each time the mouse is moved (even though it may still take 1-2 seconds for the tooltip contents to normally appear).

So now it boils down to what we put in our tooltip as to how we can control opening/closing the drawer.

We are in fact also making use of a script-triggering plugin. This plugin will run a script via our tooltip calculation upon detecting we need to either open or close the drawer. But we are getting ahead of ourselves, first things first, lets dive into how it all works.

It may be a good idea at this point if you are following along to download the demo file so you can dissect it all as you read.

Panel Setup

The first part of the puzzle comes with setting up a sliding control. Our control contains 3 panels. The first of which is blank, the second contains the expanded drawer view, and the third blank.

You may be wondering why we have the first and third panels as blank. This is to do with achieving the correct animation effect when the drawer is opened. The correct animation is to show the drawer expanding from left to right. To actually achieve this, we must animate the navigation from panel 3 to panel 2.

The reason our panel #1 is also blank is because unlike a tab control object, we cannot determine the "default" panel to show - it is always panel #1.

In the picture below I have moved the drawer off to the side and shown the dots on the panel for reference. Also note that our collapsed view of the drawer sits outside of the slide control object altogether. The reason for this is a little hard to explain, but it comes down to the speed at which tooltips are evaluated, and the resulting triggered scripts are run. With the closed drawer inside the slide control, we ended up in testing with lots of unusual things happening!

Tooltip that activates the drawer

Let's have a look at the tooltip calculation that is responsible for opening the drawer. This tooltip is set on the green rectangle panel that is the representation of the drawer in its closed state:

Wow how easy is that, only one line of code!! Well, okay maybe not, but as you can see we have abstracted the code into a custom function. The reason for this is re-use. The same code is going to be used to both open and close the drawer. Let's take a look at the custom function.

Still one line, jackpot! The function is passed a keyword - on or off - to determine what action the mouse-event is trying to perform. In this case hovering over the closed panel will attempt to open the panel, so we pass the parameter "On".

Inside our function, we are comparing the new requested state of the drawer, to a global variable we have called $$CurrentState. This variable will contain a keyword that tells us what current state the drawer is on, be it on or off.

If the new state is different to the current (e.g. current state is off, and user wants to turn it on) then the LET statement within the function is executed.

This part will change the $$CurrentState variable to our new state, and then carry out a script called SlidingDrawer which is responsible to changing the drawer state.

Note here we are using the very awesome and free BaseElements plugin from Goya to trigger the script, but you can use any script triggering plugin you want. The demo file comes bundled with the plugin and it should auto-install on startup if not already installed.

A Note on plugin use

Plugins are always something people are naturally skeptical of, but these days plugins are so simple to install in FileMaker that their use should not be seen as an issue. This particular implementation of a sliding drawer is a desktop-only implementation, so a plugin should be fine to use (This method makes no sense on FileMaker Go as there is no mouse).

For WebDirect users, at this point this method will not work as plugins work as long as they are server-side, but our process references a global variable that is client specific so won't work. If anyone wants to work on a WebDirect implementation it would be more than welcome :)

The script to open/close the drawer

The SlidingDrawer script is also pretty simple:

Essentially all it does is turn on the animation effect and go to the required state of the drawer via object name. We have named the on and off panel objects accordingly.

The first script step is a non-animated panel change. This is only required once the first time the drawer is used on the layout. Recall earlier we mentioned panel #1 is always the default visible panel, but that to achieve the correct animation effect we must begin from panel 3. This step ensures that before the animation takes place, we switch from panel #1 to panel #3 if need be. We have named panel #1 "Default" in this case.

Thanks goes to John Sindelar again for this bit of code from his example file, as this was an issue I was struggling with before seeing how he achieved it!

Okay so the drawer is open, how do we close it?

The drawer is closed in exactly the same way as it is opened, via a tooltip. This one however is a bit more of a messy affair. Opening the drawer is easy, we just put the open tooltip on the closed version of the drawer. However closing the drawer will occur if the user puts the mouse anywhere on the layout that is not over the expanded drawer, so how do we do that?

The easiest way - and the way the demo file does it - is to create a large blank text object, and overlay this across the layout with the required tooltip attached.

We define the ordering of tooltip objects on the layout as such so that our closed drawer is at the front, followed by our panel object, and the closing tooltip underneath that. All the other layout objects lie underneath our close tooltip.

You can see in the image above the tooltip object as it sits on the layout.

If you make this overlaying tooltip transparent fill, then a very cool thing happens. If you have other objects on your layout with their own tooltips, then these will continue to work even though those objects are underneath your closing tooltip. But the closing tooltip will still evaluate, as will those other underlying tooltips.

The net result is that your sliding drawer will close, and then any tooltip on any object where your mouse ends up will show.

The only downside to the implementation is you end up with this large object covering most of your layout contents which can make developing a pain. You'll just have to move this object off your layout while developing - but don't forget to move it back on when done or your drawer will not close!

Ensuring the drawer sits in front of everything

One of the limitations of a slide control panel is that underlying objects can still be clicked into and pressed. When our drawer is in its open state, we want to ensure that any layout objects under the drawer are disabled and that the drawer is the only object that can be interacted with within that space.

The solution is quite simple - turn the drawer object into a button. In the example file we use a rectangle object for the open drawer. To set it up you can do the following:

Turn it into a button
Set the script step to "Exit Script"
Disable the option that uses the Hand Icon
Switch to the "Pressed" state of the Rectangle
Change the pressed fill colour to a colour very similar to the normal colour, but fractionally different.

That last point is key. If you set the pressed colour to the same as the normal colour, FileMaker will still add its normal grey pressed colour to the button. We want to give the appearance that this is in fact not a button at all. So to do this, make a minuscule change to the colour, so small a normal user could not perceive the colours being different. Now when the user clicks on the rectangle, nothing seems to happen. In fact the Exit Script step is run, but this has no real effect on anything. Because it is now a button, it will sit in front of all underlying objects, blocking them.

Current Limitations

This specific demo layout has been tested extensively during development, but not much testing has been done at all for other scenarios, such as:

Multi-Windowed environments
Multiple layouts
WebDirect
Multiple panels per page (though this is probably a bad design choice anyway).

The example actually will not currently work with multiple windows as both windows would rely on the same $$CurrentState variable, even though drawers on both windows may have their own state. I do think though this could be quite easily remedied through some tweaks to the custom function and script. Consider generating dynamically named variables for each window, perhaps named using the window & layout name, and then passing the required new state to the script. This would remove the need for the script to reference a global variable, and would mean each layout in each window would have its own variable to control its current state. I would love to see an implementation that does this

Example File

Click here to Download the Example File

Update - New Demo Files from Users

Denis Somar has kindly contributed an awesome modification to the demo file which makes use of popovers to produce the active panel. He noted that popovers have the highest z-level ordering of any object on the layout and thus can be used as the active panel to cover any underlying objects. The demo file he produced works in table-mode and is a very cool take on the traditional drawer, I urge you to check it out! (also check the comments for more information from Denis)

You can download the example file here

Another reader, Joel Shapiro (who did a great article also about sliding drawers using web viewers here) has also contributed a modification to the demo file. His suggestion can be found in the comments, but he noted that by offsetting the slide control 48px to the right (such that it sits to the right of the collapsed panel) the end result is a much smoother transition effect from collapsed to expanded panel. The one downside here is the area occupied by the collapsed panel is not usable when expanded, however I'm sure someone out there will be able to offer up a fix!

Sending Email from FileMaker Using Mandrill

Fri, 21 Mar 2014 00:00:00 +1300

Introduction

Sending Email from FileMaker is a common feature these days. With the Send Mail script step this has made it even easier as you can either send via an SMTP server or your Mail Client. While good, these methods do have restrictions such as a one attachment limit and no HTML support if using via SMTP server. Also if sending via your Email client then it becomes difficult to capture sent mail in your system and not all mail clients work the same.

Developers have aimed to circumvent these issues by using FileMaker Email plugins capable of HTML and multiple attachments among other things. Plugins are a good alternative but require some setup and configuration of SMTP details, authentication, and are at the mercy of firewalls and other restrictions that may prevent Email from being sent.

Mandrill - What is it and why do I care?

What is Mandrill?

Mandrill is different. It is basically the E-Mail sending side of MailChimp that has been spawned off to become its own site. Because of this, Mandrill also offers a wide range of features that you would expect from an Email campaign management site such as tracking of Email opens and clicks, full statistics on mail sent, bounce management, as well as a raft of other customisable settings.

And why do I care?

You can use Mandrill to send Email via standard SMTP, or via their API. Even if you wish to use it just via SMTP alone it makes sense. The Mandrill SMTP credentials are reliable, secure, and work anywhere (subject to firewall restrictions of course). In addition, you get all the benefits of comprehensive email tracking and settings to help customise the experience.

In this article we will be covering sending Email via Mandrill by using their API. The benefit of this method is the Emails are sent using an HTTP POST request on port 80 so unless you work for a totalitarian company which has blocked the internets then you should be guaranteed that your Emails will send every time.

There is always a catch, what is the catch?

No catch I promise! I may sound like I work for Mandrill but my enthusiasm is based solely on using Mandrill now on 4 separate projects and having great success on all of them. Best of all Mandrill is free (now I have your attention!). With a free account you are given a starting limit of 12,000 Emails per month, with an hourly limit of 250.

Mandrill works using algorithms that fairly allocate Email send capacity based on the type and quantity of Email that you send. If you are sending legitimate Email and not spam then you will begin to notice your daily and hourly limits increase over time - though for most FileMaker solutions these starting limits are more than enough.

Setting up a Mandrill Account

How do I create an account?

Go to http://www.mandrillapp.com and sign up for a new account. Account setup is really easy - all you need is a unique Email address and password. If you intend to use it for multiple solutions then it would be good practice to create a new account per solution - 12,000 emails per day sounds like a lot but you don't want to run out. Accounts are also free so there is no reason not to.

Generating an API Key

All Email you intend to send via the API must be sent with an API Key. The key identifies which account is sending the Email. Once logged into your account select SMTP and API Credentials from the settings menu. Here you can create as many API keys as you wish for various purposes. You will also find the SMTP credentials if you prefer to use those.

Configuring your account for use

Mandrill is packed with configuration settings and tools for managing sent mail. These include things such as click tracking, blacklists, whitelists, custom metadata and webhooks to name a few. We won't go into depth on these here, but we will cover a couple of useful settings found in the Sending Options area.

Generate plain-text from HTML Emails (and vice versa). This is a useful option for mail client compatibility. Mandrill will automatically generate either HTML or Plaintext from your Email.
Expose the list of recipients when sending to multiple addresses. You can send an Email to multiple recipients in a single request, however you may not wish for all recipients to know who else got the Email. Use this option to show/hide the full list of recipients from others.
Send a copy of every Email to this address. A great feature for initial deployment. If you are concerned about Emails not being sent, then you can be CC'd in on everything sent using this option, or use it as a secondary log of everything sent out.
Forward bounce notifications to this address. If knowing whether an Email reached its destination is important, you can have Mandrill forward a special bounce response to a nominated Email address. We have used this in solutions where we use a plugin to receive these Emails back into FileMaker and process the bounce accordingly

Integration with FileMaker

What do I need to add to FileMaker

From this point on we are going to refer to the Mandrill example file that is included with this article.

Download the example file

There are 3 key pieces of Mandrill information that you need to put into your FileMaker solution:

The API Key, you can get this from your account.
The URL to which you will send the API request. Mandrill uses a REST API where you send to various URL's your request depending upon what you are trying to do. For sending Email, the URL is https://mandrillapp.com/api/1.0/messages/send.json
The request code into which you will place your email information. Best practice is to define the template and substitute placeholders for actual data.

All of the URLs and request formats for the API can be found in the documentation here. We will be sending requests using JSON format, so we use the .json endpoint to the URL - however other formats are available such as XML and PHP.

You can hard-code the above directly into your send scripts, but a better way is to store them in global fields so they can be used system-wide and can be easily modified if required.

Generating an Email send request

The next step is to transform your request template into an actual request that can be sent to the API. You will see in the screenshot above that our request template has some place-holder data in it at various points, eg. SENDERNAME, SUBJECT, and MESSAGE.

How you record that information in the database we will leave entirely up to you. For our example file we have an Email table onto which we will capture this information. For attachments we have a related Attachments table where each record stores an attachment in a container. It is then simply a case of substituting out our placeholders for actual data. To do this we have created a couple of helpful custom functions.

mandrill_createRequest

This custom function takes a number of parameters, each corresponding to something we will substitute into the request. We are also passing the request template as the first parameter, however if you wish it may be easier to include the template within the custom function, particularly if you only intend to use one template for the entire solution. The function is basically a glorified substitute command, but it does a couple of required things:

It will escape all required characters within the parameters, this is so that the request does not break as a result of prematurely terminated strings caused by a non-escaped characters.
It will call a helper custom function mandrill_attachmentCode to generate the required request code for attachments.
Because we are sending all Email as HTML, it will transform the message into HTML code using the GetAsCSS function if it detects it was not passed HTML code already.

EDIT: Thank you to Tim Dietrich, Stephen Dolenski and Michael Gaslowitz who all pointed out we also need to escape other characters in the request so as not to break it!

mandrill_attachmentCode

You don't really need to concern yourself with how this function works, however it is such a cool function function it deserves some mention!

Custom functions can accept a container field as a parameter. However you cannot pass them a list of containers as the List() function is for strings only. We could define 1 parameter per attachment but that is really bad as a) we don't know how many attachments we will have, and b) if we have none or one then we have to define blank for all the other attachment parameters. So how do we process multiple container attachments with a single parameter?

The answer to this came from this Soliant Consulting article written by the very smart Wim Decorte. He noticed that a parameter to a custom function has a dual nature - you can either treat it as a normal value, OR you can treat it as a reference to a value. Basically, if we treat it as a reference then we can use it in conjunction with recursion and the GetNthRecord function to recurse through multiple related attachment containers and process each one. We are making use of the dual nature of the parameter, using it as a both a value and a reference. I think this is one of the coolest untapped features of custom functions!

Attachments are converted into Base64 and along with a file name and mime type are put into the correct request format.

I won't go into any more detail than that, feel free to dig deeper into how it works, and definitely check out Wim's great article on the topic.

Enough with the stalling, send the damn Email already!

This is the easiest part. Now that we have our request generated from the custom function, all that is left to do is send it to the API to send the Email.

The Insert from URL script step may be able to be used to send the request. At the point of writing this, I am still working on determining whether this is possible, and seeking the help of fellow developers in getting this working with this script step. In FileMaker Pro 13, the step does support HTTP POST, but I'm still working on getting the syntax correct for sending. For now, we are going to use the BaseElements plugin to send the request. Thank you to Michael Gaslowitz for pointing out that Insert from URL does support HTTP POST.

The example file comes pre-packaged with the excellent and free BaseElements plugin from Goya Pty Ltd. This should auto-install on startup and prior to sending Email if not already installed. We use this plugin because not only does it have a working mac and windows version but it also has a 64-bit windows version compatible with FileMaker Server 12 and 13 for server-side sending.

Because plugins do not work on iOS you have a couple of options - one is to have FileMaker Server carry out the sending by using the Perform on Server script step. If your solution is not hosted then you can use the native FileMaker Send Mail script step and use the Mandrill SMTP credentials instead of the API. We are also working on getting the Insert from URL step working (see above).

Sending the request is now really easy and is a single function call:

BE_HTTP_POST ( $URL ; $Request )

Where $URL is the API endpoint for sending an email, and $Request is your completed request. Sending of a standard Email without attachments should take less than a second, and a little longer for attachments.

The API Response

After sending the request, the API will send you a response that contains useful information. A typical response will look something like this:

[<br />{"email":"daniel@weetbicks.com",<br /> "status":"sent","_id":<br /> "d54bb019417c491eb01fc8578c4641a5",<br /> "reject_reason":null}<br />]<br />

This is a JSON array of values of the following:

email. Where the e-mail was sent
status.This tells you the outcome. If the status is sent or queued then it succeeded. Emails without an attachment will send right away, whereas ones with an attachment will be queued - however they are typically only queued for a couple of seconds so you won't even notice. A status of scheduled means you have told Mandrill to send the message at a nominated date and time (you can define this as part of the request). If the status is rejected or invalid then something went wrong, and you can check the reason for more details
reject_reason. The reason the Email failed to send if the status is rejected.
id. This is a unique identifier assigned to the sent Email from Mandrill. This is useful to track the message via the online Mandrill dashboard, and also if you intend to process Email bounces (the bounce message contains the unique ID).

mandrill_parseResponse

We have included this custom function to help you easily obtain a specified parameter from the response. Pass this function the response, along with either the parameter keyword (or associated number) to retrieve the value. This is useful if you wish to run a test condition as to whether the email sent or failed.

So in Conclusion...

We hope this article has given you a good overview of Mandrill, what it is and what its benefits are. Integrating Mandrill with FileMaker is dead simple. It avoids a lot of potential SMTP related issues such as firewall restrictions, Outlook Exchange problems, or simply increasing usage of your own SMTP server. It also contains a wealth of settings and tracking options for marketing/campaign related emails. We haven't even touched upon the comprehensive online dashboard for tracking sent email statistics, but it's all there for you to explore. Have fun!

Example File

Please find attached an example file. This file is provided to help you fully understand what is going on in this article. Note that FileMaker 13 is required to view this example file. The file also contains links to the Mandrill API documentation and website, as well as the custom functions mentioned in the article.

Download Example File

UPDATE:The example file has been updated on 23rd March with the following changes:

More escaping of request characters within the mandrill_createRequest function
added a mandrill_escapeData helper custom function to escape merge data in the request
I have replaced angle bracket for merge data with « and » respectively.

Cutting out the middle man

Thu, 13 Mar 2014 00:00:00 +1300

As an account manager, my job is to look after new and existing clients, with the end goal of keeping them happy. My role is also to keep our developers busy with work, a busy development team makes for a happy workplace.

What has changed between my previous job and now (at Digital Fusion) is we have cut out the middle man. Previously it was my role to sell websites, pass the client to a project manager who would then form a team and oversee the design and development phases. Once I had handed the client over, I pretty much dropped out of the equation, coming in at the end of the project to give the client some love and to check that everything went well (with fingers and toes crossed).

This was described by my previous manager as a 'touch and pass' method, the Account Manager would 'touch' the client and then 'pass' them onto the project manager. As Account Managers we called the 'touch and pass' method more the 'dump and run' because invariably we had to move onto our next sale so we could keep the cogs moving.

After joining Digital Fusion in late 2012 it was interesting to see how our model works, and I have to say it is fantastic. Here my role is more of a Relationship Manager, I check in with clients and developers and make sure they are all good. As our designers and developers manage all our projects, they are intricately involved. Clients love the fact that they are working directly with the people who are working on their projects, there's no having to explain something to a project manager and hoping that the message gets passed on to the unknown designer or developer. I am always there to support the clients and developers with the comms side of the project, keeping things ticking along is important.

I will add here that I think we are blessed with an outstanding team, people who are more than capable of running projects and being a part of our clients businesses. This is credit to Craig and Julie that they employ staff incredibly well, there's not a dud one in the bunch of now 16 staff (and yes I include myself in this figure, they picked well when they employed me).

So what's the upshot of this blog post? There are really two take-aways, one being how you employ your staff: look for well-rounded people that are passionate about what they do ? and can speak human language, not just geek speak. The other is to not put barriers between yourself and clients, keeping the communication channels as open as possible will lead to happy clients.

So what is an API and why should you care?

Wed, 19 Feb 2014 00:30:00 +1300

Quite simply, an API is a purpose built extension of an existing system to allow information to flow back and forth with other systems.

Who cares? You should... because API's are a simple and cost effective way for your website or application to communicate with other pieces of software.

The best way to get your head around what an API is, would be to use an analogy:

Your television set has an HDMI socket (or many), this allows you to plug devices into the television so you can get information into and out of it (think Sky Decoder, Apple TV, DVD recorder etc). Think of the HDMI socket as an API, without it you would have what is best described as a 'dumb' television, you can watch programs but you can neither watch DVD's or record programmes.

Software is the same, you can have a closed solution which doesn't 'speak' to other pieces of software, or you can have an 'open' solution which can communicate via an API.

To give you an example of how an API works in the wild, we will use our good mates at xero.

One of the best features of Xero is the automated population of transactions from your bank. To allow Xero to do this, the banks have developed API's that give Xero the ability to pull information out and display it in their system. The other cool thing about Xero is they have then taken it a step further and built their own API, which means web developers like us can then build solutions that either push or pull information into or out of Xero.

Big Tabs!

Thu, 13 Feb 2014 00:00:00 +1300

Introduction

Building FileMaker solutions for iOS introduces a new set of challenges for developers and requires UI controls that make it easy for users to interact. This article gives a very quick and simple technique you can use to make selecting tab controls much easier for FileMaker Go users on iPad and iPhone.

Tab Controls before FileMaker 13

Prior to FileMaker 13, the labels you define for tab panels would be the only means of dictating the height of those selectable tab panel areas. Increasing the font size inevitably increases the height of the tab panels selectable area.

The problem here is that with increased font size comes unreadability of the tab label. Various methods could be employed to inhibit this behaviour such as making the label white to hide it. Another method people have used is to set the tab label to a series of space characters and then overlaying the actual label as a standard piece of text. Neither method is that elegant or easy to maintain.

The solution in FileMaker 13

With FileMaker 13, we can now define the labels for tabs by way of calculation and as such we can make use of some of the text formatting functions within that calculation.

To retain big tabs but allow for readable labels, we can use the TextSize function to reduce the label size to a readable level, while making the font size associated with the tab control object large.

Here is a tab control where the tab font size is set to 72pt. By doing this, the selectable tab area height is increased.

If we look at the tab setup, you'll notice all the tabs are defined by calculation. I have also set tab width to a fixed width per tab (choosing the other options tends to not work nicely with this technique).

The tab function is simply a custom function that will correctly format the label to a desired size - this is purely for readability.

The End Result

When viewed in browse mode, we end up with some really nice tall tabs with a readable font size. On an iOS device this gives a much larger area to tap for selecting a tab.

Compare this to a tab control based on the standard font size of 12pt.

Example File

Please find attached an example file. This file is provided to help you fully understand what is going on in this article. Note that FileMaker 13 is required to view this example file.

Download Example File

And Finally...

It has been just over a year since my last article. in January of last year I set off and spent 5 months cycling across the African continent. Upon returning to work the motivation for writing new articles wasn't quite there and it took a while to get back into the swing of things. Now it is a new year and I'm looking forward to cracking out some new articles in 2014 and explore everything that FileMaker 13 has to offer!

Thank you for your continued readership and support!

Cheers,
Daniel

Weetbicks Returns

Thu, 13 Feb 2014 00:00:00 +1300

We're rapt to announce that Daniel has returned to the keyboard to share some of the expertise and methods gleaned from the real world development work we do here at Team DF.

Daniel's new article looks at a solution particularly useful in iOS development where everything needs be nice and big and easy to target when a finger is the pointer ? check out Big Tabs.

FileMaker 13 Hits The Streets!

Wed, 04 Dec 2013 00:23:00 +1300

Wahoo! A new release of the venerable database platform, FileMaker, is out today.

For software developers a new release of one our main tools of the trade is like Christmas... and look at that it *is* December already.

With a new version like this we get some all new superpowers to make our solutions more impressive, faster, and of course, better looking. There are some really important things too, like security, encryption, and new server admin tools with graphs showing how many bits are bobbing around between the clouds, the people, and all those 'mobile devices'.

Lovely. So what's in it for me?

Well, if you're a business owner or manager or someone just trying to make life better with some decent 'systems' then FileMaker 13 brings some major new possibilities for you, especially with WebDirect and a lot of enhancements to the mobile version, FileMaker Go.

So here we go with a bit of a run down on the highlights:

WebDirect

This is the biggy: it's FileMaker to web without getting down and dirty with HTML, JavaScript or PHP... Not that we don't like that?in fact we love the power of the web as a platform too, but sometimes you need the job done quickly and don't need all that power.

I reckon there are 2 ways to look at it:

You can think of WebDirect as a way to access FileMaker solutions from a web browser. Yes, that means you don't have to license and install the FileMaker application on everyone's computer!

WebDirect used this way is ideal for people who don't need to work within a FileMaker system all day, every day. The FileMaker Pro application is still more powerful and does some things a lot better, like printing and producing PDFs. But for occasional users or people who only need to do a few specific things in the database, then this is an easier way to get them onto it.

You can think of WebDirect as a low cost way to provide a 'web app' for people outside your organisation, say your clients or contractors, to interact with you.

Whichever way you look at it, WebDirect is revolutionary and there's honestly very little, if anything, out there that's comparable.

Slick New Interface Widgets

FileMaker 13 brings quite a few new ways to make better looking and easier to use screens. Behind the scenes we've got a lot more control over how things look and behave too, with styles, customisable themes, and visibility control (so we can hide the sh*t you don't need right now).

More obviously though are the two new types of control: Pop-overs and Slides... these are very web like and add to that 'liveliness' feeling when you're using a system.

Pop-overs bring up more information or options without having to open a new window or dialog box. They help keep things uncluttered while having more detailed information or additional options easy to access without going to a different screen or new window.

Slides come from the mobile world, and in FileMaker Go (the iPhone and iPad version of FileMaker), they work by swiping left and right to move between slide panels. Slides help you access more information or move to the next step, without having to leave the screen you're on.

Licensing

You might also be interested to know how FileMaker Inc intend to make money from this if you can use a FileMaker solution from a free web browser now?

Sadly although owned by Apple, which has more money than God, FileMaker Inc. is required to keep its head above water all by itself, so there's a new licensing system:

Basically, to connect the free clients (WebDirect and FileMaker Go) you'll need some concurrent connection licenses for your FileMaker Server. The more you have, the more WebDirect and FileMaker Go licenses you can have on the system at any one time.

What else do you need to know?

Well, we'll be going more in depth in our FileMaker blog to look into the new stuff, and how to use but I will also add that there's a lot you don't see like speed improvements in both Server and FileMaker Go, and ongoing development of things like the backup process, SQL engine and 64-bit capabilities.

In fact one thing to note is that because of changes to the SQL in FileMaker we're releasing an update to our Reactor plugin (that does Calendars, Gantt charts etc) in the next few days?so keep an eye on that over at Fusion Plugins

We're rapt to see the FileMaker platform embracing the web and mobile spaces even more, and as always maintaining its place as one of the fastest and most robust ways to build database solutions there is.

Drop us a line or fire questions at us via this blog and we're more than happy to fill you in on the finer points.

Xerocon - If only I could come up with a better blog title

Tue, 20 Aug 2013 04:55:00 +1200

Next week three DF'ers are heading to Xerocon in Sydney. As first timers we thought we better make a bit of a splash so have been putting our 'thinking caps' on and have come up with a bit of a competition (of sorts)

Our tag line for the conference is 'If only?.' which forms that basis for our booth and speech. The idea behind the tag line stems from our custom software development heritage, we develop solutions that are tailor made to you or your clients needs. This might be along the lines of developing a shopping cart that integrates with Xero, a database that invoices via Xero or the big bertha, a database and website and Xero, all interlinked.

So back to the competition, we want to hear what 'If only?..' you can come up with. Some of the ones we have tossed around are 'If only?I had bought my Xero shares two years ago' or 'If only?.there were more beans to count'. We want you to put your 'thinking caps' on and and come up with some equally fun sayings. The more topical to Xerocon the better.

If we like your idea and contact you via Twitter, come see us at the conference (Booth 33) and pick up a t-shirt.

While you are there, you can enter the draw to win an iPad mini.

Remember to hashtag your idea with #xerocon

Xero Makes It Big In Australia

Tue, 16 Apr 2013 10:41:00 +1200

Earlier this month we saw the results of Xero's continued growth, particularly the increase in users in Australia. With a growth rate of 219% for the year, we are starting to see that businesses in Australia are really getting behind the products (32% of all users are Australian based). We are also starting to see some of the unique requirements that go with using the solution in Australia.

By nature, Australian businesses are typically larger and have a focus not just on business in Australia but also into the Asian region. They are also a number of years ahead of New Zealand businesses in terms how they expect to integrate other parts of their IT solutions into Xero and finding solutions that will save them money and time. This might be via shopping carts, CRM's or payment gateways but each have their unique requirements, particularly taking into account the need to transact in foreign currencies.

As Digital Fusion have an office and staff in Australia and a large part of our business comes from there, we understand the needs better than most and are able to put our experience to good use when it comes to website or database integration.

We have a number of projects on the go at the moment where we are integrating large scale development projects (both web and FileMaker) into Xero, in multi currencies and multi sites. One of the good things about this is our level of experience grows with each project and we like to think we are at the forefront of Xero development and integration in Australia.

We use Xero ourselves so we understand the need to make it work for you. As with all things, we are keen to discuss what solution you require and how we can help. Do send us an email or give us a call.

On the Right Track

Thu, 07 Mar 2013 17:06:00 +1300

We recently finished an iPad solution for Canterbury Track Cycling using FileMaker Go. Known as RacePlace, it records the results of their club racing, championships and special events and integrates smoothly with the website we built for them at the end of last year.

There are lots of nifty mobile apps out there, but there are a few things that make this one a bit different, mainly that we've used the mobile version of FileMaker - FileMakerGo.

Why use FileMaker Go?

Using FMGo makes development fast... and fast in the world of custom software equals affordable
The solution can also be used offline (no internet connection) or online making results uploadable to the website in real time as race meetings are in progress
Anyone with an iPad can record the results which means the organisers are not dependent on any one person to ensure results are published in a timely fashion

If we'd a approached this project using web technologies (HTML5) the solution would have to be connected to the internet to be used fully, thus restricting the recording of the results to those with a 3G iPad.

The iOS (native app) platform was also an option, but the cost would have been much greater and speed of deployment inhibited. Approval from the App Store would have been needed before release of the initial version and any subsequent iterations.

All this means FMGo is a very viable alternative for SME's looking for a mobile solution to help run their business?something that may not have been an option in the past.

Gone Wild

Tue, 01 Jan 2013 15:26:00 +1300

Weetbicks, our FileMaker development blog, is well known within the FileMaker community. Daniel's articles help other developers with ways to work around sticky problems. But in the last two months, the FileMaker Weetbicks blog has dried up a little ? Daniel has gone M.I.A.!

Fret not friends, Daniel is safe and sound in Ethiopia. He's part way though an epic cycling journey that started in Cairo and ends in Cape Town. That's a staggering 12,000kms through 10 of the world's hottest countries. We think he's CRAZY!

His blog of adventures has given us an insight into the heart of Daniel and Africa. While you're sitting there drinking your coffee, reading and laughing at Daniel's situation, consider giving a little to the Heart Foundation. He's riding for them and has set a target of $12,000 ($1 per km). Skip tomorrow's coffee and donate that $5. Every little bit helps. One Man. One Bike. A Whole Lot Of Heart.

Miami Nice

Tue, 11 Sep 2012 15:17:00 +1200

In the cold of July Daniel, Julie and myself packed our skimpiest summer gears, sprayed on the tan and headed to body-beautiful Miami? OK it wasn't exactly like that, but it was hot hot hot and the hotel Fontainebleau was a classy venue, right on the beach.

The real reason we headed to Miami was of course the annual FileMaker Developer Conference where over 1200 of the best developers from around the world gather to indulge in all things FileMaker.

So what did we indulge in? The odd cocktail may have been consumed, but DevCon is most definitely a geek?fest so invariably the conversation is very technical. I won't bore you with the details but suffice to say there was plenty of knowledge to be shared and great ideas gleaned.

The real value of attending a global event like this is the chance to get a sense of where things are going and to be inspired by seeing some of the amazing things others are doing? like a Japanese solution for dental surgeons where you draw on a patient's teeth using an iPad. You draw on the iPad I mean.

Out There

This year the overwhelming sense was that "mobile" is really taking off in business, and that means iPhones and iPads finally getting down to some serious work?

This is a tectonic shift in how technology is used ? it's a whole new game. You can now empower anyone in a workplace with a computer, camera, GPS and mobile internet connection, and all disguised as nothing more than a flashy phone.

Not surprisingly then DevCon 2012 featured a number of sessions on developing specifically for mobile devices, from user interface design to performance enhancing magic.

Another hot topic is "location awareness" ? an iPhone or iPad can know which job you're on if your work is location based so why not automatically bring up information about that job? (Of course it also knows when you're at the pub and could potentially log that too?)

Faster, Pussycat

Behind the commercial needs are the technology challenges, and what we saw at DevCon was that speed is the big one which everyone is tackling head on.

For a start if you're mobile, you can't count on being connected to the mothership so there was a lot of discussion about synchronizing data, whereby database records are copied onto the device so it doesn't matter if cell reception is crap. Things work much faster this way too, so it's a better experience all round.

But you also need to get connected and store everything centrally, so there were sessions on optimizing databases for "WAN" (over the Internet) performance. Engineers and product mangers from FileMaker Inc made it clear that performance, particularly over the internet, is a huge priority for them going forward.

New Interfaces

And what would a geek conference be without some new technology? In FileMaker 12 it's the new 'CSS' web technology that gives us the ability to make much better looking screens, that feel contemporary and dynamic, just like the web kids do.

Alas it's also still very easy to mess it up, so to go with the new tools there were sessions on User Interface design and Usability, including a great lecture by Heather Winkler who is head of UI at FileMaker Inc. In fact there were a lot of sessions from FileMaker staff ? a lot more than before, and really good to see because they're often able to give us a whole new level of insight, after all they know what's going on 'cause they built the product!

Aside from the sessions and discussions, cocktails and beers, awards (see Mad Dog Daniel Wood) and nice dinners, we got to spend time chewing the fat with the FileMaker engineers and product managers. We were rapt to hear the way they're talking about FileMaker as a platform now, for business innovation, embracing 'app' development and looking well out into the future. FileMaker 12 is a foundation version and opens the way for some very cool stuff to come yet.

Right, so get back to Silicon Valley people and get to it, please.

Out of the Wild

Tue, 11 Sep 2012 15:17:00 +1200

Apple released its new operating system, Mountain Lion, a couple of weeks ago. As it is always a good idea to test new software before deploying it to all computers in a business, we tested it on a few computers, just to make sure not to run into serious problems.

However, Mountain Lion (OS X 10.8) held up to the excitement one could find in the Apple fan community prior to release: it is more stable, quicker, uses less resources and altogether makes a far better impression than its predecessor Lion (OS X 10.7).

Although Apple mainly indicated that this upgrade is a minor one - like before with the step from Leopard to Snow Leopard - Apple addressed not only performance issues, but also made a significant amount of changes to the system. I will give you a quick tour through some of the more noticeable changes now.

What is new for users who had Lion installed already:

You will find a notification column on the right now, which might look familiar if you are using iOS 5 on your iPhone or iPad. In this column you can find info about new emails, incoming chats, calendar events and everything else your computer wants to tell you.
Safari got an overhaul and is apparently much nicer and smoother to use now. There is only one address field, which also serves as google search bar - Chrome users might recognise this. Also there is a new 'Share' button, which lets you share pages via mail, messenger / ichat, Twitter, Facebook?
Apple made some minor improvements to the launchpad, mouse-gestures and some other stuff like notes and reminders.
iChat is now Messenger! If you are used to iChat thhe new Messenger takes a bit of getting used to - but it is worth it! The history function that keeps past conversations accessible can be very helpful, although it is harder to check who is online. However, you can activate the 'old' buddy list through the menu and enjoy the new functions without loss.
Software update is now completely integrated in App Store. This can be a little bit of an issue when multiple users install software with different Apple-IDs, but important system updates will be unaffected and work fine.

Coming from (Snow) Leopard, there is MUCH more:

Additional to all the stuff above, you will notice that your mouse scrolling now works the other way round. It needs a bit getting used to it, but once you adjusted it is actually quite nice.
Mail got an overhaul with grouping emails in a nice way and some smaller changes here and there. Altogether a plus in my opinion!
The Application starter from the task bar is now called Launchpad and looks more like iOS. I don't like it that much, but it might be a question of taste?
ExposÃÂ© (the multiple desktop system) is now called MissionControl and is combined with the 'show all programs' (function key F3) button. This is quite an improvement, and if you have a magic mouse or a touchpad, you can easily swipe between screens with two fingers.

There are quite a few more changes, I guess, but I can't remember all of them. So just do the upgrade and enjoy.

Just a little warning at the end: the upgrade takes about an hour (not including the time to download the 4GB image from the App Store) and Spotlight will reindex your computer in the first hour or so after login, which makes your computer react a bit slower than normal. However, once this is completed it should be as fast as ever - at last!

Daniel 'Mad Dog' Wood

Wed, 18 Jul 2012 15:00:00 +1200

Our very own Daniel Wood has just been awarded the coveted Mad Dog PR Award at FileMaker DevCon 2012. The award recognises developers who have made a significant contribution to advancing the awareness of FileMaker in the media and community.

Weetbicks Trivia 1.0

Tue, 03 Jul 2012 14:30:00 +1200

Introduction

A little while ago I received an e-mail asking for ideas on how to implement a multiple choice testing database. It just so happens that I had begun to build a database a few years ago which does just that. While it is not finished, I have decided to release a first version for people to download, dissect and use.

Weetbicks Trivia

This database was built around 2008 and the original purpose behind it was to create a trivia database that could be placed on a FileMaker Server and where the database users would be able to take quizzes to test their knowledge in a range of areas - mainly FileMaker related. It was to be built up to be a nice certification training tool, or just to brush up on FileMaker knowledge.

However other things got in the way and it was never finished. The toughest part was simply coming up with numerous FileMaker related questions. As with a lot of projects, the motivation disappeared and it sat around on my hard drive for years unfinished.

Revival

With an e-mail received recently asking about this type of database structure, I decided to brush off the database, give it a spruce up for FileMaker 12, and release it here for anyone to download.

Hopefully if there is enough interest in the database I will continue to finish it.

Currently it only contains a practise mode where you can choose one/all categories of questions, and you are presented with question after question until you can take no more testing :)

Future Versions

The plan has always been to make the database quite comprehensive and have different gameplay modes such as:

Beat the Clock: X questions in Y minutes as a quick-fire mode, kind of like the certification exam.
Challenge: Pit your knowledge against another user by challenging them to a test.
Tournament: One or more database users enter into a longer format challenge which can span multiple tests over multiple days to find an overall victor.

Stay tuned for future releases. The plan is to release a new version once enough new functionality is added, perhaps one mode at a time.

Download

Download Weetbicks Trivia 1.0

Any feedback, comments, bugs, suggestions etc are very much appreciated, thanks!

Sweet Scrolling in FileMaker Go 12

Mon, 14 May 2012 18:06:00 +1200

Introduction

Portal scrolling has always been a bit of a struggle in FileMaker Go up until the release of version 12. This article outlines some of the changes to portal scrolling in FileMaker Go 12 and we give a couple of examples how it can be set-up to give a very nice native-application look and feel. We also cover field scrolling.

Getting that Native-App look

If you look at any regular application on the iPhone or iPad you'll notice they all have very similar looking scrolling. This is typified by a thin grey bar to give a visual cue as to where the scroll position is - yet there is no actual scrollbar present.

In these applications the scroll indicator is close up to the right edge of the screen. You'll notice it can even slightly overlay some of the contents, as if the scroll is floating on top of everything else. This is what we are going to try and replicate for our FileMaker Go layout for iPhone.

Our iPhone layout design

So below we have a layout that we have designed to be used on an iPhone running FileMaker Go 12. This layout mostly contains a portal and as you can see in the image, we too have a little grey scroll indicator up to the right edge of screen.

You may be asking yourself why we didn't just use a list-view layout as opposed to a portal - surely that would have been easier. There are a couple of reasons why we chose not to:

We do not wish for our context to be that of the portal (or a list-view layout).
Portals have a tendency to render much faster than records in list-view. This means they feel much more like a faster native application, and we don't see so much blocky rendering happening.
Portals in FileMaker Go 12 no longer require to be clicked into before you can begin scrolling which was the case in FileMaker Go 11. This means they are actually usable now!
With a portal you get a nice left-edge of the screen without the list-view thin bar you get to indicate current record.

If we look at the layout in layout mode, you can see how this effect has been achieved.

What we have done is to simply place the visible scroll-bar portion of the portal off the right edge of the layout. This means the visual scroll bar never appears on-screen but the grey scroll indicator does given that it is appearing to the left of the scroll bar - the area of which is still on screen.

It is a very strange thing that portals in FileMaker Go 12 should even render with a scrollbar at all - they are completely useless and do not actually serve any functional purpose as we shall see later. Good thing we can now hide things off the edge of the screen!

What about scrolling within a layout?

Scrolling when the portal extends to the edge of the layout is fine because we can simply hide the scroll bar off the edge of the layout. But what if we have a portal we want to scroll that is contained within the layout too far from the edge to be hidden?

Let's consider the screen above. In this case we have a portal that is not touching the edge of the layout. Never fear! We can still achieve the same desired effect with a little jiggery pokery.

But first...

Before we show how this effect can be achieved let's investigate why a regular portal is a bad idea to be used on-screen in FileMaker Go 12 for scrolling.

Here we have a typical portal displayed within the layout shown in both browse mode and layout mode. We have some rounded corners on the portal because the desired effect is to show a rounded white box on the screen with the records within. The scrollbar is clearly visible for all to see.

Now, what do you suppose would happen if the user began to run their finger up the portal to scroll? Well, it's a scrollbar so you may expect it to look how it might in FileMaker Pro, surely.

As soon as the user begins to scroll, the scroll bar disappears entirely! This leaves no right edge to the portal which means it no longer has rounded right edges. The grey scroll indicator you can see is still present aligned to the left of where the scroll bar used to be.

In this above picture, the user has stopped scrolling, but the scroll bar is still nowhere to be seen. In fact, the only time the scroll bar appears is when the user is not in the portal. It can be made to reappear when the user clicks elsewhere on the layout - but when it appears it is simply a scrollbar with no actual use. We should just get rid of it entirely!

Hide the scrollbar by covering it up

We've all done this in FileMaker development at some point or another - cover up layout objects with other objects. Fortunately in FileMaker Go 12, if you cover just the scroll bar part of a portal with another object, the scroll bar will never appear, or jump in front of it's overlaying object, so it is quite simple to hide them.

Here we have placed a graphic over top of the scrollbar. It should be noted here that because the portal scrollbar constitutes the right-edge of the portal, then with it disappearing we no longer have a rounded right edge to display. To remedy this, we have made the portal transparent, and placed a rounded rectangle beneath the portal instead.

It does not matter where the portal scroll bar is positioned so long as it can be overlaid. In this case we wanted to get the scroll indicator positioned in such a place that means the scroll bar is part-on and part-off the layout. This is no problem however.

Scrolling of text fields

The next challenge we encountered with scrolling in FileMaker Go 12 came when we tried to scroll a text field on the layout. In FileMaker Pro 12 if you want to scroll a text field you put a scrollbar on it, click into the field, and then begin scrolling. Unfortunately it's not so easy in FileMaker Go 12.

Here we have a field on the layout. Note we have no scrollbar. The reason is that once the user is clicked in the field, they can scroll whether there is a scrollbar or not, so it is again kind of a redundant artifact to be showing on a field.

So, here is the field in browse mode showing lots of text, too much to see on screen at once, so we really want to be able to scroll. Let's try clicking into the field ala FileMaker Pro 12.

Problem! in FileMaker Go 12 when you click into a field, it automatically reveals the keyboard in anticipation for input. It does not know that we merely want to view and scroll the information in the field, not edit it! We don't want to show the keyboard every time we want to scroll, nor do we want to have to click into the field to begin scrolling. It would be nice if it performs like portals do.

Web viewers to the rescue

One solution to this issue we found was to use web viewers instead. In FileMaker Go 12, the web viewers exhibit a nice scrolling experience much the same as portals. Also they do not reveal the keyboard because there is no field to click into.

The one difference between web viewers and portals however is that a web viewer must be clicked into and given focus before it will scroll, it does not register scrolling automatically. We can overcome this however through using some script triggers, more on this below.

In order to display the fields contents we are using a Data URL. This allows us to render text in the field directly via the web viewer without the need for plugins - which are not compatible with FileMaker Go anyway.

The end result is quite nice. To overcome the fact the web viewer has to be in focus to be scrolled, we are ensuring that when we go to the above particular screen, we go directly to the web viewer through a Go to Object script step. By arriving at this screen directly in the web viewer, the user can begin scrolling right away.

In the picture above we have used data:text/plain as our data URL scheme which gives the font in courier. This lets the text automatically wrap itself to the edge of the web viewer so we have no side-scrolling required to view all of the text. We are sure there are always to alter the font and retain this behavior but have not investigated this further.

Because in this solution nothing is editable, the user has no reason to leave the web viewer unless they choose to via one of the navigation buttons. To keep the scroll alive, we put a simple little script trigger on the web viewer for the onObjectExit condition.

Whenever the user attempts to leave the web viewer, they will only succeed in doing so if the parameter to the script is non-empty. Because we are passing the current script name as a parameter - it means the user will only be able to exit the web viewer if navigating away from it via script. If they manually attempt to click outside of the web viewer - e.g. on the layout - then this will fail and they will be kept in the web viewer. Because all of our navigation is from scripts, this ensures that when a script tries to navigate the user away from this screen it will succeed in doing so.

Just a note about web viewers in FileMaker Go 12

In building the database on which this article is based we encountered a number of rendering issues with the web viewers in FileMaker Go 12. Often the web viewers simply fail to render anything, and are displayed as a black box. Other times they part-render insomuch as they display as a blank white box instead of black! It is only about 1/2 the time that they actually work properly and render the contents of the data URL.

We have also noticed other issues with web viewers in FileMaker Pro 12 Advanced which are bugs, and we have been submitting these to FileMaker in the hopes they will be resolved in an upcoming patch. So fingers crossed the reliability of the web viewer improves in future releases so that this technique becomes 100% reliable :)

Example File

Please find attached an example file. This file is provided to help you fully understand what is going on in this article, and to let you experiment with this solution in both FileMaker Pro and FileMaker Go.

Download Example File

Being there is everything

Thu, 19 Apr 2012 11:09:00 +1200

Digital Fusion have been working out of Australia for a few years now, sharing an office in Sydney with one of our favourite clients - Streamtime. During this time we've had good success but not good enough for our liking.

And running an operation in this vibrant city is pricey and we didn't feel like we were doing the best we could for the dollars we were spending.

Now I know what you're thinking... but we didn't decide to close the office - quite the opposite in fact. Working on the premise that being there is everything, we've leased our own office that comes complete with a 2 bedroom upstairs apartment.

We're making it super-easy for our Christchurch team to be in Sydney, by providing some very stylish digs - this way they?ll get there more often, increasing our presence in this fantastic market.

Already we've had a steady flow of developers working over the ditch, both onsite with clients and in the office itself. With the continuous and rapid evolution of tools like VOIP (Voice Over IP) phone systems and centrally hosted databases, the office in which we do our work is becoming less and less relevant.

So next time you're talking to one of our team, you never know where in the world they might be... here in Christchurch or in our new office in Sydney.

Hook me up.... connecting FileMaker with your website

Thu, 19 Apr 2012 11:08:00 +1200

As our human race progresses through the ages, we're constantly after a bigger bang for our buck. We want more for less: more productivity for less effort i.e. efficiency.

In business, the biggest productivity gains come from automating our processes and connecting all facets of our business. Each time one thing automatically links to another, one of your precious team members reclaims time that can be used to add better value to your business.

So how does this apply to the systems we use?

If our potential customers are able to find out about our company, the services we provide, and the products we sell without having to wait to speak to someone. That'd be a good thing, right?

And if our customers can then order the products they want, with real-time feedback on stock availability at a time that?s convenient to them. Surely they'll keep coming back for more, yes?

And if our customers can pay their account, update their contact details and download a copy invoice, all from the comfort of their home, office or pool-side recliner. That has to be a win-win!

Never far from our client's primary objectives are improvements to efficiency. And the best way to improve that is to automate and connect.
At Digital Fusion we like to think of ourselves as connection experts - in particular FileMaker to Web. There?s two ways to make this all-important love connection:

Take information from your FileMaker database and show it on your website (product info, stock levels etc)
Grab information entered on your website by your customers and drop it into your database (orders, contact details etc)

New Zealand cycle clothing manufacturer, Ground Effect is a good case study. Customers can browse the current product range and even see the availability of different colours (very important for us girls). Online orders take a fast-track to dispatch, and customers can instantly update their delivery details.

Printing company IBS Design have taken it even further, customers can generate their own quotes, place an order and track it right through to courier dispatch and delivery. Purchase history is also available, facilitating re-orders at the click of a button.

The University of Canterbury students can view Community Education courses, place availability and enrol online. All of which is driven directly from their FileMaker database.

Making these connections smooth and seamless can sometimes be tricky, but the rewards are huge. More and more it's what your customers expect - it's also going to make your staff happier, more productive and delivering better value to you (the business owner) and your customers.

Cool things to do with Tab Controls in FileMaker 12

Fri, 13 Apr 2012 15:17:00 +1200

Introduction

FileMaker 12 is here, and with it comes many new cool new features, a lot of which are a result of the new css-based layout engine. In this article we are focusing on one small change borne out of the new layout engine which has massive potential for building new interface controls.

FileMaker 12

So FileMaker 12 is here and by now I'm sure you are getting stuck into it and learning about all the cool new features. We figure rather than re-hashing the same feature lists that you have already seen, we will skip that and cut straight to the cool stuff - namely how can you use the new cool stuff in 12 to do even cooler stuff :)

If you need to learn about any of the new features in FileMaker 12, here are some great resources to get you started:

FileMaker version comparisons
FileMaker Knowledgebase Article documenting all of the changes - a great resource!
FileMaker 12 Whats New from DB Services
FileMaker 12 Managing Container Data also from DB Services
New Features Video from Matt Petrowsky of FileMakerMagazine.com
12 days of FileMaker 12 series of webinars from FileMaker Academy

Tab controls are no longer hungry object-grabbers

In FileMaker 11, tab controls are an all or nothing type object when it comes to objects that they enclose. An object is either enclosed in a tab control, or not enclosed in a tab control, it cannot be half-in or half-out.

This behavior made placing tab control objects over the top of existing layout objects a troublesome affair, especially if you did not wish for the tab control to enclose those objects. In FileMaker 11, objects could become enclosed when the tab control itself was moved or resized.

Here is an example of what we mean:

Here is a tab control and inside it a field. The field is completely enclosed in the tab control - that is to say no edge of the field lies outside of the tab boundary.

As you can see, we can move the tab control to another location on the layout and the field moves with it. Everything enclosed in the tab moves with the tab.

Even putting the field outside of the tab boundary above is still considered enclosed in the tab.

Here we have a typical portal. One of the things you are bound to have done during development is attempt to enclose a portal in a tab or try to resize a tab control over a portal only to find some odd things happening if you don't quite get it right:

Uh-oh! It looks as if one of the fields that was in the portal is now gone. Where did it go? Well the answer is it went nowhere. Remember that everything not fully enclosed in the tab control is considered outside of it.

Another key rule is that anything which falls partly in and partly out of a tab control will by default be placed in front of the tab control.

In the above example, the portal is in front of the tab and everything inside. One field managed to become fully enclosed inside the tab and that field now appears behind the portal.

If we now reposition the tab control you can see the portal field revealed behind the portal.

So what does this all mean?

FileMaker 12 is completely different in the way that it handles tab controls and enclosed objects. An object is still either enclosed in a tab control or not, but this is distinction is now visually blurred somewhat. Objects can appear to be enclosed in a tab control when in actuality they are not - they are simply behind or in front of the tab control.

Whereas before a tab control would enclose any objects within its boundaries, in FileMaker 12 the user has to literally drag, copy and paste, or move an object within a tab control for it to be considered enclosed in that tab. We can best illustrate this with an example.

Again here we have a portal, this time in FileMaker 12

When we drag the portal part-way into a tab control, you'll notice nothing disappears from view. The reason for this is that we dragged the entire portal plus fields into the tab control. FileMaker 12 treats this as a single moved object and because it does not entirely fall inside the tab, nothing is considered enclosed in the tab - not even the field that appears to be fully enclosed.

Because nothing is actually enclosed in the tab, we can now move the tab control around the layout. Moving the tab control in FileMaker 12 has no effect on any of the objects on the layout in terms of them becoming enclosed in the tab control.

Remember - layout objects cannot be placed inside a tab control by means of adjusting the tab control itself - only through moving an object into the tab control.

Now look what happens when we move the field slightly. This time we are moving the field and not the tab control and we have moved it within the tab boundaries. The field is now considered to be enclosed in the tab.

As a result, it now appears behind the portal that is still outside of the tab - just like it did in FileMaker 11. If we now move the tab, you'll notice the field moves with the tab.

Okay I get all that, so what is the benefit?

Well, the benefit is that you can create tab controls full of objects, then drag them somewhere on your layout and have them have no effect on existing layout objects. This may seem a pointless thing to do - why would you put objects in a tab control and them move them in front of other layout objects?

One reason you might wish to do this is in creating overlay menus - hence the name of this article :) An overlay menu is one which we will activate via a button and the menu itself will become visible in front of any other objects on the layout. This functionality can be achieved through the use of a hidden tab control.

Here we have a tab control with 2 tabs. We have placed it on the layout and it happens to be covering part of a portal - no worry! Because we moved the tab control here, it has not enclosed any contents of the portal causing issues.

The button on the first tab is hooked up to the "Go to Object" script step to take the user to the second tab - both tabs have object names.

And here is the second tab with the menu itself present. We have used some opacity on the menu so the user can see what the menu is overlaying. When the user wishes to hide the menu they just click the button which takes them back to the first tab. The overall effect is really quite nice.

The power of tab controls

Using this technique you could in fact end up building some rather cool menu and navigation systems. In FileMaker 12 layouts now have a right edge, so you can use the area outside of the layout for construction of your menu tab controls. When satisfied with them, simply drag them onto the layout wherever you want them to go. You could even group multiple tab controls into a single object to make it even easier. If you need to make changes to a menu, you can do so direct on the layout - just as long as you don't accidentally move any existing layout objects into one of the tab controls you'll be fine.

The case of the disappearing tab control

Another very awesome feature of tab controls in FileMaker 12 is the fact that once a layout object is classified as enclosed in a tab, it is in it until you move it out - no questions asked! This means even if you are to resize the tab control object, shrinking it down to a smaller size - those objects that it enclose are technically still in the tab control, just not visible and not accessible, here is an example:

Here we have reduced the height of the tab control, and as a result half of our menu is now gone. It is still in the tab but because the tab is smaller, it is inaccessible.

Why would this be useful you ask? Well, you can very easily resize a tab control in this fashion to access underlying layout objects you wish to edit.

What else could you do with this functionality? hmm. Let's say you create a tab-control object with a whole heap of stuff in it - a really tall tab control for example. Place it at the bottom of your layout and set it to anchor to top & bottom of the layout. Initially on the layout a user will not see anything, but as they begin to drag the layout height to make it taller, the tab control will reveal its secrets!

Note that in testing this technique we discovered that placing the tab control too close to the bottom of the body part means when the layout is resized the tab control contents are not revealed. There seems to be a threshold point about 30-40 pts above the bottom of the layout part after which the contents don't reveal themselves - odd !

You can find an example of this technique in the demo file supplied below.

A couple of "bugs" as of writing

With all new features in a new version of FileMaker Pro, there are bound to be some issues. In the example file you may notice that the overlay menu itself is actually constructed from a web viewer object rather than a straightforward rectangle object. The reason for this is that if the tab control is placed over an object such as a portal, then clicking in the tab control is actually going to click on the underlying object in some cases - in this case the portal. This means if you miss-click an item on the menu you may in fact click on a portal row instead.

To fix this we use a web viewer because the web viewer object is always in front of portals no matter what, so you can freely click on the menu without it selecting underlying portal rows.

Note:when tested in FileMaker Go 12, this didn't work properly - the web viewer does not appear to render its transparency or colour in Go and instead is just a white void obscuring the menu items. Perhaps it would work better in that scenario with a rectangle for the menu instead of a web viewer.

The technique for revealing layout contents on layout resizing doesn't exactly work great on the iPad where the only way to resize a layout is to change orientation - though it could be used for that purpose to reveal something when you enter portrait mode, and hide it when in landscape for example.

Example File

Please find attached an example file. This is a brand new example file for FileMaker 12.

This file was used for "most" of the screenshots in this article, and is provided to help you fully understand what is going on in this article, and to let you experiment in FileMaker with this solution.

Download Example File

In addition to this, Patrick Kenlock has also kindly submitted his example file of a cool thing you can do with tabs in FileMaker 12. His example allows you to toggle individual tab controls on or off, conditionally formatting them differently depending on whether they are toggled or not. He has also included an updated version of the example produced by David Jondreau, cheers guys!

Download Patricks Example File

Download Davids Example File

FileMaker 12: What's New?

Thu, 12 Apr 2012 10:03:00 +1200

We're all buzzing about the new version of FileMaker that has just been released. There are all sorts of goodies for you as users and us as developers (and there are a few gotchas you should be aware of too).

Let's start with the cool stuff for you:

Containers, those fields that house photos and graphical data, are now easier to manage when they're stored externally. FileMaker Pro and FileMaker Server can keep all of your documents in a single location on the Server (or locally) and can encrypt them. The end result is that database files are smaller and so faster to back up, and all your files are stored in one place, rather than all over the place. Containers have also been optimized in 12 to be much faster to load, and are now capable of streaming audio and video, as well as displaying PDF's directly in the container. And you can drag 'n drop into containers now.

Progressive Backups are now possible, meaning that only what has changed since the last backup needs to be backed up. If you have a large database, you'll see major speed improvements in the time it takes for you to do a backup.

Graphs have been given expanded capability and a new user interface, so you may find that a graph that we couldn't do before is now possible.

FileMaker Go, the FileMaker application for iPads and iPhones, has been brought into feature parity with FileMaker, meaning fewer limitations on that side of the fence.

Web Publishing: there's been a complete rewrite of the FileMaker Web Publishing engine, to get better performance for Custom Web Publishing. The speed improvement is touted to be up to 100 times faster.

For us as developers and for those of you who like to get your hands dirty, here are a few of of our favourite new features:

Layouts based on Web Technology: The Layout engine has been rebuilt based on CSS. This makes possible the styles and alignments described in the next two paragraphs. It also raises the hope that in the future, CSS-savvy developers might be able to make changes of their own, including designing customised database themes.

Object Styles: A bit like conditional formatting taken to new heights: you can specify different styles/colours for a button (or other object) when it is in focus, hovered over, pressed, or just sitting there. And colour gradients and transparency are available for the first time too.

Aligning Objects: Guides that are local to a layout or global to all layouts in the database are now possible. It's much easier to keep the look and feel more uniform across a database. And FileMaker makes a real effort to help you keep fields aligned and buttons or fields of uniform size with its dynamic guidelines and same-size recognition.

Execute SQL function: FileMaker is signalling greater support for SQL by expanding the existing Execute SQL from a script step that can only be used on external ODBC data to a function that can be used to query FileMaker databases. This means that records from unrelated tables can be queried without having to set up a relationship.

Now the things to be aware of:

Mac OSX 10.5 (Leopard) and earlier, and Power PCs are no longer supported, so you won't be able to run FileMaker 12 on a Mac unless it's OS 10.6 (Snow Leopard) or later. Macs bought in 2009 or later should be fine (i.e. have 10.6) and older ones bought from 2006 onwards (Intel-based) can be upgraded.
FM12 involves a file format change from earlier versions, which means it's not reversible: once you've converted a database, it will be openable in FM12 only.
If you have your own FileMaker Server, and you upgrade to 12, you'll need to upgrade your Server too.
Conversions go pretty smoothly, but you can expect the odd problem and sometimes these can take a bit of time to resolve.

Changes to FileMaker Go 12

Thu, 12 Apr 2012 10:03:00 +1200

FileMaker Go has been "brought into feature parity with FileMaker Pro". In this article we'll look at what that means more specifically.

Firstly, "features" don't extend to things like Layout mode, Manage Database or Edit Script: you still need to do development on a Desktop machine. And we'll include a list of some specific things that are not supported at the end of this article.

But there's plenty of new stuff to get excited about:

Speed - it's faster overall.

Preview Mode is now supported where it was not previously. And air printing has been available since version 1.2 (no expansion of printing capabilities in the new version).

Thumbnails of images can now be generated and displayed.

Importing is hugely enhanced to take advantage of the things that iPhones and iPads do:

import a photo or video capture from inbuilt camera
import audio from inbuilt audio recorder

Exporting is expanded from just exporting a single record to exporting multiple records in a variety of formats, including pdf, csv, jpeg, mp3 and lots more, and offering email, save and view options.

Snapshot Link is enabled, in both opening and creation modes.

New Chart Types have been added, as in FM12.

Conditional Formatting - As in standard FM12, you can specify different styles/colours for a button (or other object) when it is in focus, touched, or just sitting there. Colour gradients and transparency are available for the first time. And conditional formatting in tab panels has been implemented too.

Email/Save Photo lets you choose a File Size option.

Location - a new function, Location(), allows you to retrieve your location from GPS, Cell or Wifi.

Behaviour when in the Background has been tweaked. The extended privilege fmrestorelogin has been replaced by fmreauthenticate, which has optional entry of a number of minutes of grace before re-authentication is required. The re-authentication dialog is used not only when restoring from hibernate, but also when switching from background to foreground and from sleep to wake. The setting "Try to restore Login?" is no longer used because it will always try to restore, subject to security settings.

Not Supported:
Tooltips
Plug-ins
Script debugger

FileMaker 12: Better, Faster, Stronger...

Thu, 05 Apr 2012 15:57:00 +1200

We're rapt to see the new version of FileMaker released, a major release covering all 3 aspects of the FileMaker suite (FileMaker Pro, Server and Go) in one hit, and bringing a raft of new features along with speed and robustness improvements... all very good stuff, so here's a few highlights and what they'll mean for you.

The biggest change is the "layout engine" which is the technical way of saying that it's now a lot easier to have modern style screen layouts. FileMaker have used the same technology used in web pages so we can do a lot of the same effects, like changing what shows when you mouse over something, gradients and transparency... all of which means your FileMaker solutions can look and feel a lot more like a modern program or web site. In turn that helps keep screens clean and clear, make better user of space, and ultimately makes for happy productive staff using the systems.

Behind the scenes the server product has very important improvements that basically mean more speed, continuous backups, and a huge improvement in stability - it's now much harder for plugins and scripts running on the server to crash. You won't notice this day to day so much, but we know that FileMaker systems are the backbone of many businesses and these changes greatly reduce the chance of interruption and disgruntled staff... keep em happy!

Other changes include the way documents, images and files are handled which means FileMaker can be used as a document management system with much greater aplomb; and connecting your database up to the web will see you dish out web pages much faster, all as a result of some serious rejigging under the hood in that area of FileMaker Server.

Finally FileMaker Go, which is FileMaker for the iPad has been updated too. It's very slick ? much faster than the previous version and of course it inherits all the new layout capabilities from the desktop application. Perhaps the biggest thing is that it's free which is a very nice surprise and we're sure that'll mean it spreads like wild fire... it's by far the best and only real option for quickly building quality business solutions for iOS devices ? iPad, iPhone and iPod Touch. And no, it doesn't run on Android.

The only real drawback with the new FileMaker stable is that it's not compatible with the old version, so files have to be converted and you can't mix and match. We think the price of that is worth it for all the good stuff this new version brings, but before you upgrade please talk to us and we'll help make sure everything will go smoothly and advise on when we think it's time to make the jump.

For more details read our blog article on some of the technical changes .

Tips & Hints - Scripting

Mon, 05 Mar 2012 00:00:00 +1300

Introduction

This is the third article in our series of tips and hints for FileMaker. This time we are focusing on scripts - from their creation, to editing and debugging. Take it as it is - this is just an assortment of our favorite time-savers, shortcuts, tips, hints, tricks, tools of the trade and more.

Getting to a Script for Editing

There are a number of different ways to access individual scripts or the Manage Scripts dialog.

Obviously the most common of these is via the Scripts menu, or using the shortcut cmd+shift+S (ctrl+shift+S on windows).

When in layout mode, one of the most common things done is creating buttons and attaching scripts to them:

From this dialog you can select the script via a modified - and modal - version of the Manage Scripts dialog.

While not initially obvious, you can in fact create and edit scripts from this dialog. In the normal Manage Scripts dialog a double click on a script will open it for editing. Here however the double click action is used to assign the script to the button.

To edit a script from this dialog, first select it and then choose Edit from the menu shown below.

When editing a script from this modal Manage Scripts dialog the script itself is also modal. You'll notice an OK and Cancel button provided on the script just like in versions of FileMaker prior to 10 (cmd+S to save and cmd+W to close are not available here).

Creating and editing scripts from this modal manage scripts dialog is a huge time saver when setting up a button as it saves you having to work your way back out of the chain of dialogs to get to the regular manage scripts dialog. If the script is simple enough then you may as well create it when you define the button :)

The script debugger in FileMaker Pro Advanced is another location where you may need to quickly access the script being debugged.

The middle button will open the script currently being debugged. This makes the debugger a useful tool for quickly opening a script attached to a button while in browse mode. Of course, the script you open cannot be saved while the script is still running in debugger, so be sure to halt the debugger in this situation.

Don't forget also that if editing scripts via the Manage Scripts dialog you can open more than one at a time. This is useful if you are dealing with a script that uses sub-scripts, or if you need to modify a large number of scripts at once. To do so, highlight the scripts you want to edit and then double-click - all chosen scripts will open.

Script folders are a great way to organize your scripts. If you are anything like me then you like to keep things tidy. Sometimes you'll have folders collapsed and others expanded, which can make locating a particular folder a real chore.

There is however a way to locate any folder whether it is expanded or collapsed by using the folder filter at the top of the Manage Scripts dialog.

Problem! While this filter does keep folders in the correct order, it does not nicely display the sub-levels of folders, and as a result all folders appear one beneath the other - you have no idea which is a sub-folder of another folder!

This can be remedied by adding spaces to the beginning of your folder names for each level. I'll admit it's not the nicest solution - this is something FileMaker should just do natively - but it can provide a nice effect for quick folder selection.

A Note on the Import Records script step

When it comes to creating copies of scripts, FileMaker gives you a few options. You can start with a blank script and copy script steps into it. You could duplicate the script or use the copy/paste script functionality. Finally, you can import scripts from other files.

All of these methods are fine methods but pay particular attention to the difference between the duplicate and copy/paste functionalities. Aside from the resulting copy's name change (a 2 on the end for copy/paste vs "copy" for duplicate) there is an interesting change that occurs in the Import Records script step.

In the picture below we have a straightforward import records script step that is importing contacts from another file into the current file.

Here we are using the matching names option as a means of providing the field mapping.

Now if we were to make a copy of this script using the copy/paste functionality we end up with:

as the mapping method on the import records step as opposed to using the duplicate command and having the step retain its mapping method:

In a situation where the import records script step is used in a script, the duplicate command is preferable to a straightforward copy/paste if you need to copy the script.

In fact, even copy/pasting that single script step to another script will revert the mapping to "last order". If the script is imported from another file, then the mapping is also changed.

Making writing a script easier

Here's a quick tip: when writing a script it is always a good idea to put yourself on a layout which is the main context the script will spend the majority of its time on. By doing so it means anytime you need to reference a field in a script step you can be sure that it will be in the initial list of fields to appear.

Chatty Scripts (mac only)

Sometimes we create scripts that can take quite a long time to execute. Examples of such might be doing a mass mail-out, or generating millions of test records. Other times we are debugging complex scripts that can take a long time to step through in the debugger to find out what's happening.

What do both of these scenarios have in common? Well, they both take a long time to do - time that busy developers do not have. What if there was a way to start a script running so you can basically forget about it, yet still debug it or be notified of its progress at the same time? There is a way on the mac.

The Speak [] script allows for a calculation to be presented to you in an auditory manner :) Better yet, it has an option to have the speech not impact on the scripts execution by pausing while talking.

There is some good potential for this script step to be used in debugging or progress notifications. Consider the script shown below:

Here we have a script that we will use to generate 100 million dummy records. We want to be kept abreast of how it is progressing, yet we don't wish to do this via custom dialogs that we have to manually dismiss, nor do we want to waste time defining variables to view in the data viewer (which suffers from update issues during script execution).

The Speak [] step is a great solution. We simply have the script tell us its progress. This is done every time a new 1 million records are created. The script step tells us how many records have been created. We could very easily tweak this to have it tell us what percentage of completion it is up to. Very cool! We can now fire up another copy of FileMaker Pro on the mac and do other work while leaving this to run in the background.

We first learn't of this cool technique from this article by the very talented Dwayne Wright at his FileMaker Thoughts blog - well worth checking out!

Secondary Action Modifiers

There are a number of script steps which require require two or more pieces of information for the step to be fully specified. In some cases it is possible to use a modifier key to open the secondary options.

As an example let's look at the Set Field script step.

The primary option is to specify the field as noted by the fact the button has focus. Double-clicking on the script step is going to run this first option. The secondary option of specifying the calculated result can be opened by using the option modifier key (alt on windows) and double-clicking on the script step. This is a huge time saver when writing scripts that use this step often.

Other script steps where a modifier key can be used to open the secondary options are:

Install OnTimer Script []
Set Selection []
Set Field []
Set Field By Name []
Set Next Serial Value []
Insert Text []
Insert Calculated Result []
Insert File []
Replace Field Contents []
Export Field Contents []
Save Records as Excel []
Save Records as PDF []

The import records script step cannot have its secondary option opened via modifier key, but it can be opened using the return/enter key which is still faster than using the specify button provided.

Adding Multiple Script Steps

Just in the same way we demonstrated how you can open multiple scripts at the same time, you can do the same with individual script steps. Quite often when writing a script you have a good idea of the steps you will require, so why not just add them all at the same time. You can go shopping for script steps, adding each step to your cart by selecting them from the list of steps. When you have chosen all of your steps, use the move button to checkout your steps to the script, or double click any of the selected steps.

Steps every script should have

There are some important script steps that it would be a good idea to add to most of your scripts prevent issues for your users.

The first is adding a script step to the very start of your script that determines the initial mode the script should be in. Typically this is going to be the Enter Browse Mode [] script step. Why you ask? Well consider a user who has gone into find mode to do a search, but in doing so they happen to click on a button that runs one of your scripts. That script is going to begin its execution in find mode - a new record command will be adding a new request, set field will be defining a find request, and so on.

You should always be explicit in defining context at the beginning of a script.

Lastly, putting an Exit Script[] step as the last step of your script is a very handy thing to do for debugging purposes. Without it you are unable to fully debug the very last script step.

Here is a very simple script to illustrate that last point. The script has a single set variable script step. Let's now debug this script to try and determine the value of $variable during execution:

Uh-oh! We are on the last script step, but our data viewer is still not showing the value of $variable. This is because $variable has not been defined yet. Because this is the last script step, once we move to the next step the script will end and $variable will be lost - we will never know what it could have been set to

What if we put an Exit Script [] step as the very last step? Now the Set Variable step is not the last in the script, and we have an opportunity to view its value. The script is going to exit anyway at the last step so the Exit Script [] step merely helps to serve as an extra debugging step for the "real" last step that precedes it.

A 'Local' Way to Suppress Script Triggers

Sat, 11 Feb 2012 00:00:00 +1300

Introduction

Script triggers are a great feature in FileMaker that allow you to initiate a script when certain actions occur such as committing a record or leaving a layout. Not only do they run when user initiated, they can also be script initiated by script steps. This can sometimes produce unexpected results and so you may wish for triggers to be disabled. This article presents a very simple and elegant method of suppressing script triggers from firing when initiated by other scripts.

EDIT: You always think of new things once the article is written, d'oh!

So after writing the entire article and then sitting down afterwards and having a little thing, it became apparent there is in fact a far more elegant solution that follows the same technique as in the article - but without the need for any variables of any type. It will make more sense as you read the article, but for the time being just note that you could simply pass Get ( ScriptName ) as the parameter to the script trigger and check for whether it is empty or non-empty as your test. Anyways onto the article...

Some conventions before we begin:

Because we are dealing with two types of scripts in this article, we will refer to triggered scripts as T. The main script that is executing will be called A.

The method we have used to this point

Suppressing script triggers is a common issue and one that has had solutions devised in the past which we have used. The conventional method involves setting a global variable at the beginning of script A as a means to tell other triggered scripts T that script A is executing and that they should halt their own execution immediately.

While this method works, it does require a fair amount of maintenance. Not only does the global script variable have to be set in A, but if there are any exit conditions later on in the script, it must be cleared otherwise the global variable will persist with its value when future scripts are run.

The thing about local variables

You've all seen local variables and almost certainly used them in scripts to store information required during execution. So what does "local" mean? Well, the local variable only exists within the context in which it is defined. In the case of scripts, when you define a local variable then that variable will only exist while that script is running. Once the script ends, the local variable is trashed. The "script" is the context in this case. We tend to think of these as script variables, but they really aren't.

The Set Variable script step does not actually mention at any point that these are script variables, they are local variables.

Are there any other contexts in a FileMaker solution where we might be able to define a local variable? The answer is yes!

Defining a local variable outside of a script

Just like the title says, local variables can be defined outside the context of a script. When this is done, the local variable exists and is available to be referenced anywhere in the current file EXCEPT when a script is running. Once a script begins to execute, the context has changed and the local variable is not available until the script ends.

How this translates into a method for script trigger suppression

So what do we know so far? We know that if we can set a local variable outside of a script, then this variable will exist only outside of scripts. Conversely we know that when a script is executing, the local variable is unavailable, and so if we try to obtain its value it will return a blank.

Ah ha!

What if we define a local variable outside of a script and then pass it to the script T as a parameter. If T is user initiated then the parameter passed will be the value in the local variable.

However if another script A is executing and triggers script T it is going to pass the local variable. Because the context is a script, the local variable is going to be blank and so script T will receive a blank parameter.

Confused? Ok lets break it down....

Part 1: Defining the Local Variable

The first step involves setting a local variable outside of the confines of a script. This is not quite as easy as it sounds. In order to do this we require a calculation to define the local variable, and we require that calculation to evaluate outside of the script.

In this article we are using 2 different examples of where we can place this calculation and have it evaluate outside of a script.

The first place we could define the local variable is within conditional formatting. These calculations are evaluated when a layout renders for the first time and when the layout refreshes thereafter. In this case we have defined conditional formatting but applied no formatting for the calculation - it is merely to define the local variable.

You could place an object on your startup layout (or a number of layouts) that contain this conditional formatting calculation. You need to make sure it is visible on the layout for it to evaluate.

The second possible location is within a custom menu name. If you have a menu item that is used in your custom menus then you can hide the definition of the local variable within the menu name as shown. Custom Menu names are evaluated when layouts load, refresh and when the menu is accessed.

Other possibilities might be to create a calculation field placed on a layout that defines the variable, or modify an existing calculation field on a layout to define the variable.

NOTE: If you use a startup script, be careful because conditional formatting and custom menus are going to evaluate while the startup script is executing, and as such the variables defined will actually become script variables!

Part 2: Setting up your Script Triggers

The next step involves setting up script triggers. In this example we are using 3 layout-level script triggers.

Each of the T scripts are being passed the local variable defined in Part 1 which we have called $ScriptTrigger.

In the scripts we place a few lines of code to check the script parameter.

If the triggered script T is user initiated then it is being initiated from outside the context of a script. This means $ScriptTrigger exists with a value and as such the script is passed a non-empty parameter. The triggered script T can then execute because it knows a user has caused it to trigger.

If however script A is executing and does something that causes T to trigger then when it tries to pass $ScriptTrigger it is going to pass a blank variable. Remember, $ScriptTrigger only exists outside of a scriptural context! The variable does not exist in script A.

Script Debugger

If you are using the script debugger to try this out you may end up with differing results. With debugger enabled, the conditional formatting and custom menu calculations will actually evaluate at some point during the process so that $ScriptTrigger gets defined within the context of script A. This does not occur when the script debugger is disabled.

Some things to note, and other stuff..

This technique can very easily be reversed so that you can use script triggers in a way that they are initiated only from other scripts and not when they are user initiated - simply change the check at the beginning of the triggered scripts.

This technique should probably be accompanied by some documentation as to where you are defining your local variable outside of the script context and what the name of that variable is. You should probably also document the technique in the triggered scripts or parameters passed to them. If other developers come along in future and see a local variable being passed to a script, they may wonder what is going on, and could think it is an error and remove the variable!

Example File

Download Example File

Tips & Hints - The Relationship Graph

Tue, 31 Jan 2012 00:00:00 +1300

Share your own tips and hints:

We had a great response to our first article with readers submitting their own favorite layout mode tips - a huge thank you to everyone who contributed. If you have any cool tips for the relationship graph we'd love to hear and share them, be sure to leave a comment with your favorite tips and hints.

Accessing the Relationship Graph

How do you get to the relationship graph? Well the obvious way is via the Manage Database dialog (File -> Manage -> Databases). Incidentally, if you are not using the cmd+shift+D (ctrl+shift+D on windows) shortcut to get here then shame on you - this should be the first FileMaker shortcut you should learn!

There are actually many other areas in FileMaker from which you can enter the relationship graph, and these areas are actually far more powerful a means of accessing the graph than Manage Database. It took me (Daniel) a couple of years of neglecting these access points to eventually realise that I should be using them all the time, and now I do!

Ever seen the option below when setting up a value list?

Or this when specifying a field on a layout?

Or even this when choosing a field in a calculation?

These are all links to the Manage Database dialog. Depending on the context from which you follow this link, you will either be taken to the last tab you were on when you last visited the Manage Database dialog, or directly to the relationships tab.

In all of the examples above the key context is the need to select a field, be it for the value list, the field on the layout, or in the calculation.

However FileMaker is very smart, and it knows that we entered the Manage Database dialog from this specific point. It knows that if we create a table occurrence when in the dialog, then there is a good chance we have created it because we need it in the original context.

FileMaker will automatically select the last created table occurrence for you when you leave the dialog, if entered from one of these special "Manage Database" links.

As a classic example, let's say we are creating a value list. The value list is to be based on a related field value from a given context. We have the initial context, but we have forgotten to establish a relationship to the related context. Rather than cancel out of all the dialogs to this point (and thus losing our work), we can instead go direct to the Manage Database dialog via the value list.

From here, we can add the relationship required for the value list

When we press OK, FileMaker knows we added the table occurrence, and so we likely wish to use it in the value list. It automatically selects the table occurrence for us so we can continue to build the value list.

If we are already in the Manage Database dialog, perhaps editing a field calculation, we can still use the "Manage" shortcut, however in this situation it is a link to "Manage Relationships" instead of "Manage Database".

FileMaker prevents us from accessing more than 1 Manage Database dialog at a time, but it does let us access the relationship part of the dialog via a separate window.

You'll notice this window is purely for the relationship graph - there is no tab for tables or fields at the top. There is also no cancel or OK button, simply a close. This dialog works the same as the other access points. Upon pressing close, FileMaker will use the last created table occurrence back on the preceding dialog.

Relationship Graph Shortcuts

While not really obvious from looking in the relationship graph, there are in fact a number of really cool and useful shortcuts available. Refer to this link for a full list of shortcuts available. Below are some cool uses for these shortcuts.

Quick Selection of Table Occurrence Groups

If you use the anchor-buoy method of designing your graph then there may be times you need to select an entire table occurrence group. The simplest way is to start by selecting the anchor, and using the cmd+Y (ctrl+Y on windows) shortcut to progressively select table occurrences more and more levels away from the anchor. Just repeatedly tap the cmd+Y key a few times to quickly select the entire TOG. You could now use cmd+T to expand the entire TOG if you wish.

Got a Big or Messy Graph?

Sometimes a common problem on large or messy graph is the inability to locate a particular table occurrence you want.

You can start by trying to type the name of the table occurrence if you know it and this can be all you need in some cases. If your table occurrence has a long name or contains spaces then it can be difficult to type the name fast enough to find it. If you found at least 1 result then you can use Cmd (ctrl) + G shortcut to cycle through the full list of found matches until you find the one you were after.

If that doesn't work, try using the cmd (ctrl) + U shortcut. Start by selecting a table occurrence whose underlying table is the same as the one you want to find. Can't find a table occurrence? Then just add one temporarily for this purpose. Select it and use cmd+U. Now zoom out of the graph and focus just on the highlighted table occurrences.

An application we often use here is 2empowerFM Developer Assistant which among other things is great for locating Table Occurrences on the graph.

Finally you can just print the graph. The Print button is located in the lower left corner of the relationship graph. When printing, you have the option to print the graph on a single page or multiple pages - either option is good.

Instead of printing it, generate a PDF instead using the Preview/Save as PDF option from the print dialog (and the windows equivalent).

Now you can search the graph using your PDF reader instead of FileMaker. This is actually not a bad idea for large graphs as FileMakers search tends to get significantly slower with an increased number of table occurrences, whereas the PDF readers tested perform fine.

The other benefit of using a PDF reader like Preview, is that it can be easier to quickly see and scroll through all found results.

Quickly Creating Relationships

When forming a relationship between two table occurrences, don't waste time dragging the relationship line directly onto the field you want in the source and destination table occurrences - you'll be there all day waiting for the fields to scroll!

The quickest way to add a relationship is to drag the relationship line from any field on the source side to any field on the destination side. Then use the edit Relationship dialog to correctly choose the fields required. Be sure to use the type-ahead functionality provided to quickly locate the fields. If you need to expand table occurrences in order to drag the relationship line, use the shortcut cmd (ctrl) + T to expand both table occurrences at the same time. You can then use it again afterwards to collapse them at the same time - every second counts !

Keep your Graph Tidy!

This is the number one thing you can do for your graph to boost productivity and decrease development time. A tidy graph is a happy graph. Try to avoid overlapping relationship lines and keep some kind of logical layout to your table occurrences.

Remember, the alignment tools are your friend, just as they are when working in layout mode. They work very much the same way - with the exception of there being no shortcut keys (Shame on you FileMaker!).

Alignment Tools and Custom Menus

A bug that presented itself in FileMaker 10 and has persisted until this day concerns the alignment tools in the relationship graph. If you entered the graph from a layout that is in browse mode, and are using a custom menu, then the alignment tools are going to be greyed out and unavailable. You should ensure that you are in layout mode first, or switch your custom menu. Here's hoping FileMaker will fix this in future!

Comment Boxes

Comment boxes need not just be used for comments. We also use them as dividers that separate table occurrence groups, or logical sections of the graph. Particularly useful in anchor-buoy systems is adding a large comment above the TOG to indicate its purpose, or the screen it pertains to. This makes locating TOGs on the graph much easier. For large graphs, make the text size big so you can still find TOGs when zoomed out.

If you prefix your TOG labels with something standard - such as "zzz" - then searching for a particular TOG becomes a cinch. Use the graphs search functionality - it looks for comments as well as table occurrences!

Creating Table Occurrences

Much like creating objects in layout mode, there are a few ways to create table occurrences on the graph. Firstly, you could use the provided button to add a table occurrence from scratch. A duplicate button is also provided - select a table occurrence and then use the button to duplicate.

Our favorite method however is option (ctrl) + Drag to create table occurrences. When using the option+drag method, the edit table occurrences dialog does not appear automatically after the duplicate is created. This is really handy, because often you want to position the table occurrence first.

And Finally, Table Occurrence Names

Using a naming convention is a great way to assign names to your table occurrences to keep everything in order, and make it easy to identify a table occurrences purpose, and its associations. There are many different conventions out there and everyone has their favorite.

Often naming conventions are such that in order to add a new table occurrence it is easiest to create a duplicate of the table occurrence it will be related to. You can then change its underlying table and rename it by changing a few parts of the table occurrence name.

Above I have created a duplicate of a table occurrence that I wish to establish a new relationship from.

If I go directly into the table occurrence setup and change the underlying table, you'll notice that the table occurrence name has reverted back to the table name. This happens upon entering the dialog and making no changes to the occurrence name. Once you make any change to the table occurrence name, it will remain as-is when you change the table.

So the tip here is, change your table occurrence name first before changing the table. Another good habit of getting into is copying the occurrence name to clipboard when entering this dialog. Tab followed by cmd (ctrl) + C will put it on the clipboard. Then if you change the table it doesn't matter if it gets overwritten as you can paste it back in.

Every second counts so if you can reuse any existing table occurrence name then it is worth doing.

Tips & Hints - Layout Mode

Thu, 26 Jan 2012 00:00:00 +1300

Introduction

This is the first in a series of articles that will present some useful and time saving tidbits for various areas of FileMaker. In this first article we focus on layout mode. There is no rhyme or reason, no common theme - just an assortment of our favorite time-savers, shortcuts, tips, hints, tricks, tools of the trade and more:

Drawing Lines and Shapes

We all know the shape tools. You know - those tools to draw lovely lines, circles and squares? There are a couple of cool shortcuts that can be used in conjunction with these tools.

Holding the shift key while using the line tool will snap the line to a vertical or horizontal alignment - perfect for drawing straight lines!

Did you know that holding the option key (ctrl on windows) while using the line tool will snap the line to a 45, 135, 225 or 315 degree angle? This can be useful for drawing triangles or any other shape where an angled line is required.

Sometimes you want to draw a perfect square or circle quickly. Rather than drawing something akin to humpty-dumpty and then using the inspector to fix the dimensions, you can instead hold the option key (ctrl on windows) to fix the width and height to the same dimensions. Now you too can make perfect circles every time.

The option (ctrl) modifier key even works with all of the other layout drawing tools and object tools as well.

Remember to never draw a line with an initial width of 0pt and then change it to 1pt or higher. This is going to result in a blurry line due to a FileMaker rendering bug that has been around for a while. This is an issue on both mac and windows. One of the lines below is not like the other...

Creating Copies of Objects

There are a number of ways to create copies of objects on a layout. The first is simply selecting an object and using the copy/paste commands (cmd/ctrl c/v). When using this option the pasted object will be moved to the location of where the mouse was last clicked on the layout. In fact, the last clicked location will be dead centre of the pasted object, so if you want to quickly paste an object in a location of the layout, click there before pasting.

The option key (ctrl on windows) can be used to drag a copy of an object. Select an object, then while holding the option key, drag the object to a new location. Release the mouse while still holding the option key. Use this in conjunction with the shift key (for locking to horizontal/vertical alignment) to copy an object and keep it in-line with the original.

Finally there is the duplicate command. You may be wondering why you would bother using duplicate when you could just as easily use copy/paste or option-drag. Well, the duplicate has a nifty feature built into it.

Select an object - let's call it A - and duplicate it (cmd+D). Now move the new object - B - to some location, such as beneath the original object A using either the keyboard arrow keys or the mouse.

If you now duplicate B, you'll notice that the resulting duplicate C is positioned relative to B, in exactly the same way B is positioned relative to A.

Now duplicate C to get D, and D will be relative to C the way it is relative to B and so on....

You can use this technique to quickly create a series of objects all evenly spaced.

Don't Reinvent The Wheel

Here's a quick tip - don't waste time designing layout controls or formatting objects if they have already been designed elsewhere. You can really speed up your development by reusing existing objects from other layouts and re-purposing them for your requirements. In fact in most cases once a database reaches a particular point, there is very little need to create any object from scratch because it should already reside somewhere in the system waiting for you to copy it :-)

Quick formatting of objects

The format painter is a great tool for quickly applying formatting styles to objects on a layout. It exists in the status area as a paint icon.

To use, select a layout object. Then click the format painter icon. Now select another object on the layout to apply the formatting from the originally selected object.

The format painter tool can also be locked in the ON position by double-clicking the icon. This lets you select an object and then apply its formatting to multiple objects. When finished, click on the selection tool icon, or press the escape key.

In fact it's not just the format painter that can be left in the locked position - every tool in the picture shown above can be locked in the ON position - this is great for creating lots of lines, circles, squares, portals, you name it.

Make Formatting Faster

Format painter is great, but what if you need to apply a style across a large number of objects? Lets say for example you have a layout with 100 text labels on it, and you wish to apply formatting from another label to all labels on this layout.

You could use the format painter in its locked mode and click on all 100 labels to change them, but there is a better way.

When the format painter tool is used on a series of grouped objects, the formatting is applied individually to all objects in that group. So, to format the 100 labels we simply need to group them. This could be a case of dragging a text selection box over the labels and grouping them. If the labels are sporadically placed on the layout, you can use a nifty shortcut to select all layout objects of a particular type.

Cmd+Option+A (ctrl+shift+A on windows) will select all like objects on a layout, such as text labels. Once selected, just group them into a single object and apply the formatting to that grouped object. When done, ungroup them.

Duplicating Tab Control Objects

Tab controls can contain many tabs and many objects on those tabs, so what happens if you want to make a new tab control with the same formatting but none of the contents? The first step is to make a copy of the existing tab control object.

Here is a pretty complex tab control object that contains many internal objects and other layouts of tabs.

For the first method, go into the tab control setup and remove all tabs apart from the first one (at least one tab is required to retain formatting).

This leaves you with just one tab to clear of contents rather than all tabs. When done, just go back into tab control setup and add your new tabs. Remember that when in tab setup don't remove all tabs and begin re-adding tabs, otherwise all formatting is lost. Make sure you leave 1 tab and click OK before going back in and adding your tabs.

The second method involves resizing the tab control object in a way that all contents that were in the tabs are no longer inside the object. To do this, drag the lower left corner of the tab control up to the upper right corner and keep going until the tab control object is completely outside the realm of the contents, as shown below.

As you can see above, the tab control is now a tiny object in the upper right corner. Because everything is no longer in the tab, it is all combined into a large mess of objects overlapping one another. This is fine though because it makes it really easy to drag a selection box over it all and hit the delete button.

Now just resize the tab back to whatever you want. The cool thing about this method is all the original tabs and their names are retained. You can restore it to its original dimensions using the "resize to largest width and height" command.

Learn to Love the Arrange Menu

The arrange menu contains so many great and powerful tools (and shortcut keys) that if learned will greatly improve your productivity, especially if you can use the shortcuts available without having to resort to the inspector or the menu. When arrange tools are used in conjunction they can make seemingly tedious tasks much faster.

As an example, let's say we have a series of labels we want to align to be horizontally spaced and left aligned.

First, begin by positioning Object 1 and Object 6 to the top and bottom coordinates you want the objects to be spaced in. Don't worry about everything else just yet.

Next, for all the other objects, put them in the order you want them to appear. Again, don't worry about any spacing or alignment just yet: as long as one is beneath the other it's all good.

Once done, you are ready to do the final steps. Select all of the objects and left-align using cmd+option+left (ctrl+alt+left on windows). Now simply use the align vertically command and you are done.

The key here is that once you have your top and bottom objects positioned, and everything in between, the rest is really simple.

More about Selecting Objects

Selecting objects on a layout can be done in the following ways.

First is simply clicking the mouse on an object to select it. Holding the shift key will let you individually select multiple objects.

Drag the mouse button to select multiple objects. All objects that fall entirely within the selection box will be selected.

Holding the option key (ctrl on windows) while dragging will draw a special selection box that will select any object that partially falls within the selection area.

Cmd+A (ctrl+A on windows) will select all objects on the layout, locked or otherwise.

With an object selected on the layout, use Cmd+Option+A (ctrl+shift+A on windows) to select all other objects of the same type on the layout. This is a really awesome feature that can really assist with development, as discussed below.

Working with Hidden Tab Controls

We have already touched on a few uses of the "Select Same" command above, but have you ever thought of using it as a means for finding objects on a layout?

Hidden tab controls are becoming ever more popular as a means for showing and hiding layout content. The problem however is that they can be a real pain to develop - they're hidden! One quick way to find hidden tab controls is to use the "Select Same" function. Select an existing visible tab control on the layout (or add one if there is none). Then with it selected, use the "Select Same" function - this is going to select all tabs, including hidden ones. From there you can locate the edge of the hidden tab for selection.

Another way of locating hidden tabs is to apply a blank tooltip to its tab controls, and then turn on "show tooltips". hidden tabs will appear as tooltip badges where you would not expect a tooltip to be :-)

Resizing Text Labels

Finally we have a tip for resizing text labels. How often do you copy and paste an existing label only to change its text and realize the dimensions of the label are now way too big?

This is a really common problem when the text in a label changes. The easiest way to snap the dimensions of the label to their smallest dimensions is to change a style of the label and then undo that change. Making the label bold/underline/italic is a really easy way to do this. Underline for example would be cmd+shift+U twice.

Sometimes you may notice that your label does not snap to the smallest dimensions with this technique. There are a few reasons why this may happen, but they all are concerning paragraph settings of the label as shown below.

For a label to snap to smallest dimensions, vertical alignment must be top and horizontal alignment must be left. There can be no indents or lines above/below. Line spacing must be 1pt.

If your text has justified alignment, then the label will snap to the smallest height, but not width.

Tour de DF

Tue, 29 Nov 2011 11:15:00 +1300

We were supposed to be competing (hmm... let me think about that word?) in the Lakes Loop Challenge, originally set for early this month. But fate stepped in at the last minute and the event was postponed.

Disappointed barely covers it. We had a house booked for the weekend in Nelson, the post-event beverages were all but ordered and we had new designer cycle jerseys (thanks to our resident designer Mat) made specially.

What do you do when your dreams go up in smoke? Well I'll tell you... you pick yourself up, brush yourself off and make a whole new dream! Catherine suggested we make our own custom-made cycle ride. Non-competitive (sort-of) and stops along the way. We all said "hooray for Cath".

So Catherine, Daniel, Phil, me and my daughter Sarah decided to ride out to Lincoln on the old, but now tar-sealed Rail Trail. It was a struggle to find another weekend that suited us all but eventually the stars were aligned and a date was set.

Barely 5 minutes into the ride and Daniel needed a break and he said it was a flatty, but was it really?

We biked to Lincoln, had a lovely lunch at Hillyer's then headed for home. But after a long ride of another 5kms (ish) Cath suggested we stop at the Prebbleton Pub for some well earned refreshment. I know what you'rere thinking and it's ok, Sarah just had a lemonade.

It was a great little outing and we were quite a sight in our matching jerseys.

I Have A Dream... Practice Management Without Fuss

Tue, 29 Nov 2011 09:58:00 +1300

Every business dreams of a paperless office right? Where administration takes a back seat to customer care and excellence in your field. Dr Alex Buller and his team at Eye Surgeons Hawkes Bay (ESHB) have put the blinkers on, buckled their seat belts and embraced this challenge with absolute determination.

This Practice Management solution needed to be able to email, print, scan in documents, track and monitor patients, calendar appointments, set reminders, and invoice all pretty standard stuff. They also needed the ability to receipt payments against multiple bank accounts and operate smoothly across Macs and PC's this is a bit more complicated, but still not too unusual.

So why not look for an 'off-the-shelf' solution?

Alex wanted control! From the outset he knew they wanted a custom solution which isn't for everyone, at times it can be more stressful than a houseful of pre-schoolers. But they were committed and didn't want to be constrained or confused by features that were designed to suit the masses. Ongoing improvements, additions and modifications needed to be driven by them and reflect the changing needs of their practice.

Dr. Alex Buller

Talking to Alex there were some other twists to the requirements:

"Clinical notes include examination drawings and diagrams, and the variations to these are multiple. A system including freehand sketches was a must, so we wanted a system that could receive them from a tablet allowing us to draw right onto the computer screen. It's true that a picture can say a thousand words."

They came to Digital Fusion for some expert assistance with their partially developed FileMaker system, fondly named 'Orbit'. They'd built it themselves and the objective was to create a unique solution tailored to their specific workflow. We understood a couple of the key outcomes were to reduce the physical storage requirements and increase visibility of patient information in real time.

But there was more...

"Ophthalmology uses some specific information: although we're doctors we are usually more interested in how well a person can read the vision chart than their latest blood pressure reading. Working on our own system means we can have the specialised information we want, right where we want it. Most doctor-oriented software won't allow us to do that."

Each patient is moved through the various stages of a consultation: appointment scheduling, nurse assessment, completion of tests then consultation with a specialist, all of which is viewable by any of the practice staff ensuring continuity of care for the patient. By the time the patient reaches the reception desk to leave, all the information necessary for writing a clinical letter, billing, and recalling the patient at a later date is at the fingertips of Rosemary and Gwen who run the office.

So how has their life changed- has it all been worth it?

Alex's business partner Dr John Beaumont summed up their feelings on Orbit so far:

"Excellent."

Alex was new to FileMaker and had no computer training, but was able to follow the tutorials easily.

"I know what the practice wants, and how FileMaker works, so can interpret between the 2 professions quite confidently communication with Digital Fusion became very straightforward."

ESHB are the masters of their own destiny, they wanted to do things a bit differently so took a risk. And now they're reaping the rewards.

"With Alex as both project leader and on site support to myself and our team of two nurses and three admin staff, we have been able to make major changes rapidly. Sure, there have been some stresses and also still developments ahead. Having a system built to our needs and under our future direction can only be good. Dr John Beaumont

Head in the Clouds

Thu, 24 Nov 2011 17:04:00 +1300

Imagine being able to access your business systems from anywhere, at any time, not having to run your own server, worry about backup, or have a plan for when the server dies.

That's the promise of one of the biggest trends in IT right now, a buzz word called "Cloud Computing". Cloud computing promises to save companies a lot of money and hassle, but it seems that nobody can agree on exactly what it means.

While Cloud Computing has some specific technical meanings, we reckon that from your point of view as a business manager it pretty much means "having your stuff accessible over the internet", right?

And taking it one step further, it means not having to run your own server. When it's done right those 2 points alone make for some pretty compelling advantages.

Probably the biggest concerns are that because you don't physically store your own data it feels like you're giving up control what happens if the internet is down? What happens if the hosting service closes or disaster strikes?

These are valid concerns and can easily be addressed make sure you have access to frequent backups and can extract your data at any time. Make sure the service is robust and well setup.

But at the end of the day most hosting services are probably safer than your own in-house server. As Xero CEO Rod Drury put it "How safe is that data on your laptop right now?"

Cloud Computing is not just for web applications we're building more and more FileMaker solutions that are being hosted in our data centre, and we're working on bringing the advantages of cloud computing to the FileMaker platform as well.

My bet is that within a few years most businesses won't have their own servers, and one more barrier to your global domination will fall.

Printing Records With Different Output Designs

Thu, 03 Nov 2011 10:37:00 +1300

Most of the time when we print records in FileMaker, the output of every record appears pretty much the same, with similar formatting and design. But what if we want records to print with a completely different output design depending on the type of record? In this article we detail some of the various ways in which this can be achieved, and the pros and cons of each method.

Why would we want to do this?

It all depends on the situation. If you are printing a simple list of customers for example, then you would expect the appearance of information on each line of the output to be the same. By that we mean the same fields in the same columns with consistent formatting.

Above is an example of a standard report output. Fields appear in their respective columns, and all look pretty similar, nothing fancy going on here.

Consider now a different printing scenario. What if we were printing a test, where questions could be one of 3 different types? Some questions may be multiple choice, others a short answer, and others may be longer paragraph answers - with each record being a question. In this situation it makes no sense to have every record appear exactly the same, because that would make the test useless to the person looking at it. Ideally what we would want to do is have each type of question output in its own correct format, completely independent of the format of other question types.

Something like the above would be desirable, so how do we go about doing this output? Well, it so happens there are a few ways in which you can do this. We will discuss 5 potential methods, and the pros and cons that each method presents.

It should be pointed out at this stage that the article is only concerned with changing the display of records for the purpose of printing. Actually having different record displays from a data-entry perspective is a different topic (and a more complicated one for that matter!)

Method One: Conditional Formatting

Ever since the introduction of conditional formatting in FileMaker Pro 9, people have been searching for ways to manipulate its intended use, and this is no different :) Here we are going to make use of the ability of conditional formatting to alter a fields text size, font color and style.

What we are looking at here is our printing layout. On it is 3 different sections for the 3 different types of questions (colored so you can see them).

Yellow: Multiple Choice
Green: Short Answer
Blue: Long Answer

Each has been formatted as we wish for the question type to appear. Now it is simply a case of trying to hide the two designs that do not apply to the type of question for any given record.

Here is the conditional formatting calculation for the multiple choice section. In this situation we are telling the multiple choice related labels to change their formatting if the question type is NOT multiple choice.

We are setting the text color to white (same as background) in an attempt to hide any display of these fields. We also set the font point size to 1 in an attempt to make it so small it cannot be viewed. Finally we superscript that sucker in a further attempt to make it even smaller. The other question type fields have similar conditional formatting on them.

Sliding is set on all of these fields so that they slide up where possible. Because we make the multiple choice section so tiny in this case, the other sections will slide up.

Pros:

Easy to setup for simple output designs
Questions will slide up, though not perfectly (but close enough!)

Cons:

Limited to only textual objects that can have font size changed
Layout design can get messy depending on number of output types
Sliding issues get worse with the more output types
Formatting/alignment issues if wanting to make complex outputs

Method Two: Calculations

This method uses a single calculation field in which all of the output design is done. Whatever you can accomplish in FileMakers calculation engine is at your disposal, but that is all.

Here is our calculation to display each of the three different question outputs. As you can see it is fairly basic and we are pretty limited to what we can do here.

Pros:

Sliding works great
Perfect for simple text-based designs

Cons:

Can't use layout objects in design
Design is in the schema in a calculation, not on layout

Method Three: Web Viewers

Now we are beginning to get into some of the more "unconventional" methods. In this method we are going to be rendering each question type through a web viewer. The code that is used in the web viewer to render the question will change depending on the question type. We are using a Data/URL to render each question, substituting in information from the record into the html.

To look at the HTML code used, check out the example file. The html is rendered by the web viewer through the data/url syntax:

Pros:

Full power of the web at your disposal for rendering

Cons:

Sliding of web viewers is nonexistent so every question has same fixed height
More difficult to make adjustments to the design
Will potential render differently on mac and windows

Method Four: Hiding Portals
This method makes use of a number of different features such as relationships, portal filtering and preview mode niceties.

Bit of a mess isn't it! Well that is how it looks in layout mode when it is all built, but lets deconstruct what is going on here.

That's better. What we have here is 3 separate 1-row portals. Each portal corresponds to a particular question type, and in each portal is the design you wish each question type to have. Originally all the portals were stacked on top of each other but have now been placed side by side.

Every portal is using a simple self-join relationship to relate to itself and display its own record.

Each portal also has a filtering calculation on it to determine whether the contents should be displayed or not. Each portal is setup in a similar way as shown above depending on question type.

The end result is that only one of the three portals will show its output depending on the question type:

When all of the portals are stacked on top of each other, a cool thing happens. The two portals that do not show a record will not only show nothing, but they completely disappear from the output, its as if they aren't on the layout. This leaves the one remaining portal that is showing contents to be the only portal visible on that record. Note that data entry and browse mode is another story... but for printing it works great!

Pros:

You CAN use FileMaker layout objects in your design
Easy to design each different output type in its own portal box

Cons:

No sliding up of portals unfortunately, so every question has same height
Unstacking portals to make changes can get tedious

Method Five: Containers

This is perhaps the most extreme and convoluted method, but can deliver good results if the effort is put in.

Here we have created new layouts for each question type. Each layout contains the design we want to use for that type of question. For example, here is the Multi Choice layout:

A container field has been added to the table. The idea is that we populate this container field with an image that looks like the question design we want to output.

To do this, we basically go to one of the three layouts, take a picture of the layout, then go back to the container and paste in the results. We do this for each record until every record has an image of itself, then we output the images, simple huh!

Here is a simple script to populate the containers. As you can see, it loops through each record. For each record it then goes to that record on the corresponding design layout. We must enter preview mode to take the picture. The picture is taken simply by using a copy script step - if done in browse mode we get just the text from the record. We then return to the original layout and paste the image - now on clipboard - into the container.

A couple of things about this method:

Freeze window should be used to increase speed
Consider using a separate table (i.e. virtual list table) for the container field, as this method could increase the size of your database considerably if care is not taken!
Changes in rendering of images from version to version of FileMaker may mean this method is prone to breaking over time. This technique worked great in FileMaker 6, but has since been prone to giving blurry printed outputs in subsequent versions

Pros:

Can use FM layout objects in design
Will slide to a degree if done correctly (see below)

Cons:

Because images being used, can increase size of database if not maintained
Potential for blurry printing

A further note about sliding with container method

In order to get sliding to work properly using the container method, the page setup for each different layout being copied has to be set so that the height of the page is basically the same as the height of your body part on the layout. If this is not the case, then when you enter preview mode the resulting preview is your layout body part plus the rest of the full page. Upon copying this you end up with a large image which is the entire page. So ideally what you need to do is reduce the height of your page so that when you go into preview mode, you are only copying the question component and that only.

Custom page setups can be setup and will remain attached to a Page Setup script step on the mac, which means it can be used across any other mac computer without issue. I believe on a PC it should still run fine with the page setups scripted (at least it appears to in testing).

The container field on your layout should be set to have top vertical alignment and to slide up and reduce height of enclosing part. If done properly you can have some good results with sliding - with the added bonus that you have full control over designing your outputs using FileMaker layout objects - something none of the other methods offer.

If sliding is not a requirement then custom page setups for each layout is not required. You could copy the entire page. On your output layout, set the containers alignment to top, but set it to crop image to frame. This will leave just the top of the image visible (the top part should contain your question design anyway).

Conclusion of the methods

Which method is chosen really depends on the complexity of output you require and whether sliding is an issue for you. Each have their benefits but come with baggage. Ideally what we are striving for is a method that gives you full control over design by using FileMakers layout objects in your design, but can nicely slide up on printing. The container method has both these features, but unfortunately it comes with a LOT of baggage! We tend to prefer the calculation method for most things, though it does struggle with multi-columnar formatting so best to avoid that if possible.

A sixth method - Append to PDF?

While not covered in this article, there is the potential for another method that would result in a PDF document as the output as opposed to a printed form. This would be done in a similar fashion to the container method through record looping, but instead of creating the image and pasting into a container, the record on its own special layout would be saved and appended to a PDF document. The end result would be a PDF of all records in their own format, and this method would support sliding quite nicely.

Any other methods out there? Let us know!

If you have any other ideas or methods that you use to output different designs for records, we'd love to hear them, feel free to leave a comment outlining your method.

UPDATE: We have had 2 further examples submitted by Stephen Dolenski and Mikhail Edoshin. Please refer to the example files section below for more information and download links.

Example Files x3

Download Example File

This additional example file was kindly supplied by Stephen Dolenski from Fmforums.com in which he demonstrates another method using Bruce Robertson's virtual list technique.

Download Virtual List Example File

.. and finally we have another reader submitted example file from Mikhail Edoshin in which he demonstrates a variation of the portal hiding technique. Mikhail points out that the portals need not in fact be stacked on top of each other, yet can be placed on the layout one beneath the other, and they will slide up. The portal contents within do not slide but because the portals themselves will slide, this is a nicer approach as it lets you see all of the different portals without the need to move them out from under one another.

Also in his example file he shows how it can be combined with other methods such as calculation fields or regular field sliding to achieve the desired result.

Download Mikhail's Example File

Appendix: Virtual List Information from Stephen

Here is information supplied by Stephen in regards to how he built his virtual list implementation, very cool stuff!

The first step is in the Questions Table need to create a field

zVirtualList this is a calc that will generate the return, pipe and %% separated text

Let (
[
q = Substitute ( Question ; "ÃÂ¶" ; "%%" ) ;
a = Substitute ( Answer A ; "ÃÂ¶" ; "%%" ) ;
b = Substitute ( Answer B ; "ÃÂ¶" ; "%%" ) ;
c = Substitute ( Answer C ; "ÃÂ¶" ; "%%" ) ;
d = Substitute ( Answer D ; "ÃÂ¶" ; "%%" )

];

ID &"|" &Type &"|Q|" & q & ÃÂ¶ &

)

The script basically goes to the Questions Table sorts and loops thru each record adding that calc field to a global variable
then it goes to the VirtualList layout where the global variable is the rendered into rows and columns as needed.

the calculation in that table determines the output calculations needed for generating the reports.. including formatting indents etc.

The benefit of this you don't need to add calcs for visual output display needs in the schema of your data tables.

I haven't employed it in the demo but you could even reduce some of the data needed and really only take the ID of the questions in the global variable
and then thru the relationship pull the question and answer text as needed.

The virtual list will auto generate the necessary records as you have need for the question & response via the script, if your schema for your survey were more
normalized ( Question - Responses ) you could simply go to the response table and grab the records building the rows as needed, and printed reports
could be dynamic where you could have different versions of tests or questions and different responses or where the responses are in different orders.

The virtual list technique will allow you to better allow for page breaks.

You could add more complexity and have more question types or options in the question to create a Likert scale
http://en.wikipedia.org/wiki/Likert_scale

The %% conversion on the original question/response - is to preserve any returns in them in the final output.

FileMaker Go

Mon, 17 Oct 2011 17:01:00 +1300

If you are already using iPads or iPhones in your business or you can see just how handy they might be, then read on. If you're one of our many customers that uses FileMaker, then this is for you too.

A little over a year ago FileMaker released a purpose built mobile version of their database application: FileMaker Go.

With FileMaker Go, you can access your existing database system on your mobile device from wherever you are - be it in the office, on site, or on the road. All you need is an internet connection and you are ready to rock and roll.

FileMaker Go is packed with exciting features, such as:

Multi-touch gestures native to iPhone and iPad.
Capture and add signatures to your database right from the iPhone and iPad.
Add photos from your device to your database directly.
Has the same functionality as FileMaker Pro (i.e. add, modify, delete, sort records).
Convert data to a PDF and email it directly from your device.
Print your reports and forms using AirPrint in the latest iOS.

Most databases will run fine on FileMaker Go without any modifications. However, given the differences between the iPhone, iPad and a regular desktop computer, it is sometimes a good idea to provide different interfaces to your database specific to the mobile device you're using.

Digital Fusion has done a number of projects with FileMaker Go, and know what it takes to produce appealing and easy to use interfaces for the iPhone and iPad. If you think FileMaker Go sounds like the way forward for you, then lets talk!

Integrating Kiosk Mode into your Solution

Wed, 05 Oct 2011 15:27:00 +1300

Kiosk mode is a cool way to run a FileMaker database in a full screen environment where users are prevented from accessing the other functionality of the operating system. But what if you have a normal FileMaker solution and wish to use kiosk functionality in certain areas only?

In this article we illustrate how a typical FileMaker solution can be enhanced with a kiosk component for carrying out certain actions. We use the article example file to help illustrate this. We also give some information on what kiosk mode is, and things to watch out for when developing for it.

So what is Kiosk Mode?

The majority of FileMaker solutions run in what could be called a normal windowed environment. Upon opening a database, it appears in its own window on a mac - or within the FileMaker application on windows. Users are free to use the rest of their operating system whenever they wish.

Kiosk mode is a little different in that it prevents users from interacting with the operating system, and keeps FileMaker open as the central and only application they can interact with. The term "Kiosk" is used because the functionality resembles that seen on kiosk machines in places such as restaurants, museums and so on.

How do you create a Kiosk file?

A FileMaker file by default has Kiosk mode disabled. Enabling is done by using the Developer Utilities dialog that is build into FileMaker Pro Advanced.

Select the file(s) you wish to enable Kiosk mode in by using the Add button, select the output folder also. You then want to click on "Specify" under Solution Options.

In here you want to tick the Kiosk mode option. Upon hitting the "Create" button on the main dialog, a kiosk mode version of the file will be generated.

Developing or Using a Kiosk File

Now that the file has had kiosk mode enabled, it is important to know how to access your file for either the purpose of using, or developing.

FileMaker help has this to say:

Kiosk mode is ignored if the solution is opened by accounts with the Full Access privilege set, a privilege set that allows management of extended privileges, or a privilege set that allows modification of layouts, value lists, and scripts.

This factor is key. If you want to develop your file, always remember to log in as a [FULL ACCESS] user. If not, you will inadvertently end up with the file open in Kiosk mode if your login account meets any of the criteria above.

If your file does open in Kiosk mode, then you have to provide a means for yourself, or your users to close the file. There is no native close option, so without a button or some other means to close the file, you will be stuck in the file and have to resort to other means to get out of the file - such as force closing the file on Server, terminating the FileMaker Pro application via remote login, or restarting your machine. Neither option is really nice so be sure to provide a way to close the file!

Now with that all out of the way, time to get into the guts of this article:

The whole point of this article is integrating kiosk functionality into a regular non-kiosk database. We know that a kiosk-enabled file will open in kiosk mode under certain conditions, so having a single file is not going to cut it because we cannot guarantee all users will have the required account level to open in kiosk mode always.

The solution is to build a secondary kiosk file that links to your main database. The kiosk file is called into action whenever that functionality is required. The overall process is not too difficult, but there are a number of things to take into consideration.

A basic example: Kiosk file for taking tests

One great use of the kiosk functionality is for users of the database who are required to take tests. If someone is taking a test then you would not wish for them to have access to things such as their web browser! Kiosk mode would be great for this given it restricts the users access to these things. For anyone who has ever taken the FileMaker certification exam, we are aiming for a similar feel here.

We will use the attached example file as the basis for the example in this article, so it might be a good idea to download it if you haven't already.

Step One: Link your main file to your kiosk file

This part is achieved by setting up external data sources in both your main file and kiosk file. Each file should have a reference to the other file. One way to think of the kiosk file is merely an extension of the main file. It doesn't need to contain its own tables or data, it is purely for kiosk functionality for the main database.

Step Two: Setup a Full Access, and non Full Access user

This is done in the kiosk file. This file requires a [FULL ACCESS] account so you can modify the file if need be. However to make use of kiosk mode, it will require an account that is not full access.

Here we have a full access account, and another setup as data entry only. The "Test User" account is the one that will be used by everyone who accesses the file for taking tests.

Here, we have set the Kiosk file to automatically login as this Test User.

A very important thing to take note of here is how FileMaker will attempt to log a user into a file that opens from another file. Lets say a user is opening File B from File A. Upon launching File B, FileMaker is going to try and find a matching user account in that file, and if one is found, log the user into File B with that account. In this situation we don't wish for this to happen. The reason is that if a user is logged into File A with [FULL ACCESS], and there is a matching account in the Kiosk file, then they would log into kiosk with [FULL ACCESS] and as such, the kiosk functionality would not work - they would log into it as if it were a regular file.

For this reason, it may be good convention to make the [FULL ACCESS] username and password in the kiosk file something entirely different from any [FULL ACCESS] account in your main file, that way this scenario will not occur, and everyone will open the kiosk file with the Test User account.

Step Three: Enable Kiosk mode

At this point it would be a good idea to enable Kiosk mode on your kiosk file if not already. Refer to the start of the article on how this is done, and some of the things you need to be careful of once the file becomes kiosk enabled.

Lets take a breather, where are we up to..

At this point we have the following:

A main database file
A kiosk enabled file with [FULL ACCESS] and non [FULL ACCESS] users.
Kiosk file is set to login with non [FULL ACCESS]
Both files are linked to each other via external data source.

The next steps will involve initialising the kiosk file from the main file, some issues that can arise from this process, and how we can resolve them.

Setting the scene for what we want to achieve

In the main file we have a portal of 10 test records as shown below:

When a user clicks on a test record, we want that test to open in kiosk mode. The user would then fill out the test, and when they are done, they would close the test and be back where they started. Sounds simple right?

Step Four: Initiating the Kiosk File

The kiosk file is closed at all times, other than when it is being used. We don't wish for it to appear in the FileMaker Windows menu, so we open and close it explicitly when we begin using it, and when we are done.

The above script is run when the user clicks on a test in the portal. At this stage we are still in the main file. The script is passed the ID of a test record, which will eventually be passed to the kiosk file.

The last script step here calls a script over in the kiosk file and passes it a test ID. This is how the kiosk file is initiated.

Step Five: Correct setup of Kiosk File

A script has now been called in the kiosk file which is going to open the file and initiate it. There are some very important housekeeping things that this script must do first in order to ensure that kiosk mode is watertight and prevents the user from getting out of it.

When a kiosk mode file is opened, and there happens to be other databases and windows also open, then these other database windows are also visible whilst in kiosk mode. In fact, if you click on one of the other databases it will switch to it and take you out of kiosk mode temporarily.

From a testing perspective this is bad news, if a user can get to another database open, then they can reveal their dock and get into their browser and so on.

The solution here is to ensure that when you open up the kiosk file, that its window dimensions are set exactly to that of the screens dimensions, so that the layout takes up the entire screen real estate, thus hiding any other open window underneath.

(Note that prior to this, we had used scripts to hide and restore all other windows upon opening and closing the kiosk file, these work fine, but simply making the layout size full screen is much easier and less scripting!).

Here is the start of the initiation script in the kiosk file. The freeze window helps the startup go smoother visually.

You'll notice we do a very brief pause of 0.1 seconds. The reason for this is that when the kiosk file opens, it very briefly opens in a normal windowed mode, before entering kiosk mode. Without the pause, our next script step that sets the window position and size actually happens while it is still in a windowed mode, and this makes it near on impossible to correctly set the window to full screen size (due to issues arising with docks and such).

The pause gives us just enough time to enter kiosk mode, so that when we set the window dimensions to Get(ScreenWidth) and Get(ScreenHeight) We are getting the full dimensions of the screen.

Step Six: Closing Kiosk File

When you are finished with the file and wish to return to the main database, you need to close the file by issuing a Close File script step command. Because kiosk mode has no exit or close command, you need to provide a means of closing the file by way of button.

In this case our big finish test button simply closes the file.

Some things to watch out for

While kiosk mode is a great way to present a full screen layout to a user (for purposes such as taking a test) - it is not 100% secure in keeping the user locked out of their operating system. While developing this technique for a client solution I realised there are some applications out there that are able to dump you out of kiosk mode temporarily. The one application I noticed that did this was Tweetdeck. Whenever this application sent a notification of updates, the resulting popup caused kiosk mode to exit.

As you can see above, we have kiosk mode running the file, yet the dock became visible.

So you need to be careful if using this for things such as testing, the computer should be setup with no other applications running that might interfere.

Example File

Download Example File

NOTE: Test_Kiosk.fp7 file has been set to login automatically as a non-admin user for the purpose of demonstrating kiosk mode. If you wish to access the file to have a look inside, hold down the option (shift in windows) key while opening the file:

Username: Administrator
Password: (no password)

Simple Truncated Displaying of Long Lists (+more)

Mon, 22 Aug 2011 16:15:00 +1200

Displaying a long list of items on a layout generally means that the majority of the list is hidden from the user until they click into the field, with no feedback as to the size of the list. This article details a nice technique you can use to present the same list in a truncated style that gives live feedback on the number of items.

The Issue

Consider the field shown below containing a return-delimited list of values:

Here we have a list but the size of that list is unknown. For all we know it could contain just the twelve names shown, or it may contain far more. The only way at this stage to get an idea of the size of the list is to click into it and then scroll through the names. Doing this however will still not give you a very good indication of the number of items in the list.

One way to overcome this issue would be to give the user some kind of visual cue as to the size of the list. This would not only alert them to the fact that there are more items in the field than currently shown, but it also also tells them how many items there are.

This could be achieved in various ways, one of which serves as the basis of this article and which we think is rather cool.

The (+More) Display

For lack of a better name, this technique has been denoted +More due to the display it gives. Below is a picture of what we are ultimately going to end up with.

The last displayed line in the field now tells us how many more items there are in the list. In this case the size of the list is the 11 displayed items plus 66 more, giving a total list size of 77 items.

The effect is achieved by overlaying another object on top of the entry field. When the user clicks onto it, they are in fact clicking into the field underneath, and so can begin to edit the field contents.

Unstored Calculation Field

We have in fact placed a calculation field over the regular field, as shown below.

The calc field has been filled with white colour so as to completely obscure the underlying field.

The Issue of Anchoring and Field Resizing

One thing a user may end up doing on the layout is anchoring the field so that when the window is resized, the height of the field changes. Generally for lists this means more or less items are displayed when resized. The implications for our technique are that we need the display to dynamically update when the window is resized, so that the number of values shown, and the number of other items displayed is always accurate. All of this is taken care of using a special custom function we created to produce the display.

How Do We Define The Calculation?

The following single line of code is specified in the calculation:

truncateList ( Home::Values ; 18 ; "MainList" )

The custom function accepts three parameters:

theList: The actual list to display
lineHeight: The height in pixels of a single line of text in the underlying field being displayed
objectName: The layout object name of the underlying field being displayed

Let ( [
	totalValues = ValueCount ( theList ) ;
	objectHeight = GetLayoutObjectAttribute ( objectName ; "Height" ) ;
	numLines = Floor ( objectHeight / lineHeight) ;
	visibleLines = numLines - 1
];
	If ( 
		totalValues â¤ numLines ; 
		theList ; 
		LeftValues ( theList ; visibleLines ) & 
		TextStyleAdd ( TextColor ( "(+ " & totalValues - visibleLines & " more)" ; RGB ( 62 ; 108 ; 176 ) ) ; Bold )
	)
)

So what is the function doing? Well, the first thing it does is determine the total number of items in the list so we know how many to display and how many remaining we need to show.

Next, it uses the GetLayoutObjectAttribute function to determine the current height of the displayed field on the layout. The reason for this is that anchoring and layout resizing can affect the size of the field at any given point in time, which will in turn affect what we display.

With that information known, we can now determine the number of lines of text that the field is capable of fully displaying currently. This is a simple calculation of dividing the fields height by the height of a single line.

We also determine how many actual values the field can display if our +More line is used. This is always one less than the total number of lines the field can display.

We now have everything we need to formulate the display. If the field is capable of showing the entire contents of the list then we simply show the list. If however it cannot, then we are going to show part of the list with our +more line as the last line. This part of the function also adds some colour and style formatting to the last line.

So that's it, pretty simple really, nothing too over the top.

Putting it all Together...

The end result of the custom function and display calculation is a nice and simple to implement way to display a list of values to the users.

As the layout is resized, the calculation is re-evaluated and the display updated. The changes to the display are instant when the window is manually resized which is nice, as illustrated in this crude animation below:

Implications of using a Calculation Field

The technique we have shown makes use of an additional calculation field for the purposes of the display. What this means is that a new calculation field is required in conjunction with the actual list field. A bit of a hassle really, but there are some reasons why we ended up taking this approach.

The following part of the article details our initial thinking of implementing this technique, and why it failed causing us to revert to a calculation field. Hopefully this proves useful and you may get some cool ideas out of it - for this particular technique however it was not good enough (you can stop reading now if you just wanted the above technique!)

EXTRA: Looking for a Solution with no Additional Fields

When first tackling it, we looked for a technique that didn't require any additional fields in the schema. What we came up with was using merge variables to achieve this.

So we defined a merge variable called $$ListDisplay and overlaid it on the field. The next trick was to have the variable define itself. We wanted the display to change whenever the user resizes the window, so we decided to make use of the layout objects conditional formatting as a means to define the variable. Conditional formatting re-evaluates during a screen redraw, so we thought this was perfect!

On the merge variables conditional formatting we defined the following:

Basically it is the calculation definition but instead we are setting the global variable to it instead by using a Let statement within the conditional formatting.

When we jumped into browse mode and began resizing the layout window by dragging it larger, we noticed that it appeared to work perfect! The merge variable was refreshing live as we resized the window and everything was good with the world.

Fast forward a few seconds however and the world began to crumble before our eyes.

It turns out merge variables don't like to play ball when it comes to screen redraws, and their behavior in that department is quite erratic. Certain actions did not force the merge variable to refresh:

Changing window size using + control in top left corner of window
Actually editing the field contents (quite a critical one)
Upon layout first loading after file opened

The first two were killers, as to get it to work properly meant workarounds such as script triggers to force a refresh. In fact, it is worse than that as a simple refresh window step wasn't even enough, we had to introduce a brief 0.1 second pause prior to any screen refresh, no thank you!

The last one was peculiar too. Turns out the merge variable evaluated before the conditional formatting did, thus the initial view was an empty global variable and so no display. Only after the first screen redraw did the variable get initialized. This could have been remedied by setting it in the startup script but that still isn't very nice.

The moral is what might look great at first has to be tested to the point where it no longer looks so good :) It was a good thought but too many issues.

Example File

Download Example File

The Search for Fast Aggregates - Trial & Error

Sat, 13 Aug 2011 16:20:00 +1200

In the first of a two part series, we begin the search for a faster way to perform aggregates in FileMaker. We cover why aggregates can be quite a costly operation - especially on wide area networks - and use that as a jumping off point for finding a faster method.

What are Aggregates

An aggregate is a collection of items gathered together to form a total quantity. In FileMaker terms, the collection of items are records, and functions can be applied to the quantity to obtain useful information such as the sum, count, average, minimum and maximum to name a few.

Aggregates generally come in two varieties. First are summary fields. These are commonly used on sub-summary reports and are placed in the various layout parts to summarize records in parts of the report. Summary fields can also be used to summarize record values through a relationship/portal.

The second type are in the form of functions that perform the aggregate operation on its passed parameters. You can pass them a specified set of values as parameters, but a more common usage is to pass them a related field using a relationship. This performs the aggregate on the field value from all related records, returning you the summarized result. Examples of these functions are list, sum, average, min, max, and a couple of other less commonly used ones.

Sum ( Home to Contacts for All Contacts::Weight )

If you do enough development in FileMaker you will undoubtedly have come across both summary fields and aggregate functions and so are familiar with how they work.

So what's the problem with them?

Both summary fields, and aggregate functions are hugely useful and beneficial features of FileMaker, and run great on local databases. However if you have ever tried to perform an evaluation of a summary field or aggregate function over a local or wide area network, you may have seen the following dialog from time to time:

A real favorite among developers and clients. Why do we see this dialog more often than not on a remotely hosted solution, and why does it sometimes take longer to process than other times? The answer lies in what is actually happening when a summary field or aggregate function is evaluated.

The caveat here is that the entire set of records being aggregated is being sent from host to client (with the exception of container fields, summary fields and unstored calculations).

To put it in other terms, if you want to find an aggregate of a single field in any given table, then every single record you aggregate is downloaded from the host. You want to obtain the total of a field from 10,000 records, then hope you got some hard disk space handy cos they're all heading your way! The second you reference anything on any record, that entire record is sent to you.

It can be summarized (ha) in single sentence that Mark Richman gave in his Devcon session this year about improving WAN performance:

If you touch it, you own it

I can only assume that the reason for this is due to the fact all of the processing in determining the result happens on the client-side of things, and FileMaker doesn't exactly do partial transfer of records, it's all or nothing.

The implication this has on Aggregate Speed

So, now that we have established aggregate operations require the transfer of entire record sets from host to client, we can begin to identify some key factors in their performance:

Bandwidth speed, notably download speed
Latency between host and client
The number of records being aggregated
The size of the records being aggregated

All of these things serve to impede performance of aggregate functions. This article in particular will focus on the issue around entire records having to be sent from host to client. The performance hit is generally much worse the first time an aggregate is evaluated as it is at this point the records are sent. After that, aggregate functions are able to make use of the cached records on the client, so generally perform much better after that. However once you close the database and reopen, all of that cached data is lost, and you must re-download the records all over again to obtain aggregates.

Where oh where to begin??

This challenge has been somewhat of an obsession of mine for the past month. There have been numerous failed attempts to crack this issue and find a technique that would allow faster aggregate speed. While the technique proposed is by no means perfect, think of it more as an exercise in "can it be done", as we walk through the trial an error process of trying to find a faster method of doing aggregates.

I should point out that the technique found, and explained in this article is by no means perfect, in fact it does have some limitations which make it not a good candidate for replacing aggregate functions in some situations. However there are other situations where it would be well suited, and greatly outperform its summary field or aggregate function counterparts. Hopefully the remainder of this article not only gives you a possible technique you could apply, but also gives you some ideas of your own which you could develop, and explain some of the trial and error process behind looking for a technique :-)

So if everything we do in FileMaker sends us records, is there anything that doesn't?

This was the single most important question to answer to begin looking for a solution. The main bottleneck in aggregates is the downloading of records being aggregated. If we could somehow eliminate this aspect, it would give us a good chance of greatly improving aggregate speed.

There aren't a whole lot of things in FileMaker that only send us partial information about records, a couple of those identified were:

Certain functions, ie Get(RecordID), or Get(FoundCount)
Certain value lists

Get(FoundCount) was used in this article to carry out very fast count aggregate operations, but unfortunately it doesn't have any use for the other aggregate types. Get(RecordID) is handy to know about insomuch as obtaining it for a record will not send you the entire record. Perhaps not useful for aggregates, but there is potential there, and we are currently working with it to look for useful applications in the areas of fast record sorting.

The last item is value lists.

A Value List you say?

Value lists can be setup in a few various ways, such as custom values, using a list from another file, obtaining a field value either from all records in a table, or a subset via a relationship.

In testing all of these possible value list combinations, we found that there is one specific setup of a value list that outperforms the rest in terms of traffic sent between host and client, and that is a field-based value list using all values, in other words all records in the table.

When the above configuration of a value list is used, record data from all records is not sent from host to client, instead, it appears that a form of the fields index is sent instead, or perhaps just the field values for that specific field.

We are not entirely sure why, but hypothesize that the reason for this is no query is required from the client to obtain the value list from the host. FileMaker simply sees that the value list is for every record in the table, and decides it might just be faster to send the index for that field to the user rather than every single record (hopefully someone could explain exactly what is happening here).

In any event, the host is not sent entire record data, which is VERY interesting for us.

Okay, so now what?

Let's assume for now that our end goal is to obtain the sum of a field called Weight across every record in the table. If we take what we know now, the next logical step may be to build a value list of all values from the Weight field. We could then obtain the value list contents using the ValueListItems function. With a list of the weights from every record obtained, we could then figure out a nice way to sum each value in that list to obtain the overall sum, sounds simple enough :-)

Another road block, value lists don't play nice

The primary purpose of a value list is a means to assist in selecting data for data entry, perhaps via a drop-down menu or popup, or checkboxes. Because of this, there is no real need to duplicate values in a value list. If two records contain the same value in a field, then both values are not shown in the list. The value list simply combines them into a single entry.

This had major implications for us in devising this technique. If we have 10,000 records in our table, then we want our value list to contain values for every single record with a non-empty value in the field - duplicates included. It is no use to us if 100 records with the same weight value end up as a single value in the value list, because when we go to add up all items in the value list, we are not going to get the correct result.

The challenge now was to somehow modify the value list, so that we would obtain all values from the records, rather than just unique values.

Hey what about the above setup of a value list? We keep the first field as the field we want to aggregate, but we make use of the "show second field" and set it to our primary key field that we know to be unique. Surely this will now force the value list to keep same values in the Weight field as separate entries in the value list because we know each value in Contact ID is unique, right?

WRONG!

As we discovered, as soon as you introduce a second display field into any value list, be it "All Values" setup, or related field setup, this will trigger FileMakers knee-jerk reaction of sending you every single record in its entirety.

Back to a single field in the Value list, how to make it unique?

So with that option dashed, we were left with the question of how to build this value list using only a single field value. We know that the field must contain the weight field as this is what we are going to use to aggregate. However records with the same value have to be kept unique from one another.

The solution here was to build a new stored calculation field. This would comprise of both the weight and the contact ID. If we could make this field unique, and use it in the value list, then maybe there is a way at the other end to parse the contact ID out and leave us with just the weight values, which is what we are after.

Building the Value List calculation field

Ahh, another problem! The weight field is a number, but in our database our primary key field is also a number - a serial number. If we combine these two fields, how will we know what is what when it comes time to parse out the contact ID later on?

We looked at a number of ways in which we could possibly do this. Some involved building recursive custom functions. We could insert the Contact ID into the calculation wrapped in special identifying characters, which we could then identify later on and use to rip out the Contact ID. The problem with this is that recursion is itself a costly process and the overhead in recursing through a huge list may in fact negate any performance benefit from the technique overall. A better way would be to find a native FileMaker function to use which was non-recursive and fast.

For this particular situation we realised that the weight field will never contain any non-numerical digits, and the same applied for the Contact ID. Perhaps we could simply turn the contact ID into an alphabetical string rather than numerical.

For example, if we had a Weight of 100.5, and our contact ID was 1234, our calculation might begin looking something like:

Weight & Contact ID

which would give us:

100.51234

Not very nice, but if we did a simple number to character translation, what if we made it:

100.5BCDE

and then after we obtain the value list items, we could strip out the Contact ID section simply by using the Filter function:

Filter ( value ; "0123456789.-ÃÂ¶" )

This would leave us with just the numerical component, minus our contact ID whose only purpose was to make the entry in the value list unique. This is exactly what we did.

The first step was to build a straightforward custom function to carry out the translation of the Contact ID into an alphabetical string:

function: numToText

Substitute (
Value ;
[ "0" ; "A" ] ;
[ "1" ; "B" ] ;
[ "2" ; "C" ] ;
[ "3" ; "D" ] ;
[ "4" ; "E" ] ;
[ "5" ; "F" ] ;
[ "6" ; "G" ] ;
[ "7" ; "H" ] ;
[ "8" ; "I" ] ;
[ "9" ; "J" ]
)

Then, our value list calculation field looks something like:

Weight & numToText ( Contact ID )

We can now be sure that every record, given it has a unique Contact ID, will now also have a unique result to the above calculation too. This field provided the basis of our single-field "all values" value list!

Note that if your primary key is a combination of numeric and alpha characters you will need to pay more attention to converting the primary key into something non-numeric. You may need to translate your numeric components of the primary key into characters you know do not currently exist anywhere in your primary keys, that way you can be sure that any conversion from the numbers to characters will not end up in records having the same converted primary key value for this calculation.

A good time to summarize what we have done so far

This basically concludes the first part of this two-part series. In this article so far we have identified that the reason why aggregates are slow in FileMaker comes down to a number of factors, the main one being that any aggregate operation on a set of records requires all records to be sent from host to client. Number of records, size of records, bandwidth and latency all tie into this to impede performance.

In the article we sought to identify something in FileMaker which will let us obtain values from records we wish to aggregate, but without sending us the entire record contents. We found that value lists were a key candidate for this.

The value lists we tested yielded one particular configuration in which a much smaller amount of data was transmitted between host and client when the value list was evaluated. This was value lists that use a field value from a table, and are set to use "All Values" from that table.

We identified an issue with this particular value list configuration in that all common values across records are combined into a single value in the value list. Because our goal is to aggregate from all records, we needed each record in the table to be represented in the value list with its weight value, respecting duplicates in the list.

We then tried to achieve this using a value lists "show value from second field" option, but found that enabling this meant FileMaker transmitted entire record data, something we are trying to avoid.

The only option left to us was to build a calculation that was unique for every record, but contained the weight value we required. We needed to construct the calculation not only to be unique, but to be fast and easy for us to obtain just the weight value after the value list was evaluated.

To do this we built the calculation to be a combination of the weight value, and the records primary key field. To prevent mixup of the two fields, we first converted the primary key from a numerical value into a strictly alphabetical text string. This then allowed us later on to use the Filter function to easily strip out any non-numeric characters - such as the primary key - leaving us with the original weight values.

In part two:

This article turned out to be a bit too large to cram into a single article, so we have split it into two. This first part was identifying the issue, and constructing a path toward a solution.

In part two, we are going to illustrate the technique in action, introduce and solve a couple more issues, and give some performance results across both a locally hosted solution and a wide area network.

Link to Part Two - Implementation & Results

Example File

Download Example File With 10,000 Records (3.5mb)

Download Example File With 100,000 Records (36.4mb)

The Search for Fast Aggregates - Implementation & Results

Sat, 13 Aug 2011 00:00:00 +1200

In the final part of this two part series, we go into a little more detail about the aggregate technique we developed in the first article. We also carry out a number of comparison aggregate tests and present the results. We also try to address some of the limitations of this technique and ways in which you could try to work around these:

Link to Part One - Trial & Error

A very quick overview of where we are at

Summary fields & aggregate calcs require all record data to be sent from host to client
This makes aggregates on large datasets or large records slow
We found an "All Values" value list based on a single field, does not send all record data from host to client. Instead, it sends just that field value from all records (perhaps using the fields index).
Using this idea, we build a value list of values we want to aggregate, the idea being we evaluate the value list and apply an aggregate to the values, bypassing the need to download all the records.
These value lists like to combine unique values from records into a single entry. For this reason our value list had to be based on a special calculation whose contents was unique for every record, that contained the value we wanted to aggregate, and be easy for us to retrieve the original value when needed.

If you haven't yet read part one of the article then it is probably a really good idea to give it a look before reading this one, it will make this article make a lot more sense to you!

Retrieving the Value List contents

So at this stage we have built our special calculation, and built a value list based on that. The end result is we obtain a value list with 1 entry per record for every record in the table. Here is a snippet of what the value list looks like:

107.6JDBD
107.7BFHA
107.7DDGB
107.7FGIC
107.7HCFB
107.7HEFE
107.7HHEI
107.7IFCD
107.8BAGB
107.8BICE
107.8CJAF

You can see the numeric component is the weight field value we wish to aggregate eventually. The alpha part is a conversion of the primary key value from a number into an alphabetical string.

The value list contents is obtained using the ValueListItems function:

ValueListItems ( Get ( FileName ) ; "Aggregate_Weight All" )

With the contents of the value list obtained, we can use the Filter function to strip out the alpha-representation of the primary key:

Filter ( theValueList ; "0123456789-.&#195;&#130;&#194;&#182;")

You will note we have also kept some other possible characters that occur in a number, the negative sign and a decimal point. We also retain the return delimiters to keep the values as a list. The end result is:

Hey, this is looking promising! We now have a list of every Weight value in a list, and we obtained it by getting just the value, not the entire record, we are on the right track.

So how do we perform an aggregate?

We looked at a couple of ways to turn this list into an aggregate result, and decided that a custom function would be a great way to achieve this.

Our initial attempt focused simply on a sum aggregate. We began by running a substitute on the list, replacing all return characters with plus signs:

Substitute ( theList ; "&#195;&#130;&#194;&#182;" ; "+" )

Taking the snippet of the value list above, this gave us:

107.6+107.7+107.7+107.7+107.7+107.7+107.7+107.7+107.8+107.8+107.8

Which is now a simple FileMaker expression. We then ran this result through the Evaluate function. This function takes a text string as a parameter, and evaluates it as if it were a FileMaker expression:

Let ( [
  theList = ValueListItems ( Get ( FileName ) ; "Aggregate_Weight All" ) ;
  theList = Substitute ( theList ; "&#195;&#130;&#194;&#182;" ; "+" )
];
  Evaluate ( theList )
)

End result - well it "kind" of worked. With small lists it worked great, but we found the larger the number of items we aggregated, we were presented with a "?" result.

The reason for this is that FileMaker has a limit on the number of characters permitted in any calculation expression. According to the FileMaker websites technical specifications, this limit is 30,000 characters.

To get around this issue, we built a recursive custom function that performed the above operation on the list, but in blocks of 500 values at a time. So the first 500 values were summed, and the result of that was added to the sum of the second 500, the third 500, and so on until each block of values had been summed. This worked great, and was pretty quick too. For example if you were summing 10,000 values, the custom function would perform 20 recursions, each summing 500 values.

That's great for sum, but what about min/max/average?

Because we were using the Evaluate function, we realised that we could adapt our custom function to take a second parameter, that being the name of the aggregate function we wished to apply

This is the original version of the custom function. The overall list is broken into chunks of 1000 values aggregated at any given recursion of the function.

The first few variable declarations in the function grab the 1000 values, chop off the trailing return character, and replace all return delimiters with semi-colons (the character that is used as the separator for aggregate functions). At this point we end up with something like:

107.6;107.7;107.7;107.7;107.7;107.7;107.7;107.7;107.8;107.8;107.8

The AggregateFunction parameter is the name of an aggregate function, which is then placed before the above string. For example if the parameter was sum, we build the following string:

Sum ( ... the above string... )

Run that sucker through the Evaluate function, and you have your aggregate! The handling of blocks of values using recursion keeps the evaluation expression under the necessary character limit.

The "Average" aggregate function, a curly one!

Sum, Min and Max work great with this custom function. The reason is that if you add values, you get one total result. Similarly there is only ever 1 minimum and 1 maximum value in an overall list. It doesn't matter if you add the list up in smaller blocks, or compare blocks of values with other blocks to obtain a min or max value, the outcome is always the same.

Average is different however. To determine average aggregate, the total number of values has to be known, and the Average function determines this based on the number of parameters it is passed.

Consider this example, a list of the following values:

Average ( 1 ; 2 ; 3 ; 4 ; 5 )

The result of this calculation is 3. The average function first sums the values, and then divides it by the number of passed values to obtain the average. In this case, that is 15/3 = 5.

Now consider out implementation of the above custom function using blocks of values from the overall list. What happens if we split the list into two:

1
2
3

and

4
5

Using the custom function, we end up with the average of the first list being 6/3 = 2. The average of the second list is 9/2 = 4.5. The function would then combine the results into another aggregate calculation:

Average ( 2 ; 4.5 )

Which is deemed to be 6.5 / 2 = 3.25 , this is certainly NOT the expected result of 5 we were after.

The simple fact is the average function has to be aggregated in a different way. We first need to sum the contents of the list, and then divide it by the number of values in the original list.

Rather than try to make the current custom function any more complicated, we simply created a new custom function called ValueList_Average that simply runs the other Aggregate custom function as a Sum aggregate, then divides the result by the number of values in the list:

Enough technical mumbo jumbo, time for some results

For testing, we built an example file (see bottom of this article). The test file carries out three types of aggregate tests:

Summary fields
Aggregate Functions
Value List technique with our Custom Aggregate Function

For each type of aggregate, we test the sum, average, min and max aggregates. The testing is done on a Contacts table with 10,000 records. There are a total of 32 stored fields on the table, and each record averages about 0.6kb in size for a total table size of 5.9 megabytes.

Test One: File opened locally client machine

For the first test, we are eliminating network as a factor in testing. This will hopefully give us insight into the performance of the functions used, and the performance of the value list retrieval and processing.

As you can see, the results of the 3 tests are very similar. Multiple run-throughs of the test yield various aggregates reach the 1 second mark, but on following tests are under a second, and it is fairly random. This suggests the summary fields and aggregate functions are basically identical in speed. The higher frequency of more 1 second results for the value list implementation means it's basically the same speed, but maybe fractionally slower.

Speeds for all 3 tests are very fast with 10,000 records when the database is local because no records have to be sent over the network, so any overhead is a result of the aggregate methods themselves - of which there is very little overhead at all.

Test Two: File opened remotely over wide area network - 10k records

Here is the real acid test. The file has been hosted on a remote server and is being accessed over a fairly average New Zealand internet connection. In order to give a fair test for each method, the file was closed and reopened after each test. The reason for this is to clear the clients cache of downloaded records from the host.

So, what can we tell from these results? Well first thing to note is that these tests above were carried out in order of the aggregates shown. This gives us clear indication that the very first time an aggregate is evaluated, the high performance hit is taken first time, as all of the records are downloaded from host to client. As you can see, the summary and aggregate function tests yield pretty much the same time taken to download all 10,000 records.

The value list implementation on the other hand, was over 11 times faster than the other two aggregate methods. The performance gain in just aggregating using a value list is huge. The main reason is far less traffic is sent between host and client. We showed in the local file test that overhead of the actual processing of the values is negligible, so by reducing the major bottleneck of traffic sent between host and client, we have greatly improved the speed of the aggregate calculations!

Note that if the tests were run a second or third time directly after opening the file and running the first test, they were almost instant to calculate, the reason is the file had downloaded and cached all the records in the first 2 cases, and in the third the value list had been cached, so future tests were essentially working with local data.

Changes to weight values on the records prior to running a new test resulted in the summary field and aggregate function tests taking relatively the same amount of time. The value list option took slightly longer in this case because since the value list had changed contents, the whole value list is resent from host to client - however given it is pretty damn quick the performance impact is minimal.

Test Three: File opened remotely over wide area network - 100k records

For the last test we are going all out and bumping up the record count to 100,000. The file is opened under the same conditions as test number two.

Again, tests 1 and 2 take relatively the same amount of time, this time over 10 minutes, subsequent aggregates are much faster as they are working on the now cached records.

But once again we see the value list test has shone through, being over 10 times faster than the regular aggregate methods.

Another thing we did when running this 100k test was to fire up an application called Wireshark. This is a utility which lets you capture network traffic and keep track of packets transmitted and data flowing over the network.

We setup Wireshark to only capture data sent between the client and the host server, on FileMaker port 5003. Here is what we found:

For the aggregate function test we found that total packet traffic between host and client was 84,608 packets of data over the 10+ minutes. There was a total of 72,588,262 total bytes transmitted, which equates to a whopping 69.2 megabytes!.

And here are the results for the value list technique. Note the total packets transmitted was 5,372. That is close to 16 times less packets transmitted - and less packets means less overall latency and data transmitted. The total data transmitted was 4,430,483 bytes which equates to only 4.2 megabytes - 16.5x less data transmitted!

Wow, so it's faster that's awesome... and here's the bad news...

To this point we've been demonstrating a pretty ideal example. We have aggregated every record in the table. But seriously how often would you really want to do that? Perhaps there are some situations where you might want to do that, for example if you are using a special reporting table where you are generating records for reporting purposes.

More often than not however you want to aggregate a subset of a tables overall records. Consider aggregate functions, they work best when aggregating related records through a relationship, which generally are filtered to be a subset of the tables overall records. Summary fields also excel in sub-summary reports where they are tallying subsets of the records in groupings.

Unfortunately this value list technique does have limitations on how far you can take it.

The value list has to be stored.

This is perhaps the biggest limiting factor. Because the field used in the value list has to be stored, you cannot introduce complex filtering into your calculation based on globals, or fields from other tables.

Lets consider an example where you have a couple of global fields where you enter a date range. You want to sum all records whose date field falls within your chosen range. How would you achieve this?

Well first instinct would be to change your value list calculation to reflect this filtering. One cool and useful property of the value list, is if a record contains an empty value for the field used in the value list, that record is essentially omitted from the value list. this has no performance impact when it comes to our method which is great - if anything it makes the method faster as the a smaller set of values in the value list means faster processing times.

Back to the problem though. Our date range is specified in global fields, so we cannot use those in the calculation, which means we can't set the calculation result to blank if the record calls outside of the chosen date range, bummer!

Having said that, some filtering is possible...

Hard-coded filtering is possible though and works quite well. Consider a contacts table with 10,000 records. There is a status field that contains either "Active" or "Deleted". Further to that is a Country field.

Lets say we want to find the average weight of all contacts living in america whose status is active. To do this we would simply modify our value list calculation as such:

if ( Status = "Active" and Country = "USA" ; 
     Weight & numToText ( Contact ID ) ; ""
)

Here we have hard-coded a check in. If the contact is active and in the USA, we put a result in the calculation, if not the result is blank, and this record will not appear in the value list. Then we just run through the usual process of obtaining the aggregate from the value list.

This is nice, but very restrictive. For each subset of records you wanted to aggregate in this way, you would require a separate calculation field and value list to do so. Perhaps this might be fine depending on your situation, but it is quite limited.

Found sets and summaries

The other thing this technique is not, is a replacement for summary fields in sub-summary reports. This technique simply cannot be used to replace summary fields in this manner. Calculations just can't know about sub-summary parts in this way and if they could, in all likelihood the calculation would end up being unstored anyway, thus breaking at the value list stage.

So in conclusion....

We've talked about a lot in this article and the previous one. We've shown various aggregate methods, and why some perform slow over wide are networks. We've walked through the process of coming up with an alternative solution to the performance issue, and as a result came up with a technique combining a number of FileMaker areas including Value Lists, custom functions, and calculations.

We have also gone into detail about building an aggregate custom function to turn a list of values into the desired result. We then showed results of testing of each of the three presented aggregate methods, and showed that the value list method has huge potential for significant performance gains under very specific conditions.

Finally, we showed that this technique is most certainly not a perfect replacement for good old fashioned summary fields and aggregate functions. It can only be used under certain conditions, but if those match your situation, then you could be in for a good performance gain!

Example File

Please find attached an example file. This file was used for all the screenshots in this article, and is provided to help you fully understand what is going on in this article, and to let you experiment in FileMaker with this solution. In the file you will also find a couple of additional tests briefly touched upon in the article but not fully tested. These are in the area of aggregating a subset of the overall records in a table.

Download Example File With 10,000 Records (3.5mb)

Download Example File With 100,000 Records (36.4mb)

Readers Note:

Christoph Teschers pointed out in the comments that in the example files the tests do not yield correct results if negative values are used in the field being aggregated. He points out that this can be resolved by adding a - symbol into the Filter function, ie:

 Filter ( ValueListItems ( Get ( FileName ) ; "Aggregate_Weight All" ) ; "-0123456789.&#195;&#130;&#194;&#182;" )

Thank's for spotting that one Christoph!

Dissecting DevCon

Tue, 09 Aug 2011 15:27:00 +1200

I can't think of a better escape than a trip San Diego in middle of the New Zealand winter, which is exactly what Daniel and I did a couple of weeks ago as we headed off to the annual FileMaker Developer Conference (DevCon) - an annual geek fest in a nice warm place.

Actually Daniel went over a couple of weeks earlier and did a lap around Colorado on his bike first; to help me acclimatise I hired a convertible and drove down to San Diego it didn't take long to adjust.

Of course DevCon is all business and in the past we've always shown off our totally awesome Reactor plugin (interactive calendars and charts) and sold that to the other developers to cover our costs. This year was different, for the first time we didn't exhibit: what a stress relief that is - we could focus on building relationships and going to sessions, "networking" is extremely important of course, even if that means you miss the first session or two the next day, eh? We also managed to take in a ball game, a Spanish nightclub, and some serious outlet store shopping.

There was the usual ton of good technical stuff, but we also picked up a few other interesting nuggets, like:

In San Diego, "relationship building" finishes at 2AM.
FileMaker Inc thinks the future is mobile and cloudy. We do too.
There are QR codes* everywhere: from business cards to tee-shirts to buildings.
Daniel is World Famous...

Wherever we went during the conference people would automatically introduce themselves as soon as they saw Daniel's name tag. Could this be anything to do with his industry leading blog FileMakerWeetbicks.com which has thousands of readers every month? Just more world leading stuff from our crew.

FileMaker themselves had a big contingent at the conference, from top brass to engineers to sales people, so it was great to talk to them and get a feeling for how business is going and where it's going. They've done very well through the recent economic challenges, remaining profitable and continuing to grow. It's also quite clear that they understand what businesses want and where the technology needs to go - it's still the best platform for building business solutions that can evolve quickly.

FileMaker have really embraced the iPad and iPhone with "FileMaker Go" and that was a major topic of the conference, as was how to make it perform well when you host it in the "cloud" as they say, i.e. on the internet. Big highlights from the sessions included: some very clever techniques for making huge performance gains; user interface designs and techniques for iPad and iPhone; and a lot of more advanced techniques like the use of SQL in FileMaker than we've ever seen before.

All-in-all a totally enjoyable experience, full-on, but low on stress and I can highly recommend San Diego as a very agreeable place to be in the NZ winter. Next year it'll be in Miami: any takers to join us?

* In case you're wondering what QR codes are, they're those square black and white patterns you see on some things - you can "scan" them with an iPhone or similar, and the information held within could be anything from a web link to an entire vCard containing your contact details. Of course, you also generate these from within FileMaker and encode whatever you like. In the US we saw them everywhere including on the front of shops in the mall: so you can just point your phone at the shop and Twitter or Facebook a link right there.

Quake Updates Go Mobile

Thu, 28 Jul 2011 10:32:00 +1200

Anyone that knows our Stephen Baker knows at least two things:

He's Digital Fusion's first ever employee and after 13 years, he's still going strong.
He's a very, very smart cookie.

By day, he's a database developer, quietly dealing to some of our most tricky database intergrations, but by night, under the cover of darkness he's banging out some very sexy iPhone/iPad apps. His latest creation is "Canterbury Earthquakes".

This little beauty combines data from Geonet with the GPS on your iPhone or iPad. The basic features include a full list of all the "events" in Canterbury: size, date, time, location relative to where you're standing right now. This list can be filtered by date or aftershock size - a lot of us Cantabrians only want to know about the big boys!

There's the quake drum (although personally that's a little beyond my comprehension) and a map that at first glance looks like your kids have thrown their spaghetti sauce all over it. However, on closer inspection it is in fact the Quake Map indicating the size and location of all the events since September 4th.

But the best feature by far is the little arrow on the Aftershocks tab that takes you to a map of Canterbury with a pin to show where you are and another to show where the aftershock was located. Such a great feature for those that want to get a good sense of where the action is.

Canterbury Earthquakes is so simple, all the information you really want to know is presented in an easy to use format... thanks Steve!

Xero Meant Nothing Until Now

Fri, 08 Jul 2011 19:51:00 +1200

For a long time I was a bit of a doubting Thomas when it came to the online accounting package cleverly named Xero. I thought it was a good idea and was pretty impressed by what the NZ company based in Wellington were undertaking. But I guess I thought the product was still too immature to cover the full gamut of functionality required to replace our incumbent system and be a useful business tool.

Well, I'm here to say am a convert. We love Xero!

I started easy, convincing my partner Ben to switch his business over just before Christmas - I thought we could see how that went and decide whether it would be a good fit for Digital Fusion. I didn't tell Ben he was my guinea pig, I thought that might influence his perspective... Even so, I was expecting lots of the usual change-related frustrations - you know swearing, cursing, slamming of laptop lids etc. Ben does all that quite well usually.

Our accountants Wood Walton set things up and brought all the historic information across. I showed Ben how to log in and we worked out how to add his company logo and create a debtor invoice then I left him to it. I braced myself for impact and hoped for the best.

But there was nothing, not a peep. Next thing I know, he's loading in creditor invoices, creating new customers, receipting invoices, checking his aged debtors and bank balances. I almost felt... surplus to requirements.

The benefits of changing from a desktop-based solution to the web were obvious from the outset; it's always backed up, we can both view the information all of the time (which is a biggie given the amount of travel Ben does), and we can log in from any computer that has an internet connection. But there are extras, it as fast - really fast. I would estimate we have reduced our financial administrative time by about 75%. The automatic bank feeds means that your cash position is always up to date and bank reconciliations are a joy.

Given the success of Ben's transition, the plan was to switch Digital Fusion over at the start of the new financial year, however the events of February 22nd brought our plans forward somewhat and we have now been using xero for several months.

Digital Fusion may appear a simple business to the untrained eye, but there are some real hooks when you scratch beneath the surface. We operate in both Australia and New Zealand, use 4 different banks and need Xero to integrate with Nutshell our CRM.

For the most part Xero has stepped up, much like in Bens business we are seeing big reductions in admin time (now that Elaine and Xero have bonded), and the sharing of information between admin and management is easy - we all just log in and look. We have had a few difficulties with inter-bank transfers, the extraction of specific information is not always simple, and I am not sure we have come to terms all of the reporting as yet.

These are pretty minor in the big picture though and overall the gains are huge... bigger than Texas. So if you have been considering Xero and you are on the fence, get off it. This has been a really big win for us for relatively little effort.

Aussie, Aussie, Aussie

Tue, 07 Jun 2011 10:42:00 +1200

We think those Aussies are kind of the same as us.... don't be fooled they are most definitely not!

Craig and I are just back from a few invigorating days in Sydney courtesy of NZTE as the culmination of the Path to Market program timed to coincide with CeBIT. There were about 20 in our Kiwi delegation and the 4 days played out like a mini conference.

We heard from both business and government, ex-pat Kiwis and die-hard Aussies. We were both impressed and surprised by the parochial attitude of each of the speakers when advocating for their respective state or city... the competitiveness is intense!

Inspiring speakers such as Rebekah Campbell, former manager of Evermore and founder of posse.com, Paddy O'Brien, general manager of SmartPay Australia and Ian Clarke CEO of Fronde were some of the highlights.

We made some new friends including Matt Steele, Business Leader for Apple in Sydney (like). Apple are really keen to build relationships with companies who create productivity tools that are winners on the Mac platform. We have plans afoot to do presentations at some of the Apple stores in Sydney. Companies like us are the enablers, through our custom software we can demonstrate how business can operate on the Mac platform efficiently and effectively.

We ate lunch at the top of the KPMG building in one of their swanky boardrooms... after a brisk 3 hour hike across the city in heels (me, not Craig) in the rain.

We went to the opening of CeBIT at the Opera House, The Cure were playing on the same night next door... wish we went to that instead. I shouldn't complain really, we did get to listen first hand to Australian and German politicians in a mutual love fest.

This article wouldn't be complete without a mention of Lee Sinclair and Carole Wright from CDC and NZTE respectively - what a couple of super-cool chicks. They have been helping us and other affected Christchurch based businesses through some challenging times - it was great to spend some time and get to know them better over the past few days.

So overall what did we learn about doing business in Australia?

If you wanna be taken seriously in Australia, you have to be there... this was the message from EVERY speaker. Rebekah Campbell described how she repatriated Evermore to Australia, going as far as making them *Australian citizens. She evolved them through the touring and pub scene, and it meant they were accepted by Australians as one of their own right from the start. Clever girl.
Australian bankers are just as boring as bankers in New Zealand
Each State in Australia should be treated as a separate market, based on their uniquely different personalities and cultures. In Sydney business is old school and done through contracts and networks where as Queenslanders are more entrepreneurial, straight talking and consider your word as your bond.
They know how to work the stats, every state in Australia has the largest, fastest, biggest or best of something in the ICT sector.
The opportunities in Australia are huge, maybe as big as Texas, maybe even bigger than Texas. Johnny Cates from Aveva was one of many to tell that wireless business is exploding.

The best part about Australia is - they want us. Almost every speaker was encouraging us to set up shop in their city, state or technology park. Offering introductions, free office space and a beer on Fridays.

So Craig and I are not quite changing our All Black for the green and gold just yet, but we are incredibly enthusiastic about the possibilities in this market that's right on our doorstep.

Build a Navigation System Part Two - Taking it Further

Mon, 06 Jun 2011 00:00:00 +1200

In part one, we built a basic navigation bar made from repeating fields. In this followup article we take the formatting of the navigation bar further by introducing highlights. We also adjust the construction of the navigation, and introduce a custom menu implementation that can be used in conjunction with, or in place of the navigation bar.

Some changes to the construction

In order to make some of the new features of this upgraded navigation bar easier to manage, we are going to make a few minor tweaks to how the navigation bar is constructed. These changes may slightly affect how the navigation bar looks from earlier versions, but these can easily be overcome with field formatting options.

On first glance it may look very similar to the navigation bar in part one, but there are a couple of changes that are shown better in layout mode.

Here, the icon repeating fields have been increased in height so that their bottom border touches the top border of the label repeating fields, creating a single block with no gaps in between the icon & the labels.

Another change less noticeable, is that each icon/label combination has been created as a separate series of objects to the other repetitions, better illustrated in the following picture:

Recall in part one that we specified the icons and labels as single fields that were set to show all repetitions. There are a few reasons for this change which will become clear later.

One final change is that each repetition combination of icon & label are grouped into a single object.

Highlighting the Selected Screen

The navigation bar in part one gave no visual indication of which screen the user was currently viewing. It would be nice to highlight the screen being viewed so the user is not left guessing where they ended up, it also provides some solid feedback that the users click on the navigation bar was successful.

What we are going to do then is to implement some highlight formatting as shown below:

In the picture above you can see two things happening:

Background filled white
Text label changed to black & bold

Both of these formatting changes have been done by using conditional formatting.

The decision to use conditional formatting over calculation fields that make use of text formatting functions is a conscious decision. The downside to the conditional formatting is that if you ever want to change the fill color or label changes, then the change has to be applied to all navigation bars (or a single navigation bar that is then replaced on all layouts). This could become a nuisance but we are going on the assumption that once set it won't change. The fact the entire navigation system is based on globals means changes aren't that difficult to make as it is a case of copy/pasting a new navigation bar on all layouts that use it.

The reason why calculation fields that use text formatting functions were not used for the formatting, is because the goal here is to keep the navigation system entirely global. By having it all global based, there is only the need for a single Navigation table occurrence on the graph, and navigation bars can easily be applied to new layouts without additional setup. Global calculation fields are not suitable in this situation as they do not refresh as desired.

The conditional formatting calculation

NOTE: This section is somewhat irrelevant now after a discovery by Peter Bouma after the article was written. Please see the extra section at the bottom of this article before reading this section as it may save you some time, cheers :-)

In order to highlight any particular screen in the navigation bar, we require a calculation that can be evaluated that is generic, but at the same time evaluated differently for each repetition. How can a specific repetition evaluate differently from another repetition you ask? Well the answer lies in using a FileMaker function that will give a different result depending on which repetition evaluated from, and there are two prime candidates:

Get ( ActiveRepetitionNumber )
Get ( CalculationRepetitionNumber )

Both of these are concerning repeating fields so have potential. Get ( ActiveRepetitionNumber ) however is of no real use because that only evaluates when the user has placed the mouse cursor inside of a repeating field. Because we have disabled browse mode access into our navigation bar, this function will never evaluate.

The other possibility is Get ( CalculationRepetitionNumber ). This function will return a repetitions number when evaluated from a calculation context of that repetition. There is just one problem here, our navigation bar is composed of non-calculation repeating fields. The solution then is to make it based on calculation repeating fields :)

In the picture above you can see two new fields added to the Navigation table - Labels Display and Icons Display. Both are global calculation fields set to their equivalent non-calculation field.

'Scuse me Egon, you said using global calc's was bad

Now, we mentioned earlier that we chose not to use global calculations to do the formatting, yet here we are using global calculations, what gives? Well in this situation they are fine because they will be used only for the navigation bar, and not formatting. Global calculation fields will re-evaluate when fields they reference are changed, but they will not change however when non-field references in them change, such as the current layout name.

Here is the new navigation bar above, based on the global calculation fields. Note the label definition is not visible because the label text is white by default.

Now that the navigation bar is based upon global calculations, the Get ( CalculationRepetitionNumber ) field can be used in the conditional formatting. Here is the conditional formatting calculation we can apply across all repetitions:

Get ( LayoutName ) = Navigation::Layout Names[Get ( CalculationRepetitionNumber ) ]

It is simply comparing the current layout name, to the layout name contained in the Layout Names field repetition that corresponds to the current repetition being evaluated. For example, the 5th repetition in the nav bar will compare the current layout name, to that in the 5th repetition of the Layout Names field. If it is a match, the conditional formatting will evaluate to true.

Changes to make applying conditional formatting easier

Recall earlier the changes made to the navigation bar construction. These were done for various reasons, but one is to make the conditional formatting of the nav bar simpler.

The grouping of the label and icon repetition means that we can apply a single conditional formatting property across the single object that takes care of both the highlight and the text formatting, no need for a separate condition for the label and the highlight.

This single conditional formatting condition can be applied across the entire navigation bar in a single hit, because it is generic across all repetitions. The text formatting of bold & text color will have no affect on the icon, and the fill color will be applied to both icon and label which is what we want.

Note that in order for the highlight fill to work correctly, your icons should be transparent png's or gifs.

A custom function for conditional formatting

While not strictly necessary, we have used a custom function in the example file to contain the conditional formatting calculation. This is a nice illustration of how custom functions can actually reference fields - so long as those fields are able to be evaluated from the context of where the custom function is evaluated from.

Clickable area in the Navigation Bar

Now that the text label and icon are touching borders, and they are grouped, we can just make the clickable button the grouped object. This removes the need for a separate button overlay which was used in part one. The reason it was used there was because our icon and label were not aligned and the same size as the clickable area. Because of this change, we can remove the button overlays, reducing the complexity of the navigation bar.

Building Navigation into a Custom Menu

With the navigation system completely global and already built, building it as a custom menu is a piece of cake.

To do this, we use a technique demonstrated in a previous article called Hide Custom Menu Elements Dynamically.

The technique consists of creating menu items in a new menu. The name of each item is set using a calculation to a specific repetition of the labels repeating field. Because this is global based, it should work across all layouts where the menu item is used.

When building a custom menu, there is no ability to soft-code item names making use of the menu items position in the menu. For this reason, each menu item's name is set from an explicit repetition of the Labels field. Because we may not know exactly how many repetitions of the navigation bar a solution may use, we accommodate for this by adding as many menu items as possible. Menu items will not display if their name evaluates to blank. This is the technique outlined in the article above, and for this reason we can be sure that the menu will only display items for just those that are in the navigation bar.

The picture above illustrates how the custom menu is built, and the fact that unused repetitions contain no name, and so will not be displayed in FileMaker 11 (in FileMaker 10 they display as blank, but have no action).

The menu item name is set via the Labels repetition, and the action attached is a script that is passed a corresponding repetition number.

We have gone from using a single script step for the navigation, to putting that inside a script. The reason for this is one of future-proofing. If we ever wish to do post-navigation stuff, this lets us add that in later without having to redo the navigation bar or custom menu.

The above shows the custom menu in action.

If you had a solution with lots of screens, you could choose to do away with the visual navigation bar entirely, and simply use the custom menu aspect for navigation.

Final Thoughts

With a few tweaks and additions, we have made the navigation bar more responsive visually, by having it give feedback on which screen is selected. We also extended it's use by building a custom menu to supplement it. All the while the navigation system has been kept global and generic so that it can easily be applied to layouts with zero modifications required.

Extra: Global Calcs not required via Peter Bouma

As always the readers of these articles come up with some great suggestions and contributions after the article is written and this case, Peter Bouma from Amsterdam, has discovered that in fact the need for global calculations that contain the icons and the labels is not necessary for using the Get ( CalculationRepetitionNumber ) function as I had assumed.

He has found that this function still evaluates correctly even from the context of a layout-based calculation such as the conditional formatting calculation. Even though the original labels and icons repeating fields were not calculations, the function still is able to obtain the relevant repetition via the conditional formatting calculation set on each repetition.

End result is the solution can be made simpler than I originally presented, you can do away with the Icons Display and Labels display calc fields entirely and just keep the Icons and Labels global fields for your nav bar, awesome!

Example File

Download Example File

Example File Extra from Stephen Dolenski

Stephen Dolenski of Ocean West Consulting, Inc. has provided an awesome adaptation of the original example file for this article. In Stephen's adaptation, he has added functionality to allow the navigation bar to toggle between each screens various list & form views, as well as a dashboard view, very cool, and I encourage you to check it out also.

Download Stephen's Modified Example File

Super Fast Record Display in Descending Creation Order

Sat, 28 May 2011 18:00:00 +1200

When FileMaker sorts records it happens on the client machine. Consequently, sorting can be a very painful process for users over a slow connection to a database.

This article is all about a technique for presenting records to the user in their descending order of creation. The main focus is showing the records in a portal, but with the extension of the application to other areas such as list and table view. It is not concerned with any other type of sort on records.

Some Background Context on Sorting

Sorting records in FileMaker can be a painful and trying process. Record sorting occurs on the clients machine, which means that FileMaker has to send all records that are asking to be sorted over to the clients machine. Now, if the client is using a database locally, then this is not really an issue unless dealing with massive data sets.

The problem with sorting is in the accessing of a database over a connection, be it local or wide area. Records have to be transferred from database to the client over this connection in order for the sort to occur, via FileMaker server or otherwise. Thus, the speed at which records will sort depends upon factors such as:

Client Download speed
Server Upload speed
Number of records being sorted
Size of records being sorted
Additional things, ie SSL encryption

All of these factors ultimately combine into a nasty experience for a user who just so happens to unwittingly sort their thousand record found set over a dodgy connection :)

What About Unsorted Records?

Unsorted records on the other hand do not require this en-masse transfer from server to client. FileMaker is smart enough to only send the client the records that they are accessing or viewing at any given time.

As an example of this, consider viewing a portal that is showing 100,000 related records. When unsorted, the database sends the client those records visible on-screen in the portal at that time. (I have a suspicion that a few more records beneath the visible ones are also sent, as a kind of buffer in anticipation of the user scrolling, can someone confirm this?)

When the user begins to scroll down the portal, additional records are requested by the client, and the database sends these records back to the client so that they can be displayed. If a user grabs the scroll bar and navigates halfway down the list of records, then when they release the scrollbar, only the records now visible are sent to the client.

Basically, records are sent from the database to the client on a need-to-access basis such as needing to view, manipulate or use them in some manner.

Here's the Situation...

We want to be able to present records in their descending creation order. We know that actually performing a sort on the records is going to mean the transfer of those records from database to client, and that this can potentially be very slow. We also know that displaying unsorted records is very fast because only a fraction of records are sent from database to user, those being the ones the user needs to see or use.

Thinking...thinking....thinking.... aha !

If viewing unsorted records is so fast, lets just leave them unsorted.

But hang on a second....if they are unsorted then how the heck can they be presented sorted?

Think Opposite

The solution we came up with was to keep records unsorted, but have a calculation on each record that is capable of determining their opposite records primary key value. When we say opposite, we mean the record that is at the same position as the current record, but at the other spectrum of the found set. Here is a visual interpretation of what we mean for a found set of 100 records:

Record #	Opposite Record #
1	100
2	99
3	98
...	...
99	2
100	1

The first record in the found said is paired with the last record, the second with the second-last, and so on.

This is why the method works only for creation order of records - because it is easy to know exactly what the opposite record is. If we wanted to sort based on a field value with this method, then the opposite record could potentially be anywhere in the found set, and a physical sort would be required.

This technique makes use of the fact that even unsorted records have a default sort order, that being creation order. We are simply making use of the one "sort" that is fast in FileMaker, and reversing it :)

How it Works

This technique makes use of a few interesting properties of some Get functions in FileMaker, namely the Get ( FoundCount ) and Get ( RecordNumber ) functions.

Both of these functions operate in context. The value they return depends on where they are evaluated from, and on which record they are on. Their value also depends upon the number of records in the found set.

Take list view with a found set of 1,000 records. Get ( FoundCount ) is going to give you a value of 1,000, and Get ( RecordNumber ) will change depending on the record you are on, starting from 1 for the first record in the found set and incrementing.

Even cooler is these functions can operate from the context of a relationship (and thus portal) when added as an unstored calculation to the table being displayed.

In this portal above, there is an unstored calculation field which is on the related table, set to Get ( RecordNumber ). The calculation is being evaluated from the context of the portal, and so each portal row is returning the record number through the relationship. The found count shown is also being shown by displaying an unstored calculation field that contains Get ( FoundCount ) through the relationship.

We have written articles in the past making use of these properties which you can refer to for more detailed information about how this works:

Portal Formatting
Alternative to Count() Function

The Point is This:

If we have an unstored calculation field on the related table, and that calculation is able to determine its record number, and the total number of records in the found set, then it should be a case of applying a simple calculation to determine its opposite records number.

Refer to the table example shown earlier. We require a calculation that can take a records number, and determine its opposite records number. Here is what we came up with:

Let ([
  RecordNum = Get ( RecordNumber ) ;
  Total = Get ( FoundCount )
];
  Mod ( Total - RecordNum ; Total ) + 1
)

When this calculation is put in an unstored field on a table, the result is the opposite records number in the found set. Try it! Put it on a table view layout or a portal, sort records, modify the found set... the calculation changes live to reflect the opposite records number, and because it is using native FileMaker functions that require no data from the records, it is very very fast.

Next Step: Grabbing the Primary Key Value from the Opposite Record

Knowing the record number of any given records opposite is fine, but it is pointless if we cannot then obtain data from that opposite record for displaying and editing purposes. Fortunately FileMaker gives us another amazing function to do exactly this - GetNthRecord

GetNthRecord ( fieldName ; recordNumber )

The function takes two parameters. The first is the field name from which we wish to obtain the value. The second is the record number. Hey cool! We know exactly what the record number is that we want to obtain! GetNthRecord works both through a relationship, and on a layouts found set, so can be used in both situations.

And Here is the Beauty of it...

The greatest thing about GetNthRecord is that when requesting a field value from a specified record, the database will only send the client that specific record only.

So lets return now right back to the beginning and go full circle. An unsorted portal will only send the client the records being viewed. Similarly GetNthRecord will only send the client the records being requested.

Lets say that we create a calculation that obtains the primary key field value from that records opposite record. If we then use that calculated "opposite" primary key in a relationship to the opposite record, we can then place fields from that relationship either in a portal or on a layout for display and editing. In doing so, some very cool things happen. Firstly values are displayed in an apparently descending creation order from most recently created to first created. Secondly and even more cooler, is that the database is only sending the user two records for each portal row being displayed:

One for the actual record for each portal row, and
One for the opposite record being displayed via calculated relationship

This dramatically cuts down on the number of records that would otherwise need to be sent from database to user. In a portal showing 1,000,000,000,000 records if 20 portal rows are being displayed, then 40 records are sent to the user, not 1,000,000,000,000 ! Now I realize showing that many related records in a portal is highly unlikely, but it illustrates the point nicely :-)

Think about most portals that show records. A user is highly unlikely to want to scroll through them all, generally they might be interested in the first bunch of records. Perhaps they know the "general" area of the record they want, so make use of the scroll bar to jump to that area, or perhaps they want to jump right to the end. The point is, having the client download every single record is pointless if the client has no intention of looking at or using every single record. This method sends the user "almost" exactly what they want - that being what they are looking at.

At this point we would recommend you check out the example file at the bottom of this article for a working example of the technique, where you can get stuck in and find out how it is all put together.

What this Technique Isn't...

This technique is not actual sorting, and while that fact serves it well in terms of its speed and efficiency, it is also a source of limitation if you are intending on taking this idea and jumping right in to implement it. There are a number of things you need to beware of.

First, the records are not sorted, and what you are seeing visually in a portal, or in a list view, is not the actual record you are on. The technique basically gives the illusion of sorted records, but you must beware they are not. If you allow users to delete records, you need to script for the deletion of the real record the user thinks they are deleting. While we haven't detailed how this works in this article, it isn't a stretch to say that it is definitely possible given the fact each record is aware of what its opposite record is, and you can establish a relationship to its opposite record quite easily. Through the use of scripts, and custom menus, you could easily control correct record deletion.

Areas Where We See This Being Used:

Prime uses we see for this would be things such as displaying records in a portal where the most recently created record is the one that is at the center of the users focus, ie:

Invoices
Transactions
Interactions with Customers or Contacts
System log entries
Records assigned # based on order, ie Jobs

We would love to hear of situations where you think you could make good use of this technique, and if you end up taking it further or build on it, we'd love to hear about it and share it here, Cheers!

EXTRA: Easy Editing of Records

A few hours after this article was released, I had the thought of grabbing just the opposite records primary key value, and using that in an additional relationship for the purposes of easily editing records in a portal or layout using this technique. The example files have been subsequently updated to show this change, and the article has been tweaked to reflect it.

Example File

Download Example File With 10,000 Records (3.3mb)

Download Example File With 100,000 Records (32mb)

Xero to Hero

Thu, 26 May 2011 15:56:00 +1200

For a long time I was a bit of a doubting Thomas when it came to the online accounting package cleverly named Xero. I thought it was a good idea and was pretty impressed by what the NZ company based in Wellington were undertaking. But I guess I thought the product was still too immature to cover the full gambit of functionality required to replace our incumbent system (MoneyWorks) and be a useful business tool.

Well, I'm here to say I'm a convert. We love Xero!

I started easy, convincing my partner Ben to switch his business over just before Xmas - I thought we could see how that went and decide whether it'd be a good fit for Digital Fusion. I didn't tell Ben he was my guinea pig, I thought that might influence his perspective.... Even so, I was expecting lots of the usual change-related frustrations - you know swearing, cursing, slamming of laptop lids etc. Ben does all that quite well usually.

Our accountants Wood Walton set things up and brought all the historic information across from MoneyWorks. I showed Ben how to log in and we worked out how to add his company logo and create a debtor invoice then I left him to it. I braced myself for impact and hoped for the best.

The benefits of changing from a desktop-based solution to the web were obvious from the outset, it's always backed up, we can both view the information all of the time (which is a biggie given the amount of travel Ben does), and we can log in from any computer that has an internet connection. But there's extras, it's fast, really fast. I would estimate we've reduced our financial administrative time by about 75%. The automatic bank feeds means that your cash position is always up to date and bank reconciliations are a joy.

Given the success of Ben's transition, the plan was to switch Digital Fusion over at the start of the new financial year however the events of February 22nd brought our plans forward somewhat and we've now been using Xero for several months.

Digital Fusion may appear a simple business to the untrained eye, but there's some real hooks when you scratch beneath the surface. We operate in both Australia and New Zealand, use 4 different banks and need Xero to integrate with our in-house CRM.
For the most part Xero has stepped up, much like in Ben's business we're seeing big reductions in admin time (now that Elaine and Xero have bonded), and the sharing of information between admin and management is easy - we all just log in and look. We've had a few difficulties with inter-bank transfers, the extraction of specific information is not always simple, and I'm not sure we've come to terms all of the reporting as yet.

These are pretty minor in the big picture though and overall the gains are huge... bigger than Texas. So if you have been considering Xero and you're on the fence, get off it. This has been a really big win for us for relatively little effort.

Making Your Windows Self-Aware (Mac Only!)

Fri, 06 May 2011 15:33:00 +1200

In this article the term "self-aware window" refers to a FileMaker window that can know in real-time whether or not it is the currently selected window, and act accordingly. We introduce a technique for allowing individual windows to calculate this, and some examples of what windows could do with that knowledge.

NOTE: This technique only appears to work on a Mac - sorry Windows, back in the box!

There are a number of different wee bits and pieces that are used to tie this all together, so lets get stuck in with the first...

WindowNames function

One of my favorite functions, it can do some pretty cool things. In this case, one of the unique properties of the WindowNames function is that the currently active window name always appears first in the list of window names returned by the function. To try this, you can open a few windows, and put the following function in the data viewer:

WindowNames ( Get ( FileName ) )

When you click from window to window, you'll notice that all though the function returns all window names open for that file, the one you click on is always moved to the top of the list.

Now, why is this useful? Well, for one it gives us a test we can perform. If we can get each window to independently evaluate the WindowNames function, and compare its own window name to that which appears first in the list, then we can tell whether or not that window is currently selected.

Web Viewers

It's no mystery that web viewers can do a lot more than just show web pages as may have been originally intended. Over the years they've been used for all kinds of things, from simply displaying a web page, to used in plugins, to used as a substitute for calculation fields, the list goes on.

In this situation we are going to make use of the fact that a web viewer is essentially an on-layout calculation engine. What sets the web viewer calculation engine apart from say perhaps a regular calculation field, or conditional formatting, is that the calculation in a web viewer is always evaluating. That is to say, a web viewer does not require a manual or automatic refresh of a window to update its display.

Consider conditional formatting, or an unstored calculation on a layout, these things in order to update their display require you to resize the window, run a refresh window script, enter into the field, and so on. Something must trigger the refresh. Web viewers are different. They do not require a refresh in order to update, which is great for us!

Better yet, a calculation in a web viewer will re-evaluate even when:

The web viewer is hidden on the layout
The web viewer returns no result
The web viewer is not in the active window
The web viewer doesn't reference fields at all - only functions

All of these points make the web viewer calculation engine a perfect tool for us. If we can put our WindowNames checking calculation in a web viewer on layouts, then each window can become "self-aware" because the calculation will re-evaluate when the current window changes

Putting it all together

The idea here is that we put a check in the web viewer to test whether the current window is the selected one. We do this by comparing the Get ( WindowName ) function with that of the first value returned from the WindowNames function. If they match, then that window is the currently selected window

As a point of note - you can have two windows with the same name, so pay attention if using this technique that the window names appear unique otherwise it may yield incorrect results.

An Example Use

Below we have a calculation defined in a web viewer:

What we are doing here is constructing a data URL. This format allows us to display text direct within the web viewer instead of referencing a web site URL.

Most of the calculation is concerning itself with setting up the data URL and formatting the resulting text, but the key line in all of this is:

If ( windowSelectionStatus ; "Selected"  ; "Not Selected" )

Here we have defined a custom function called windowSelectionStatus. If it returns true, we have the web viewer display the word "Selected", otherwise "Not Selected". No prizes for guessing what the windowSelectionStatus function does :)

Here is the calculation for this custom function, and it's basically what we have talked about to this point. We obtain the first window in the list of WindowNames, and compare it to the current windows name, returning true if they match, false otherwise.

Every web viewer that evaluates this calculation is acting in its own window, and so the result of the calculation and thus the subsequent value shown in the web viewer is completely independent of any other window - and it updates in real time!

If you were to place a web viewer on your layouts, and open up multiple windows, you would see the web viewer change its resulting text in real time as you click from window to window, without the assistance of a refresh.

So What's the Point?

While this is all nice and well, it's pointless if there is no real application for the technique. Perhaps you just want to show something different in the web viewer depending on whether the window is selected, in which case that's fine, the technique to this point is fine.

This article came about because we were working on an issue in a client database, where the user was getting into a record locking situation when having multiple windows open on screen at once. Often, they would end up with two windows open on the same record, either a data record, or their Home record in an interface/data solution. The user may be modifying a record in one window, only to change to another, and upon trying to edit the same record, be presented with the following dialog:

The message is pretty self explanatory as to what has just occurred. Perhaps we can make use of this self-aware window functionality to allow windows to tidy up after themselves when deselected.

Having a Window Commit Itself

Wouldn't it be nice if when a window was deselected, it was able to commit its record right away. That way, the record is not left uncommitted and subsequent locking errors can be avoided.

Now, in order to commit a record, we have to run a script, and in the web viewer we only have access to the calculation engine, so at this time we have to make use of a plugin that is capable of running a script from the calculation engine. There are various plugins out there which are capable of doing this so the choice is yours. In the example file supplied with this article, we include examples for Digital Fusion's Reactor plugin, and MonkeyBread Software's MBS Plugin.

Ideally we want the window to commit itself when:

It becomes the deselected window, and
The record is in an uncommitted state

Well, we already know how to test for the first case. The second case can be tested for using the Get ( RecordOpenState ) function - any result that is non-zero means we should run the commit.

The CommitWindow custom function

Below is the new custom function defined called commitWindow. As you can see, it is setup in a similar way to the earlier function to test a windows active status.

There are a couple of points of difference. The first is that we also check Get ( RecordOpenState).

The second is that the result of this function is a call to a plugin function capable of executing a script. The above is taken from the example file, so you can see a couple of different examples of function calls for the plugins used. In both cases the script run is called "CommitRecord".

The function is then placed inside the web viewer as a calculation. Because we are only concerned with running a script, and not with what the web viewer shows, there is no need for the function to return anything worth displaying in the web viewer, its job is to run a script and that's all it does.

Why not just use an onTimer?

Now where is the fun in that! While it is true you can set an onTimer running in all of your windows to monitor the windows active status and commit accordingly, there are issues!

Firstly, onTimers require the script to continually be running after defined intervals. In order to safely commit the record fast enough before the user tries to modify in another window, the internal has to be sufficiently low. The smaller the interval, the more frequently the script runs. Perhaps this doesn't add overhead, but the idea of a script running in every window every 5 seconds doesn't sit well with me :-) The web viewer method - while requiring a plugin - is more passive. It only executes the script when it absolutely needs to, and in doing so, the effect is instant.

Secondly, there is a peculiar bug/feature/issue with onTimer scripts that we noticed in writing this article.

Each window has its own onTimer running, that is known. When the script is eventually run, "parts" of the script evaluate from the context of the window from which it was triggered, however other parts of the script execute in whatever the current window is. We haven't fully explored this, but in trying to produce an onTimer method, we found that each window can successfully determine whether it is the selected window via an onTimer. So, each window is able to evaluate windowNames, and Get(WindowName) from their own context.

The problem however comes when the Commit Records/Requests step is run. This script step is always run from the context of whatever the current window is.

So, if you have two windows open A & B, and you modify a record in window A, then navigate to window B, the onTimer that runs in window A will determine successfully that it is uncommitted, and no longer the active window, but the commit record step is executed in the newly selected window B - confused?

To put it another way - in order for an onTimer implementation to work, the script must first navigate back to the window from which the script was executed, run the commit and then navigate back to the window that was (and now is) the currently selected window! (couple that with the fact script is still continually running...)

In short, yes you could work a solution using onTimer, in conjunction with the windowNames first value method. Both are possible, but both come with their own pros and cons, choose wisely :)

We have included an onTimer scenario in the example file so you can see this issue in action, and perhaps modify the file to work correctly, have a play and see what you come up with.

Example File

Download Example File

Integrating Image Maps in FileMaker

Fri, 29 Apr 2011 16:04:00 +1200

In this article I demonstrate how you can use image maps with web viewers in FileMaker. In doing so, you can display images that, when clicked, can report the coordinate chosen back to FileMaker to handle in whichever manner you wish.

What are Image Maps?

Wikipedia says that an image map is a list of coordinates relating to a specific image, created in order to hyperlink areas of the image to various destinations. The intention of an image map is to provide an easy way of linking various parts of an image without dividing the image into separate image files.

Can we use them in FileMaker?

Wouldn't it be great if we could use an image map in FileMaker. This would allow us to display an image, and have FileMaker know the exact location on that image the user clicked. In knowing this information, you could then program a response, perhaps via a script.

Lets establish an example

Below is a photograph of a farm, with the paddocks on that farm outlined. We have a database that is used to manage the farm and the paddocks on it. Each Paddock is a record in the database.

Wait, so why not just use buttons?

Well, we could (but c'mon where is the fun in that!). A common method of making a clickable image in FileMaker would be to place the image direct on the layout, or in a container, and underly buttons beneath the image that when clicked, run a script.

Here's the problem - paddocks are not necessarily rectangular, circular, or oval shaped. As such, to underly buttons beneath a paddock, you must use a combination of many buttons or shapes to replicate the paddocks shape, then group those objects and turn them into one large button.

Furthermore to this issue, what happens if in future the paddock fence-line changes? What happens if two paddocks become one? What happens if more paddocks are added? Basically it all boils down to the fact that the layout is going to have to be changed - not a very nice soft-coded solution.

So why is an Image Map Different?

If the image of the farm were presented as an image map, then there would be some feedback as to the location on the image that was clicked. We could then leave it up to FileMaker to determine what to do with that coordinate such as find out the paddock chosen, and run an appropriate script. In doing so, there would be no need for hard-coding of buttons required.

Lets do it then!

Okay enough talk, lets get into the nitty gritty.

Here is some very basic html code to establish an image map. We have specified an image called "Map.png". It is given width and height dimensions in pixels. The image is established as an image map via the use of the "ismap" attribute. the html file is called Map.html.

Pretty simple, around 6 lines of code. Image maps are widely varied and can include more fanciful features, but for this example we are sticking to the basics. In the example file we offer a slight variation on the above but basically its the same code.

Using the Web Viewer

Web Viewers are the tool in FileMaker that allow you to display web content on a layout. Given image maps are used on the web, it only makes sense that we will be using the web viewer. Basically we require to display the above html file in the web viewer, this can be achieved in a few ways.

The first is via a web server. If we host Map.html and Map.png on a web server then we simply need to point the web viewer to that URL and the image map will be displayed. Of course, this method requires the database have access to the web server location, either via local network or over the internet. In the demo file, we give an example of this method.

The second option for those not averse to using a plugin, is to use Reactor plugin, or any other plugin capable of hosting up web content. The reactor plugin is perfect for this because it is exactly what it was designed to do.

For those not familiar with the Reactor plugin, what it does is emulate a web server within a plugin. You can pass any file to the plugin using ReactorFeed function, and it will in return give you a URL which you can then place in the web viewer to display that content.

We normally use ReactorFeed for things such as displaying PDF documents or images within a web viewer, and it does a great job. In this situation we are going to pass it Map.html and Map.png, and it in turn gives us a URL to use in our web viewer.

We have included a reactor example in the demo file for those readers who have Reactor installed. If you do not have Reactor, you can download a demo copy Here.

An attempt at a third method

The above methods outlined require either a plugin or access to a web server hosting the content. Both methods work great, but in developing this technique we aimed to provide an all-encompassing self contained solution. Unfortunately we failed (someone take up the challenge!) but I thought I would mention that method here.

We attempted to base-64 encode both Map.html and Map.png and serve it up in the web viewer by using a data url. While we were able to display the map in the web viewer, we were unable to obtain the selected clicked coordinate via this method, more on what I'm talking about later...

The "isMap" image map and how it works

We are using the isMap attribute to setup an image map on the image. How this works is when the user clicks on a location on the image, the chosen coordinate in pixels is appended to the end of the URL of the page.

When we defined the image map code, you'll notice we gave it a width and height in pixels. This defines the area of the image. The top-left corner of the image is given the x,y coordinate of 0,0, and from there the coordinates extend out to all four corners of the image.

When the user clicks on a point on the image, the x,y coordinate is placed on the end of the link.

For example if the URL to the image map page is:

http://www.imagemap.test/Map.html

and the user clicks at coordinate 100,200 then the resulting URL of the page becomes

http://www.imagemap.test/Map.html?100,200

Grabbing this Coordinate in FileMaker

It all boils down to the GetLayoutObjectAttribute function. This FileMaker function allows you to obtain the source url of a web viewer. Thus if we are able to obtain the source URL of the web viewer after the user has clicked in it, then it will tell us the URL with the coordinate appended! Brilliant!

GetLayoutObjectAttribute ( "WebViewer" ; "Source" )

How can we tell the user has clicked?

Web viewers generally offer up content that the user interacts with independently of FileMaker. What we need is a way for FileMaker to know the user has just clicked on a position in the image map.

We can achieve this now using script triggers that were introduced in FileMaker 10. Specifically, the onObjectEnter script trigger can fire off a script to run when the user enters an object - including a web viewer. This is how we are going to go about obtaining the source URL of the web viewer after the user enters the web viewer.

It's all a matter of timing:

Now, if we were to run a script triggered by onObjectEnter as soon as the user clicks into the web viewer, the problem is that the script runs before the users interaction with the web viewer occurs. So if we run a script that tries to evaluate the source of the web viewer, it's just going to tell us the original URL because the users click on the image map has not yet been registered. What we need to do instead is delay our script from evaluating the source URL of the web viewer - finally a great use for the onTimer script step!

Setting up the onTimer delay

As you can see in the image above, we set an onTimer to run .25 seconds after the triggered script is run. The delay you specify depends upon various factors, mostly related to the speed of the web server hosting the image map, or your internet connection (Rector being local tends to be faster). We find that a quarter of a second is ample time for the URL to update, and short enough to not be noticeable by the user.

The process of events that occurs from the moment the user clicks into the web viewer is:

User Clicks into web viewer
onObjectEnter triggers a script
The script installs an onTimer for a main script to run
The users click now happens, and the web viewers URL is updated
Now the delayed script runs, and is able to reference the web viewers new updated URL
The script will run a commit record step to put the user back out of the web viewer, ready for the next click

And there you have it!

So that's basically it. You have an image with a width and height in pixels, and by using script triggers, onTimers, and various FM functions you can obtain the x,y coordinate clicked. From there, you can parse out the coordinates from the end of the web viewers URL, and do with them whatever you want, great.... but is that the end?

Well not really. Once you have the coordinates the question now becomes what do you do with them? Being able to obtain the coordinates is nice, but unless you can do something meaningful with them, whats the point.

Lets go back to the example:

So lets now return to the example originally established, and see if we can figure out a nice way to select paddocks using this technique.

Recall that each paddock is a record in the database, and we know the x,y coordinate clicked, but we don't yet know which paddock the user clicked in. What we now need to do is establish a method of defining paddocks in terms of their coordinates on the image map, and then evaluating the chosen coordinate to determine if it falls within one of the paddock boundaries.

Defining a Paddock by its boundary coordinates

Paddocks are shapes, and shapes are called polygons. A polygon is simply a shape with many sides (according to the weetbicks big book of mathematics).

Where two edges meet, you get a corner, and a corner is defined by an x,y coordinate. We can define a polygon by a series of x,y coordinates, obtained by traversing the polygon in a clockwise (or anti-clockwise) fashion, and grabbing the coordinates of the corners.

Lets assume for example we have a paddock defined by:

(x,y)
0,0
20,0
20,20
20,0

This defines the paddock as a perfect square, 20x20 in size on the image map. The paddock begins in the upper left corner at 0,0. From there, the upper right edge of the paddock is at 20,0. the lower right corner at 20,20, and the lower left corner at 20,0.

We can define paddocks in this fashion regardless of their shape or location simply by plotting the corners of that paddock in order. In the example file, these are recorded on the paddock records in return-delimited lists of both the X and Y coordinates respectively.

Determining if a coordinate is within a polygon

So now we have a paddock defined as a series of x,y coordinates. What we now need to determine is whether a given x,y coordinate lies within the boundaries of that polygon.

For more information about this technique, you can check out this great site that explains how the process works, and gives a C function of how to achieve it. Also please check out the acknowledgements at the bottom of this article for those who helped me take this C function and turn it into a FileMaker custom function.

PointInPolygon function

In the example file you will find this function which can tell you if a given coordinate is inside or outside of a polygon. the pointinPolygon function treats coordinates that fall on the edge of a polygon as outside. There is also an alternative function provided that treats boundary coordinates as inside the polygon. The functions have been provided by Nick Orr and Jason DeLooze respectively.

Let the Paddocks Decide

With the function now in place, we can let each paddock determine if they were selected by adding a calculation field to each record, that calls the custom function, testing its own coordinates against that of the selected coordinate.

Each paddock now has basically a flag set that determines if it was chosen or not. What you do with that information is up to you. In the example file, I am grabbing the ID of the chosen paddock, and using it in a relationship to that record for editing purposes, but the possibilities for this application are huge.

Further Applications or Improvements

Hopefully this article has proved enlightening and helpful for people. This is very much a work in progress and one of the goals of this article is to get peoples minds thinking about how this technique can be used and applied to FileMaker solutions, and also how it can be refined and improved upon, I would love to see peoples examples of how they can take this technique and run with it. Possible applications or improvements might include:

iPad applications (in fact this was the reason for its development in the first place)
Improved image mapping techniques, highlight entire polygon chosen
Figuring out how to make this scaleable - allowing you to resize web viewer & image and have the record coordinates gracefully scale (right now this is a fixed image size and paddock coordinates are also fixed to this scale)
Using it for navigation
Writing a script that lets you click on the image map to create your "paddock" records easily
Generating an image based upon polygon coordinates in records (could then be served up with Reactor)
Writing a Reactor black-box function to essentially "do-it-all" - the possibilities here are limitless depending on how much javascript and various other web technologies you know!
Figuring out how to make an "all-in-one" solution without the need for a web server or plugins, perhaps you can crack the base-64 encoding solution...

Example File

Note: Example file updated on 4/5/11 to fix an issue in alternate ptInPoly function.

Download Example File

Readers Contributions: Douglas Adler

Douglas Adler from HomeBase Software has taken some ideas and techniques from this article and run with them. He has revitalized an earlier image map technique he had worked on and put a new spin on it.

I encourage you to check out his great article outlining what he has done over at his blog site here.

Thanks Douglas!

Readers Contributions: David Wikstram

David Wikstram from CamelCase Data has produced this awesome demo file showcasing his extension of the image map idea. In this example, David has taken it to the next level, using SVG technology to not only produce a clickable image in a web viewer, but he also demonstrates how you can very easily setup your polygons on the image - with live visual feedback! In addition to this, using SVG has allowed David to do other cool things like have the selected polygon highlight itself upon selection. Check it out, you won't be disappointed!

A Huge Thank You to the Following:

In preparing for this article, I sought the help of a number of people and would like to thank them here:

Stephen Baker - Digital Fusion Ltd
Stephen is the one who deserves the most credit for this article as this was a technique he developed when working on a client solution. Steve has been the main source of reference in writing this article and also helped in writing the pointInPolygon function, cheers!

Sam Sehnert - Digital Fusion Ltd
Initially we were using a very simple image map which gave no visual feedback of the position clicked. Sam - our resident javascript guru - provided the alternative image map code to display the pin icon in the location clicked, thanks!

Nick Orr - Goya Pty Ltd
After struggling to write a FileMaker version of the pointInPolygon function (I was working off a C code example), I put the word out on the FmExperts mailing list for help in writing a FileMaker equivalent. Nick was quick to jump in and help out and spent a great deal of his own time in helping to write the final pointInPolygon function, which is the one you see in the example file. I can't thank Nick enough for his willingness to help out - he is a real class act!

Jason DeLooze
Jason responded to the call for help on the FmExperts mailing list and came up with another cracking version of pointInPolygon which has been included in the example file. Jason's version is slight different to Nicks in that it treats points that fall on the edge of a polygon as inside, rather than outside, so thanks to Jason you have two choices in which function you wish to use, thanks Jason!

Mikhail Edoshin, Mike Duncan and Leland Long
These 3 top blokes all answered the call on FmExperts and offered advice, suggestions, and even had a crack at the pointInPolygon function too, huge thanks for taking the time to help out, cheers!

DF's World Famous Blogstar

Tue, 19 Apr 2011 16:02:00 +1200

Back in December, Digital Fusion launched FileMaker Weetbicks - a section of the main site dedicated to FileMaker articles of a technical nature. The idea behind creating the site was to give something back to the wider FileMaker community, and act as a resource for developers of all skill levels. Digital Fusion has a number of certified developers and a large pool of collective knowledge, and so this was a way to make that knowledge accessible to other developers around the world.

Since its launch, the site has turned out to be a huge success and exceeded our expectations, with daily visitor numbers averaging over a hundred. The comments left on article posts suggest that people are enjoying the content and learning new techniques along the way which is great to see.

While the content may not appeal to most of our clients, if you have ever dabbled in FileMaker then you may like to check it out - www.filemakerweetbicks.com

Remembered

Tue, 19 Apr 2011 15:51:00 +1200

The night after the earthquake, out checking on the state of my father's house, I started thinking about friends and acquaintances that I hadn't checked up on. I happened to be driving at the time past a street where I knew an ex-colleague lived. I hadn't seen him for some years, and the suburb was largely untouched, so I put it out of my mind.

It was some days later that I heard that Stephen Wright had started work only the month before in the CTV building, one of two relatively modern buildings that suffered total collapse in the earthquake. Officially listed at the time as 'missing', the conclusion was sadly inevitable when the TV showed pictures of a small tightly-packed pile of still-smouldering rubble.

Stephen was marketing manager at MagnumMac throughout the eight years I worked there, and only recently left to work in a similar role at CTV. In doing so he went to work again for his previously employer at MagnumMac, now part-owner and managing director of CTV, Murray Wood.

Murray was a man for whom the term 'larger than life' might have been invented. Despite a healthy personal modesty, he was a local legend in multiple communities. A lifelong musician, many years as a musical director at TVNZ, leading light in the Mac community, businessman and mentor, in recent years he returned to the TV fold as a mover andÃ¢ÂÂdare I say itÃ¢ÂÂshaker in local television at CTV. As the online tributes and the 1,000+ attendance at his memorial service proved, Murray was the kind of guy who was known by just about everybody.

Two of us here at Digital Fusion had the honour to work with these two men in our careers. They will be remembered, and sorely missed, by many many more.

Suppressing Self-Referencing Auto Enter Fields

Sun, 17 Apr 2011 08:07:00 +1200

Using an auto-enter calculation on a field is a great way to populate its contents when other fields are modified, including itself. But what do you do if you want to use a calculation that references itself without having it trigger its own auto-enter calculation? The answer lies in thinking outside the calculation....

Setup aof an Example

In the attached example file I have concocted a scenario which illustrates this dilemma, although there are many situations where this may become an issue.

Here is a basic table of products. Each product has two rates. In another table I have a product ID field with a value list attached displaying products from the products table. The idea is that when a product is selected, the rate field is populated automatically with the correct rate from the products table. The rules are:

If product has a Rate 1 use that, otherwise
If product has a Rate 2 use that, otherwise
We wish to leave whatever is in the rate field at the time unchanged.

Here are some examples of what we expect when a product is chosen:

There is one more key rule for our Rate field and that is the rate must be able to be modified once a default is auto-entered

Building an auto-enter calculation for the rate field

With all of the required rules known, the first attempt at formulating an auto-enter calculation looked as follows:

Let ( [
TriggerField = Product ID ;
RateOne = Home to Products for Rate Auto Entry::Rate 1 ;
RateTwo = Home to Products for Rate Auto Entry::Rate 2
];
Case (
not IsEmpty ( RateOne ) ; RateOne ;
not IsEmpty ( RateTwo ) ; RateTwo ;
Self
)
)

Note that auto-enter calculations will trigger and re-evaluate when any field that they reference within the same table context is modified. We wish for the rate to change whenever the product ID is changed, however the product ID is merely a means to lookup the correct rate, we don't actually make use of the product ID itself in the calculation results. In order to have it trigger the auto-enter calculation we simply need to reference. This has been done using a Let statement where we set the Product ID field into a trigger variable whose only purpose is to fire the auto-enter calculation into action.

The rest of the calculation is straightforward and follows the rules defined. If there is a Rate 1 use it, otherwise if there is a Rate 2 use that, otherwise leave the field contents unchanged, as evidenced by using Self.

When this auto-enter calculation is used, everything appears fine.. Modification of Product ID fires the auto-enter, and the correct rate from the products table is entered.

But what about the final rule allowing modification of the rate?

This is where this auto-enter calculation fails. Recall that an auto-enter calculation triggers when any of its referenced fields are modified in the same table context. Well this even refers to its own self. If an auto-enter calculation references its own field, then any modification in the field itself will cause itself to auto-enter. Sometimes this can be a very useful behavior depending on your situation, but sometimes this can be a real pain in the arse!

If we were to attempt to modify the rate field now, then because our auto-enter calculation references Self then the auto-enter is re-evaluated. Given the current calculation, it is going to relookup the associated rate from the Products table, thus nullifying any modification we tried to make to the field - the auto-enter is essentially hijacked by our lookup from the products table, preventing any modification to the field by the user. The only time the user is free to modify the rate is if there is no associated default rate in the Products table. Again, this may be what you want, but sometimes it isn't.

So, how do we fix this?

Finally the answer, bit of an anti-climax perhaps after all of this build up :) If an auto-enter calculation triggers when any field it references in the given table is modified, including Self, then is there anyway to reference Self from somewhere other than the table context? The answer is of course yes, and can be achieved using a Self-Join relationship.

Here is a simple self-join relationship matching on primary key. Essentially a self-join is a 1-to-1 relationship with itself.

Now, we make a slight tweak to the auto-enter calculation:

Let ( [
TriggerField = Product ID ;
RateOne = Home to Products for Rate Auto Entry::Rate 1 ;
RateTwo = Home to Products for Rate Auto Entry::Rate 2
];
Case (
not IsEmpty ( RateOne ) ; RateOne ;
not IsEmpty ( RateTwo ) ; RateTwo ;
Home to Home for Self Join::Rate Modifiable
)
)

The change is made on the last line. Instead of directly referencing the field using Self, we instead now reference it via the self-join relationship. By referencing self outside of the calculations context, we are able to use the value of Self, without having it trigger its own auto-enter calculation which is exactly what we want. Now, the only field in the auto-enter calculation which will trigger the calculation is Product ID.

Back on the layout, if a product ID is chosen the rate will be auto-entered if there is one. Once done, the user is free to then modify the rate to whatever they wish, and because the auto-enter calculation no longer directly references Self from the calculation context, it can do so without having the value revert to the default rate.

Script Triggers

Yes, this could have been achieved with a script trigger on the Product ID field, but sometimes a script trigger may not be applicable, able to be used, or easy enough to work with. Because the auto-enter is tied directly to the field itself, then wherever the field is used the auto-enter simply works. With the script trigger it must be attached to every place the field is used in the solution.

I'm not saying a script trigger is not a good way of achieving this type of result, it certainly is and could be used. However I think auto-enters as a means to set a default value into a field, or enforce data entry rules on a field is still a great technique and very useful - especially in solutions Pre-FileMaker 10.

Final Thoughts:

Auto-Enter calculations are a great method for enforcing data-entry restrictions or rules on a field and for pre-populating a field with a default value. However because of their triggering properties there can arise situations in which you wish to reference the fields on contents but not have the field re-trigger itself when modified. A self-join can be used to reference the field in its own calculation - or indeed any field on the table - without having those fields force the re-triggering of the auto-enter calculation.

Example File

Download Example File

As-You-Type Window Naming and Selection

Mon, 14 Mar 2011 17:08:00 +1300

In applications such as Mail, you may notice that window names can be dynamic, dependent upon the contents of a field. In the case of Mail, the subject dictates the window name. In this article I'll demonstrate a way this can be replicated for FileMaker, and more importantly, how these dynamic windows can easily be selected again once created.

Disclaimer: Things are just better on Mac

This technique works great on Mac platform, but on Windows it may give some undesired results especially later on in the article where window selection is addressed, you may see a square box in the window name among other things. To put it bluntly, it's a mac only technique being illustrated.

An Example of a Dynamic Window Name

By the phrase dynamic window name what I mean is a window whose name will be constantly changing, it's not set in stone. A classic example of this is the Mail application (and almost certainly other applications) when a new message is being composed:

As you can see the windows name is the same as the subject line. If I were to clear the subject line entirely, a default window name is used:

This would be a pretty cool thing to have in FileMaker - window names that change dynamically based on some value in a field. For example your window name could change to reflect the record you are viewing, whether you are in find mode or browse mode, or the subject of a note/task you are composing just to name a few.

The solution, and then the solution to the solutions problem:

This is a cool feature and would look very nice, but having this feature presents a new pitfall to think about. The next section will just demonstrate the method in which you can achieve live window naming, and it will then be followed by explaining what the situation is that arises and how you can go about resolving it.

Using Script Triggers to achieve the Window Name

You may have seen that one coming :) Script triggers are a great tool for introducing live and dynamic changes to a lot of different areas in FileMaker, and window names is just another of those.

As an example (please refer to the included example file) I have created a sample solution containing an E-Mail table. Each E-Mail is a draft that is pending to be sent in the database, and contains a recipient, subject, and message:

Here I have a list of the e-mails. Editing and sending of the e-mails is done in a special popup window. I wish to have just one of these popup windows open at any one time for editing emails.

In the image above you can see the windows name is exactly the same as the selected records subject. If I were to change the record, I would expect the window name to also change.

Here we see an e-mail with no subject. In this situation a default window name is assigned. So how is this done?

There are two triggers used here. The first is onRecordLoad, in which I am running a script whose purpose is to set the windows title. The onRecordLoad trigger is a useful one to use in this case because it handles various situations such as:

Changing Record
Performing a Find
Omitting, modifying found set etc
When the popup is first opened

All of these operations cause a new record to load, and so the trigger will execute.

The second trigger used is on the field that is responsible for the windows name. In this case it is the e-mail subject:

Here we are using an onObjectModify trigger so that the windows name will be updated after the users keystroke is entered.

The script responsible for setting the window name is a very simple 1 line script which uses the Set Window Title script step. If the subject field is not empty, then the window name is set to that, otherwise the window name is set to a default value of "(No Subject)".

Now the Issue: Selection of this Window once Open

As with most things in FileMaker there is always a catch, or something that will cause an issue that you need to workaround, and this technique is no different.

With regular windows whose names do not change, the window name itself becomes a sort of identifier of that window, kind of like what a primary key is to a record. If the window needs to be selected at a later point in time, it can easily be selected because the window name will not be changing. The window name could thus be stored in a custom function, global variable, or global field as a way to obtain its name for selection.

In this situation however, we don't know what the windows name is because it is dynamic. When the window first opens it may have the name of "(No Subject)". Once the user enters a subject the window name has now changed to something entirely different, and similarly any change to the users current record will affect the window name also.

So the problem now becomes how can we identify what the window name is even when the name itself is changing?

Window Names that are Lists

The solution to this issue devised makes use of a little quirk in FileMaker window naming. A window name can actually be a return-delimited list of values, however only the first value in that list is visible to the user as the windows title.

What does this mean for us? It means if we can assign the window a name that is two values - the first being the visible window name, and the second being a constant identifier for the window, then this might just let us figure out the full windows name somehow.

A closer look at the set window title script step

Here is the code used for the set window title script step used:

Let (
Subject = Emails::Subject ;
List ( If ( IsEmpty ( Subject ) ; "(No Subject)" ; Subject ) ; window_Email )
)

You can see the use of the List function here in generating the windows name. The first value in the list is the visible window name, either the subject, or a default "(No Subject)" title. The second value however is a special custom function called window_Email. In this custom function I have placed a text string which I am confident has not been used as a window name elsewhere in the solution.

So, if we look back to the earlier picture of my popup windows window name, you will notice that the second value "- Email Compose" is not visible anywhere in the window title, yet it is still part of the overall windows name).

So what does this look like

If we were to take a look at the WindowNames function what you end up seeing is something like:

LiveWindowNaming
Don't Forget Morning Tea
Email Compose

As you can see, the window name spans two lines in this function as you would expect because of the fact the window name itself spans two lines.

This is something you may need to pay attention to especially if you use the WindowNames function to determine the number of open windows in a file, because in this case there is 2, but windowNames would suggest there were 3.

Obtaining the original window name

The original window name can be obtained with the help of some magic custom functions. To obtain the window name, we start with the fact that we know what the identifier is, we could then:

Find the position in WindowNames of the identifier
Obtain the previous value in the list
Combine that with the identifier to get the actual window name

The example file has a custom function contained called window_OpenWindowName which accepts as a parameter the identifier, and will return the full window name if it is open, or blank if it is not.

Some other things to consider when using this technique

There are a couple of other things you may need to keep in mind when using this technique.

The first is the selection of field/value to use as your visible window title. If you choose a field that may contain return characters, then you should probably substitute those for another character upon setting the window title, this will prevent any issues later on when trying to back-engineer the windows name. Substitute with a space or comma and that should be fine.

Secondly is the choice of identifier to use. This should be something that you know will not appear as a window name on another window. It is ok if the identifier appears as part of a windows name, so long as it is not the actual window name, the reason being that the custom functions employed to determine the original window name are looking for the identifier as its own value in the WindowNames list, not as part of a value.

Lastly is another little quirk that occurs with this method and creation of windows. Generally if you have a window whose name is 1-value, and you create a new window via Windows -> New Window, the new window name is appended with a number so that the new window name is different to the original. This is FileMakers way of trying to ensure you don't end up with two window names the same.

However you are not restricted in FileMaker to having unique window names. When this 2-value window name technique is used, the "- 2" appendage is not appended to either value of the window name, so you essentially create a new window whose name is exactly the same as the first.

For this reason, the technique still works, but it will always be the first window created that is considered to the be found window. subsequent windows will not be identified as the main window because of the way the custom functions work to obtain the windows name - they seek out the first occurrence of the identifier in WindowNames....

Back to Creation/Selection of the Popup Window

With all that said, we can now employ this technique to handle both creation of this special popup if it is not already open, or selection of the window if is already open. Looking at the example file as a guide, the script to open/select the window does the following (condensed):

Set Variable [ $Window ; window_OpenWindowName ( window_Email ) ]
If [ not isEmpty ( $Window ) ]
  Select Window [ Name: $Window ; Current File ]
Else
  // Create the Window, onRecordLoad takes care of window title
End If
// Correct record navigation is done afterwards, again onRecordLoad takes care of window title

The first thing is the potentially open window name is determined using the custom function. If it is found, that window is selected, if not, the window is created. After that the record the user wishes to view is selected via a find, GTRR or whatever other means, because we have the onRecordLoad trigger assigned to set the window title, we need not worry about setting it ourselves.

Handling the Windows Menu

So far we have talked about the visible window title and the fact the first value is only shown there. However the other place window names are visible is in the Window menu itself. If you have this disabled via custom menu then this is not a problem, but if not read on:

In the Window menu, the name displayed is one of the following:

The full window name if short enough, otherwise
~ first 14 characters start of window name, and last 14 of window name, separated by three dots.

In our case, the end of the window name is the identifier, which actually works out quite well. We can choose an identifier that is about the required length, so that when the user views the Window names from the Window menu what they see is something like:

This is a great window name to see here because it lets you see the start of the visible window name for easy selection, but if the visible window title is not enough to tell what the actual window is, the identifier makes it very easy to see the purpose of the window. Imagine if you had 10 open windows, each with very arbitrary window names based on a field value, knowing which window is which in the Window menu would be a nightmare, but using the identifier you can very easily see what the windows are.

As a side note, the reason the identifier of " - Email Compose" was chosen as such, was for this purpose. In the case of a very short window name, this nicely formats the visible window name in the Window menu to:

"Short Name - Email Compose"

Which is much nicer to read.

Further to this, if the file is hosted on a server, then typically in the Window menu you will see the server name appear in brackets after the window name (if the window is hidden). In this situation the window name comprises of the last 25 some odd characters in the following:

(Server Name)

So if you have a short server name, you can expect to see your identifier suffixed by it, ie:

Email Compose (FM Server)

Which again is quite nice.

Taking it further, multiple popups

This article is only really concerned with explaining the dynamic window technique and a way in which you can then reference these windows for selection or creation. The example chosen assumes that one popup window is required at any one time, and the user should not be allowed multiple email popup windows. But what if this is not the case, and we want the user to have as many popups as they want?

While I have not explored this area fully, I thought I would put my thoughts in on how you could achieve this. Fairly straightforward, it would just mean an adjustment to the way the identifier part of the window name is generated. The identifier would instead contain the primary key value of the record being viewed, as well as an textual component for ease of reading in the window menu, i.e.:

"(No Subject) - 58282 - Email Compose"

In this situation, the identifier is now:

" - 58282 - Email Compose"

Rather than the identifier being stored in a custom function, it would now be dynamically generated itself in the script responsible for window creation/selection, and in the script responsible for setting the windows title.

Final Thoughts

This technique was originally conceived because of the need to replicate a Mail composition type dialog in FileMaker, but it can be applied to all kinds of window types. I have found the combination of onRecordLoad and onObjectModify triggers to be pretty robust, though more testing may need to be done in the areas of find/preview mode usage.

The technique whereby a window name consists of a multi-line value is a great way to have a visible window name, and an invisible window name component for the purpose of window identification.

Example File

Download Example File

Thinking Outside the Loop

Thu, 03 Mar 2011 13:58:00 +1300

If you have spent any time developing in FileMaker, or programming in almost any language, you will be familiar with the concept of a loop. When scripting your loops you probably have a favorite method that you use. This article presents and compares a number of looping techniques that can be used in FileMaker in an attempt to locate the fastest method.

Establishing our Test Scenario

Lets assume that our solution is a CRM which has a Contacts table. The CRM also has a letter writing screen where we can compose letters.

To make the best use of this facility, we should be able to compose a letter and print a personalized version for each contact.

In order to print these personalized letters we require three important things:

A Letters table to store the personalized letters.
Records for each individual letter
A Contact ID field to link to a Contact

The goal of our loop then is to generate Letter records, each personalized for a specific contact which is determined by the fact that each record will have a different Contact ID.

A Note:

This article makes heavy use of the example file that accompanies it. It might be a good idea to download the example and reference it while reading this article :-)

The code in this article is also a simplified version of what appears in the example file and is to illustrate the basic loop structure. If you want to see it in action then the example file is the best place to look.

Method #1: Layout Switching

Perhaps the simplest method and the one most beginners to FileMaker would use. The method involves looping through contact records, grabbing information from each in order to create letter records. The loop ends when all records have been traversed.

Set Variable [ $LetterContents ; Home::Letter Contents ]
Freeze Window
Go to Layout [ "Contacts" (Contacts) ]
Show All Records
Go to Record/Request/Page [ First ]
Loop
  Set Variable [ $ContactID ; Value: Contacts::Contact ID ]
  Go to Layout [ "Letters" (Letters) ]
  New Record/Request
  Set Field [ Letters::Letter Contents ; $LetterContents ]
  Set Field [ Letters::ContactID ; $ContactID ]
  Go to Layout [ "Contacts" (Contacts) ]
  Go to Record/Request/Page [ Next ; Exit After Last ]
End Loop

One of the biggest problems with the above method is the number of layout switches it involves. For each letter created, there are two layout switches - from contacts to letters & back. If you are generating 20,000 letters, that's 40,0000 layout switches which all adds up. This method might be fine for small numbers of letters only, but when the number of records generated gets large, an impact on performance can be seen.

Method #2: Chopping a List

This method differs from the first in that there is little or no layout switching involved, rather the looping is done by using a list of Contact IDs which is defined before the loop begins. This method is one that is quite common, but it too suffers from some inefficiencies.

Set Variable [ $LetterContents ; Home::Letter Contents ]
Set Variable [ $ContactIDs ; List ( Home to Contacts::Contact ID ) ]
Set Variable [ $Total ; ValueCount ( $ContactIDs ) ]
Go to Layout [ "Letters" (Letters) ]
Loop
  New Record/Request
  Set Field [ Letters::Letter Contents ; $LetterContents ]
  Set Field [ Letters::ContactID ; GetValue ( $ContactIDs ; 1 ) ]
  Set Variable [ $ContactIDs ; RightValues ( $ContactIDs ; ValueCount ( $ContactIDs ) - 1 ) ]
  Exit Loop If [ IsEmpty ( $ContactIDs ) ]
End Loop

During each iteration of the loop, the first contact ID in the list is set into the new record. The list is them trimmed of its first value, so that the second value now becomes the first. When the loop next iterates, the new first value is used, and so on until the list is empty.

The big issue with this method is the overhead in trimming the list during each loop. In particular the use of the RightValues function is a particularly costly function call. The more letters you create, the more calls to this function required. Also, consider generating a large set of letters such as 20,000. Your initial list is 20,000 values. After the first iteration the RightValues function is being told to grab the 19,999 right-most values from that list to make the new list - that can't be good!

So, is there any way we can still use a list of contact IDs, but perhaps avoid using these costly function calls during each iteration of the loop? Fortunately there is...

Method #3: The Counter Approach

You may have noticed in Method #2 that we used the GetValue function to obtain the first value in the list. GetValue takes two parameters, the second of which is the value # in the list to obtain. We were just using the first value, but there is no reason why we can't grab any value.

So, we are now going to maintain a running counter variable for each iteration of the loop. We will use this in conjunction with GetValue. This lets us obtain a contact ID during each iteration, without needing to modify the original list:

Set Variable [ $LetterContents ; Home::Letter Contents ]
Set Variable [ $ContactIDs ; List ( Home to Contacts::Contact ID ) ]
Set Variable [ $Total ; ValueCount ( $ContactIDs ) ]
Set Variable [ $Counter ; 1 ]
Go to Layout [ "Letters" (Letters) ]
Loop
  New Record/Request
  Set Field [ Letters::Letter Contents ; $LetterContents ]
  Set Field [ Letters::ContactID ; GetValue ( $ContactIDs ; $Counter ) ]
  Set Variable [ $Counter ; $Counter + 1 ]
  Exit Loop If [ $Counter > $Total ]
End Loop

This method has eliminated the need for the RightValues function call, and instead requires one GetValue function call per iteration of the loop.

One thing I noticed in building this particular loop was that during each iteration, I was carrying out two "Set Field" operations - one to set the Contact ID, and one the letter itself. This means that if we generate 20,000 records, then there are 40,000 set field operations. Is there another way to set field contents en-mass? Why yes there is...

Method #4: Replacing

The premise behind this method is as follows - we generate all the letter records using a standard loop as we have seen in the above methods, however we don't set any field values during this loop. Once all records are generated, we then run two "Replace Field Contents" steps across the found set, one to set contact IDs, and the other to set letter contents.

The question is - are two replace field content steps faster than X "set field" steps - where X is 2-times the # of records generated?

Set Variable [ $LetterContents ; Home::Letter Contents ]
Set Variable [ $ContactIDs ; List ( Home to Contacts::Contact ID ) ]
Set Variable [ $Total ; ValueCount ( $ContactIDs ) ]
Set Variable [ $Counter ; 1 ]
Go to Layout [ "Letters" (Letters) ]
Show All Records
Show Omitted Only
Loop
  New Record/Request
  Set Variable [ $Counter ; $Counter + 1 ]
  Exit Loop If [ $Counter > $Total ]
End Loop
Replace Field Contents [ No Dialog ; Letters::Contact ID ; GetValue ( $ContactIDs ; Get ( RecordNumber ) ]
Replace Field Contents [ No Dialog ; Letters::Letter Contents ; $LetterContents ]

Here you can see the loop creating essentially blank records. When done, the created records then have their fields populated. GetValue is used in conjunction with Get(RecordNumber) to populate Contact ID.

When the replace happens, Get(RecordNumber) is evaluated from the context of each record, so when the 50th record is being replaced, Get(RecordNumber) will be 50, and so on.

Note also that before looping we ensure the found set is empty so we don't interfere with other letter records when we do the replace.

Looping methods without actually looping at all...

Up until this point, all four looping methods have used Loop constructs - that being the Loop and End Loop script steps. We are traversing items, whether they be records, or values in a list.

There is however another way in which records can be generated in a table without explicitly looping or using the New Record/Request script step, and that method is using an Import.

The Import Records script step can be used to Import records from a file, such as a CSV, tab delimited etc. It can also be used to import from another FileMaker file. Even more specifically, it can be used to import from a different table within the same file, and it is this method we will be making use of.

So how do we create multiple records using Import?

The conventional idea behind an import is you start with X records in the source table, and after the import you now have X records in the destination table. In this situation however we don't have X records to begin with.

The way in which we will create the letter records is to make use of a particular setting of the Import Records script step:

When importing values in a repeating field, you have the option to either keep them in one record, or Split them into separate records.

So, if we have 20,000 contacts for example, if we can somehow get each contact ID into a repetition of a repeating field, and then import that repeating field choosing to split into separate records, we can effectively generate 20,000 letter records!

Method #5: Import Madness

And here it is:

Go to Layout [ "Home" (Home) ]
Show All Records
Omit Record
Show Omitted Only
Set Variable [ $$ContactIDs ; List ( Home to Contacts::Contact ID ) ]
Import Records [ No Dialog ; "ThinkingOutsideTheLoop.fp7" ; Add; Mac Roman ]

It's a little hard to deduce what is happening here so I'll explain. The first few steps are to ensure that we are in a found set of 1 records. This is to ensure that the import step generates the correct number of letter records. This is to do with how the import step works when dealing with repeating fields. If we have a repeating field of 20,000 repetitions, each with a contact ID in them, and we import from a found set of 1, we get 20,000 letter records. if however we had a found set of 2 records, we will get 20,000 letter records per record so in effect we end up with 40,000 letters! We always need to be on a found set of 1.

The setting of the global variable $$ContactIDs is the way in which I am setting the repeating field which is part of the import, lets have a look at that repeating field:

This is a live unstored calculation that is setting each repetition to a value in the list in $$ContactIDs. So if $$ContactIDs were to contain 20,000 values, then the first 20,000 repetitions in this calculation field will have values, any others will be blank.

It is important here to note also that only repetitions with a value in them will be imported, and thus have a record generated for them.

In the import record step itself, the repeating field is being mapped onto the Contact ID field in the Letters table, and the Letters contents is also mapped accordingly.

Some inefficiencies with this Import Method

The above method is great, it's simple, cuts down on the number of lines of code, and is quite reliable. However there is an inefficiency here. This is the fact that the repeating field we are using in the import is an unstored calculation. When the import is occurring, each repetition has to be evaluated, so in effect there are X calculations being evaluated, where X is the number of letters being created.

Some Testing and Results, What Do We Learn

Now would be a good time to look at the example file. In it, I have setup each of the 5 looping methods mentioned so far.

Here, I present the average time to create 20,000 letters for each of the 5 methods presented. This first test is done on a local copy of the database.

Layout Switching: 45 Seconds
Chopping a List: 72 Seconds
Counter Approach: 30 Seconds
Replacing: 31 Seconds
Import Madness: 32 Seconds

The following test was done over a slow internet connection to a copy of the database hosted on FileMaker Server 11 Advanced. Due to internet connection speeds, I have reduced the number of records created in this test to 500 letters. It's not ideal using a reduced record set because this affects the interpreting of results, but I'll do my best:

Layout Switching: 210 Seconds
Chopping a List: 209 Seconds
Counter Approach: 209 Seconds
Replacing: 313 Seconds
Import Madness: 110 Seconds

Interpreting the Results

First thing I notice is that times vary more significantly in the local test than the WAN test. My assumption here is that this is because of the different in letters generated, 20,000 compared to 500. In the local test, the main reason for the large differences comes down to the script steps themselves and the looping methods, not the actual process of creating the records. In the WAN test, fewer records means the overhead of the looping constructs becomes less, as indicated by the fairly consistent speeds for the first 3 methods. The overhead in this case is the method of record creation, and the number of calls between server and client required.

Looking at the WAN results, the layout switching, chopping a list, and counter methods are all very similar in times, in fact, only a second separates them. This would indicate the overhead in these 3 cases is in the New Record/Request action. The methods of looping have little overhead. In fact if you think about it, layout switching, and list manipulation are all happening on the client-side anyway and there is no server interaction in this process. The only interaction with server is first obtaining the list, and then the committing of the new records back to server.

The Replace method is an interesting one. Here in the WAN test, it is by far the slowest, and if you think about it this kind of makes sense. If we keep the assumption that the overhead here is in server/client calls, or more specifically the setting and getting of data between the two, then this method has 3 explicit send/get operations compared to 1 with the rest. The first is the loop to generate the records. The second and third are the two replace field contents script steps. There are three separate sends of data to the server as opposed to one for the rest.

Finally is the import method which has proven to be the fastest of all. The calculation that determines the repetition values is done on client once the contact IDs have been set into the global variable $$ContactIDs. So the overhead here is again the creation of records via the import.

I can only deduce that record creation via import is more efficient than a loop, perhaps it reduces on the number of packets sent back and forth between server and client, I'm not sure, but compared to looping methods, the import method proved significantly faster in WAN testing, and in local copy testing the difference in speed was negligible compared to that of looping methods.

And for the Local Copy Results...

As always with using more records, the results are going to be more distinctly different. If we tested a local copy with 500 records then the time difference between all methods is negligible to the point of under 1/100th of a second. It is only when using very large data sets do these differences present themselves, and the truly efficient methods present themselves.

So what does this all mean?

What this means for real world practices? Basically, if using a solution over WAN, you should probably look at using an import as a way to generate your records if you can as it is a more efficient method of record creation. If using a local copy, OR only generating a small set of records, then any looping method is probably OK, but if you want to use a truly efficient method, either the import, or a counter looping method would be advised.

Added Bonus: Looking for the Ultimate Speed

Looking at the results shown above, the import method is fastest over WAN, but the Counter approach is fastest over local copy (and with large record sets). Is there a way to combine these two approaches to produce an even faster method?

Lets compare a loop vs import for simple record creation

For this test, I am using a local copy of the database and 20,000 records to generate. The goal is to compare the speeds of a simple loop, with that of a simple import to generate records.

The first thing I did was to create a very simple loop to generate 20,000 blank records:

Set Variable [ $Counter ; 1 ]
Loop
  New Record/Request
  Set Variable [ $Counter ; $Counter + 1 ]
  Exit Loop If [ $Counter > 20000 ]
End Loop

The second method is a single import records script step. Note that to create the 20,000 records I am using a Stored repeating field with values 1 thru 20,000 in the repetitions.

Import Records [ No Dialog ; "ThinkingOutsideTheLoop.fp7" ; Add; Mac Roman]

Simple Loop: 12 Seconds
Simple Import: 3 Seconds

That's a whole 4x faster to create 20,000 records using an import as opposed to the simplest loop possible.

So, the import is clearly the best way to create the records that was already known, but why is this method so much faster than the loop? The key here is that our repeating field is Stored.

Recall the original Method #5 was using an unstored calculation as the repeating field, so there was overhead involved in calculating each repetition. What if we instead used a loop to set the Contact IDs into a stored repeating field, instead of having them unstored?

Method #6: The Need for Speed

This method uses a simple loop to set each repetition of a stored repeating field. The repeating field is then used in an import records script step to generate the records.

The hope is that this combines the best of both methods. We are hoping a loop to set 20,000 repetitions will have less overhead than the evaluation of 20,000 unstored calculations.

We also hope then that the import of a stored repeating field is faster than a loop of 20,000 record creations (we already know this to be true from the earlier test).

So, here we go!

Set Variable [ $LetterContents ; Home::Letter Contents ]
Set Variable [ $Counter ; 1 ]
Set Variable [ $ContactIDs ; List ( Home to Contacts::Contact ID ) ]
Set Variable [ $Total ; ValueCount ( $ContactIDs ) ]
Loop
  Set Field [ Home::ContactIDs_Stored[$Counter] ; GetValue ( $ContactIDs ; $Counter ) ]
  Set Variable [ $Counter ; $Counter + 1 ]
  Exit Loop If [ $Counter > $Total ]
End Loop
Commit Records/Requests [ Skip data entry validation; No Dialog ]
Import Records [ No Dialog; ThinkingOutsideTheLoop.fp7; Add; Mac Roman ]

The Need For Speed: 22 Seconds

That's a whole 10 seconds faster than the earlier Import method which used an unstored repeating field. Not too shabby!

Again, overhead comes with the loop when dealing with a local copy. So when dealing with small record counts over WAN you may notice no difference between the two import methods. The difference is achieved when working with large record counts.

Limitations using the Import Method

While the import methods may be more efficient for creating records, they do have some limitations from other aspects. For starters, you are using a repeating field, and repeating fields have a limit to the number of repetitions they can hold - 32,000. So you are limited to 32,000 records created at any one time. You can of course modify your import script to be contained within a loop which itself loops for each block of 32,000 records if you need to generate more.

The other limitation to this is that while the records are being generated you have no way of keeping track of what number of records have been created. All you will see is an import dialog which says it is importing 1 record (which technically it is, but it is splitting it into many records).

One good thing about using a scripted loop is that during each iteration of the loop you can know exactly what point you are up to, so you can do things such as progress dialogs or visual cues as to progress.

Final Thoughts...

Hopefully this article has presented some alternate styles of record creation and looping you may not have thought to use.

While some are more efficient than others, the performance gain depends on a number of factors such as your connection method to the database, internet speed, number of records being created and so on. So don't feel bad if you are using a looping method that may be slower than another, that difference in speed may be unnoticeable.

I am very keen to hear of other people's looping methods, or whether you can take the example file and expand on it, or come up with other faster ways. Some things to explore may be:

SQL Creation of records
Exporting to CSV/Tab and Importing back in
Alternate methods of setting the repeating field, faster calculations
Ways of optimizing scripted loops

If you have any feedback or suggestions please leave a comment, or get in touch directly via e-mail. I'll do my best to add them to the article.

=======================================

EXTRA! Reader feedback and New Looping Suggestions

Thank you to everyone for your feedback, with it has come a couple of new methods of record creation. I actually feel a little silly at this point because one of them now appears so glaringly obvious I wonder why I completely omitted it, so much for thinking outside the loop as it were :)

Method #7 - Contact Import

Instead of putting all of your contact IDs into a repeating field, why not just go direct to the contact records and import them into letters, why not indeed! In fact I even made mention to the fact that FileMaker can import from one table to another, yet seemed to glance over that aspect :)

So, to do this I have put a global field into the contacts table to store the letter contents for purpose of the import. Then, a Go to Related Record step is used to put the user on the contact records, the import is done, and that is that:

Set Field [ Contacts::zg Letter Contents ; Home::Letter Contents ]
Go to Related Records [ Show only related records; From table: "Home to Contacts" ; Using layout: "Contacts" (Contacts); New window]
Import records [ No Dialog; "ThinkingOutsideTheLoopExtra.fp7"; Add; Mac Roman ]
Close Window [ Current Window ]

Turns out, this method is by far the fastest method tested so far, there is no processing of repeating field required, and no looping, it is just a pure import. Testing with 20,000 records on a local copy took an average of 8 seconds, a full 14 seconds faster than my "need for speed" method :)

Method #8 - Auto Enter

This method makes use of field-level auto-enter calculations to populate the contact ID and letter contents of letter records. The key involves the fact that local variables exist for the duration of a script, and that applies to records created during the processing of the script, thus auto-enter calculations can reference those local variables.

The script itself appears as a basic loop:

Set Variable [ $LetterContents ; Home::Letter Contents ]
Set Variable [ $ContactIDs ; List ( Home to Contacts::Contact IDs ) ]
Set Variable [ $Counter ; 1 ]
Set Variable [ $Total ; ValueCount ( $ContactIDs ) ]
Go to Layout [ "Letters" (Letters) ]
Loop
  New Record/Request
  Exit Loop If [ Let ( $Counter = $Counter + 1 ; $Counter > $Total ]
End Loop

From the scripts perspective contact ID and Letter contents are not set, but they are in fact being set via the auto-enter calculations, each of which are set to $LetterContents and $ContactIDs respectively.

Testing of this method has shown that it takes around 22 seconds to generate the 20,000 records on a local copy, so comparable with need for speed method 6, but nowhere near as fast as method #7.

Revised Conclusion

If you are able to generate your records by importing direct form a found set of records in another table then you should definitely look at doing that as it is the fastest method. There is no overhead in looping, setting a repeating field and so on.

However that is not to discredit the repeating field import method which still has its place. This would be a good method to use if you had to set many fields on the new records from globals, or if you don't have the ability to go to a found set of records. Perhaps you are not specifying contacts, but instead you have an arbitrary list of items that need to be turned into records, in this case there is no found set available so your options are a loop or an import.

Thank you to those who contributed to this extra section!

Example Files

Download Example File

This next example file contains methods 7 and 8 that were added after the article was published, thank you to Mike and Stephen for contributing these two methods.

Download Extra Example File

A Lightweight Cross-Tabular Data Entry Method

Mon, 21 Feb 2011 21:20:00 +1300

One of the shortcomings of FileMaker is its inability achieve easy cross-tabular reports and data entry in a normalized structure. There are various techniques to replicate cross-tabular interfaces, but they often involve many relationships for either the columns/rows, or are for display only. The goal of this article is to present a lightweight method for cross-tabular data entry using as few relationships & fields as possible.

Disclaimer:

My apologies for the length of this article. To try and make this as easy to follow as possible I have tried to make it as clear as possible, and have tried to explain every step of the process with pictures. As a result, it turned into a bit of a monster :) Hopefully you don't switch off half way through - if you do, book mark it and come back later, or you can skip to the example file and just get stuck in :) - Daniel

What is Cross Tabulation?

Displaying data in a cross-tabular format basically means representing data in a grid 2-dimensional format. Think of a spreadsheet with rows and columns. Each cell is defined by a row number and a column number

In the image above, the rows are defined by the people, and columns are numbered 1 through 7. Each cell is a piece of information.

What is the Ideal Underlying FileMaker Structure?

The underlying format ideally should be a normalized structure of tables & records with 1 record per "cell". This is why cross-tab in FileMaker is so difficult - we can easily display the vertical component of a cross-tab with a portal, but the horizontal component is the hard part. FileMaker has no horizontal portals, and so to display the columns one must resort to other methods...

Other Structures That Should be Avoided

I have seen cross-tab been done in the past where the columns are done as repeating fields, or even individual fields. Consider a grid of 10x10. The 10 rows are done with 10 records in a list or portal which is fine. For the 10 columns, a repeating field may be built with 10 repetitions, or even 10 individual fields added to the table responsible for the rows.

This is a huge no no! Repeating fields should never be used for storing actual data in this manner, it will only lead to nightmares, cold sweats, and post repeating-field trauma in later life. Repeating fields are not good normalization structure for any database.

The Solution - use Repeating Fields

Okay, you may be scratching your head at this stage. "Didn't you just tell me NOT to use a repeating field? Won't I have nightmares if I do?" Well, yes you will, but only if you use them for Data Entry

Repeating fields are perfectly fine to use as an interface tool for displaying data, or as a means to manipulate data, just so long as they are not the source of that data! I love the repeating field so much in fact that I try to talk about them any chance I get, much to the chagrin of my colleagues :)

The rest of this article is going to show a method of using repeating fields to achieve a nice cross-tab data entry portal, in fact the same portal you saw at the beginning of this article.

Setting the Scene for What We Want to Achieve

Lets have a look at what the end result should be:

Each cell here is to be a record containing its piece of information. In this example we have 2 tables:

Parent - This is what constitutes each row, 1 parent record per row
Child - Each child record is a cell in a column.

One parent record has 7 children records, and we can assume this is established at the point the parent record is created. Children are categorized as 1 thru 7, so for any given parent we know it will have 7 children numbered 1 thru 7.

To begin, we can build a portal whose context is based on a parent table occurrence, this gives the following:

We know that each row has 7 associated children record that will need to have their value shown as columns. How can this be done?

A Common Method of Relationships & Fields

As mentioned in the abstract, one method of cross-tab production is to construct a series of relationships to each specific record for the purpose of showing it in the portal. This method is works fine when the number of child records is known, but one of its downfalls is the large number of relationships required, and the fields required to build those relationships.

Have a look at how this might look if we were to pursue this method:

In this graph you can see our home context, and the table occurrence for the parent that is showing Parent records. Related to the portal table occurrence is 7 individual child relationships, each one to a different one of the 7 children.

In order to establish a relationship to each specific and unique child record, 7 fields are required, each containing a unique identifier which lets the parent record relate to each child individually:

This is an awful lot of management required to build your cross-tab. Think of a cross-tab with 50 or 60 columns, can you imagine what the graph is going to look like, let alone the parent table with all of these interface fields!

Back to Repeating Fields as the Solution

If only we could just stick a repeating field in the portal and be done with it. This would give us a nice cross-tab appearance, as repeating fields can easily be shown horizontally. If the number of columns ever changed, then it would simply be a case of extending the # of repetitions and widening the portal, simple stuff.

Here's how we will do it....

Get ( ActiveRepetitionNumber ) & GetNthRecord

Two of FileMakers most awesomest functions. The GetNthRecord function allows us to obtain field contents from any field of any specific record through a relationship. The Get ( ActiveRepetitionNumber ) Allows us to know at any point in time what repetition number of a repeating field the user is in. More on these two functions later.

Step One: Get the children record data displaying in the portal

The first step to this method involves being able to display values from the 7 children records in the portal using a repeating field. If we can at least display the data, then this will give us a good platform for modifying that data.

We have added the repeating field to the Parent table as shown above, and given it 7 repetitions, 1 per child record. This is a calculation field so live child record information can be displayed. The calculation is:

Here you can see both the GetNthRecord and Get(CalculationRepetitionNumber) functions being used. GetNthRecord allows us to obtain a specific records value, and the record for which it is obtained is dependent upon the repetition in which each calculation is evaluated. As an example, for the 5th repetition of the field, Get(CalculationRepetitionNumber) will return 5. When this is used in conjunction with GetNthRecord, the value in record # 5 is returned.

Note that the extend function is required when referencing non-repeating fields in a repeating field calculation.

What we end up with:

The image below shows what we end up with when we put this display repeating field in the portal:

Look familiar? (It should, I've shown it 3 times now!) What we end up with is a pretty looking cross-tabular display of our data. Great. If we merely want to show this children information then we might as well stop here because we are done. But this is only half the story. We now need to be able to allow editing of these values within the cross-tab structure, and have the underlying children records be updated, and this is where things get interesting:

Step Two: Building a Repeating Field we can Modify

The problem with the current repeating field is that it is a calculation for display only, and we cannot modify the contents of a calculation. Instead, we require another repeating field that is not a calculation, so that we can enter values into it.

The first image shows the new repeating field for data entry in the Parent table. The second image shows how both repeating fields are positioned within the portal. Note that the display field is placed on top of the entry field and has a fill color so that the entry field is completely hidden from the users view. I have highlighted the entry field in green purely so you can see it.

Note also that entry into the display repeating field is disabled. This has the effect as such that when the user clicks onto it, they are in fact entering the data entry field underneath.

Step Three: Display value when clicking into entry field

Currently, if the user were to click into a data entry repetition, they would get a blank box, and it would appear that the value has disappeared. Instead, we wish for the value they see prior to entering a cell (the display value) remains upon clicking into the data entry repetition.

We will achieve this with the use of an onObjectEnter script trigger attached to the data entry repeating field:

When the user clicks into any given repeating field, we want the associated display value to show in the entry field. The first line of the script achieves this:

Here you can see the field and repetition to be set. We are setting our data entry field, and the repetition being set is the one we have just clicked our mouse into - which can be obtained using the Get ( ActiveRepetitionNumber ) function.

The value that we will set into this repetition, is the value in the corresponding repetition of the display calculation.

Still awake over there? Yes? Good! The end result of the above is that when the user clicks into a repetition, they see exactly what they saw prior to clicking. In fact, the data entry field now contains the value that is in the corresponding child record. The user is now able to type freely and modify this value to whatever they want.

Step Four: Exiting the Field & Updating the Child Record

The user has now entered the cell, modified the value in it, and is ready to exit out of the field. When they do this, we are going to need to update the associated child record with the new value. Remember that each repeating field corresponds to a specific child record.

While obtaining a specific records value using GetNthRecord was easy, going back the other way is not quite as easy. There is no SetNthRecord function, nor is there a script step to set a specific record in a relationship. So in order to achieve this we employ some other smarts.

GetNthRecord is able to obtain the value of any field from any related record. Well, we know what record we are dealing with when the user is in the data entry field, because we obtained the value put into that field in the first place, right? So why don't we grab that child records primary key value while we're at it. That way, we can establish a relationship "on the fly" to that specific record as a means to update it? Make sense? No? Keep reading...

Two new fields have been added to the Parent table. The first of these is "Active Child ID". This is a live unstored calculation that at any point in time contains the child ID (primary key) of the child record that the user currently thinks they are modifying in the cross-tab interface. It's calculation is very similar to that of the Display repeating field calcualtion, but instead of returning the child records value, it returns its primary key instead:

The purpose of zRelationship Refresh Field

You may have seen this field lurking in some of the earlier screenshots. The main purpose behind this field is to force a refresh of the relationship between the Active Child ID field, and its associated child record. The Associated Child ID field is an unstored calculation, which doesn't reference any field on the Parent table. Because of this, when it is used in a relationship, the relationship is unaware of any change to the calculations contents, and thus the relationship does not re-evaluate.

You may have read an earlier article describing this exact issue, and the proposed solution was to use a Cartesian-Join in the relationship as a means to force the refresh. This is exactly what is being used here, and is the purpose of this refresh field. You can read that article here.

When the user clicks into the data entry repetition, the last step of the script is to set our refresh field to 1, this forces a refresh of the relationship to that specific child record. Now it is correctly established, when the user leaves the entry field, we can very quickly and painlessly set the new value into that child record.

Here is script that is run upon onObjectExit of the repeating field via script trigger:

We have a direct relationship to the child record to update:

And we set it to current field contents:

Below you can see the relationship from the portal context to the child record that is being updated.

(Image)

And these are the two predicates in that relationship - the first is the direct relationship to the child being updated. The second is to force the refresh of this relationship

(Image)

Finally, you will note that the last script step is to clear the data entry field. This is because once the user leaves the data entry field, there is no need for it to contain a value, in fact if we kept the values in there, then the size of the database would get large over time. To avoid this, we clear the data entry field contents. If the user ever does click back into that field, it gets set again anyway so no harm done.

To put it all in Summary

Step One: Display the live data in display repeating field
Step Two: Build the data entry repeating field
Step Three: Script triggers to set data entry field contents
Step Four: Update record upon exiting field & tidy up after yourself.

The overall expense in terms of relationships & fields required is:

1x Portal
1x Relationship to single child record being updated
2x Repeating fields, 1 display, 1 data entry
1x refresh field (this could be worked around using scripting if you wish)
1x current Child ID field for updating child record via relationship
2x scripts onObjectEnter and onObjectExit

Overall I think the expense is pretty small for a 7 column cross-tab. using the other method would have required 7x relationships and 7x fields so this method already has that method beat in terms of cost.

But the best feature of this method is the ease at which it can be scaled. Once all of the basic components are in place, adding extra columns is a case of adding repeating fields to your data entry & display fields.

If the child records don't exist initially, then you can modify your onObjectEnter script to test for this via the relationship, and if no child record exists you can create it - it's all good!

Final Thoughts:

If you are still here reading this then well done! Give yourself a pat on the back! This was tough one to write and while I'm sure if I spent a bit more time on it I could have cut down the size of the article, hopefully it wasn't too much of a mission to get through it :) Thanks!

Example File

Download Example File

Hide Custom Menu Elements Dynamically

Sat, 19 Feb 2011 12:07:00 +1300

When FileMaker 11 was released, one of the lesser documented changes in behavior concerned the defining of menu names when dealing with Custom Menus. When any menu element has an empty name, an interesting thing happens:

So, tell me what happens already!

Well, when an item has no name, the item disappears entirely from the custom menu, and from any custom menu it may appear in. Why is this so significant you ask?

Well for starters, this was not the behavior in FileMaker 10. In 10, any menu item with no name would still appear in the list as an item with no name (funny that).

Have a look at the custom menu set above. There is a menu in this which has no name, can you see it?

Here it is, did you find it? Well done! Ahem, so anyway, as you can see the menu is still there and still selectable.

Now lets see what happens when the same custom menu is viewed in FileMaker 11:

As you can now see, the menu is entirely gone in 11, it cannot be selected at all.

What does FileMaker say about it?

After having a rummage through the FileMaker 11 documentation of new features, I could only find the following mention here:

Users can no longer remove the item title and action checkboxes dynamically when the menu item is not based on a command. This means that it is possible to have a menu item have no item name or action.

I don't really understand the first part, but the last sentence would indicate that they acknowledge the lack of menu item name as a change.

Oh, the possibilities!

The potential to make use of this feature is limited only by your imagination. This is because menus and commands that are used in custom menus can have their name defined via calculation.

Have a look at the custom menu above. The Giraffe menu actually has its name defined in a global field in the solution, and the menu name is derived from that global:

So, whatever I enter into the global field is what the menu name is. If I remove the contents of the global entirely, the menu will disappear as it will no longer have a name.

Hiding Parts of Menus

Basically any component of a custom menu can have its name defined via calculation. Consider the following example:

The Giraffe menu contains both a command, and a sub-menu with further commands in it.

Here, I have removed the Lion commands name using the same global method. The Lion command no longer exists within the Giraffe menu.

Note:The Lion command has actually been removed from the Giraffe menu, and every other location it is used in the custom menu set, or any other custom menu set it is used in. The item either has a name or doesn't, and if it doesn't, it's gone everywhere.

Now having said that, given you are able to define an item name via calculation, you can build a calculation that will give the menu item a name under certain circumstances for example: based on your privilege set, layout you are on, flags defined in fields, global variable contents, etc. It may not disappear everywhere depending on how you build your calculation.

Hiding Sub-Menus

A sub-menu is simply a menu that is used within another menu. When this is done, the sub-menu expands to reveal its menu items contained within it.

Again, sub-menus when defined can have their name set via calculation, after all, sub-menus are simply menus.

Here I have the menu name in a global.

A cautionary table about sub-menus

One thing to be aware of if trying to show or hide a sub-menu is the following option you are given when using a sub-menu:

Here, I have defined a sub-menu Zebra. The Zebra menu has its name defined via calculation and the name of which is contained within a global field. Also, for this particular sub-menu definition, I have chosen to place it in the parent menu Elephant.

Pay attention to the Override Default Behaviors option. Here I have specified an overriding title for the sub-menu. You may expect in this situation that the sub-menu should appear as "MAXIMUM ZEBRA OVERDRIVE" under all circumstances, for an override should replace any default name for the Zebra menu.

This is not the case when the menus actual name is empty. In the case where the Zebra menu has no default name, the override is NOT applied, and the menu will still disappear.

This is unfortunate because the override item name would have been the perfect convenient way to keep a sub-menu in one menu, and have it hide in others.

When the Zebra menu does have a default name, the override will be applied.

Potential uses of this Feature

As mentioned earlier, the possibilities are endless. Here at Digital Fusion, we have used this feature in some of our custom solutions as a way to introduce a Developer menu into the solutions custom menus.

Rather than create separate menu sets for developers and users, we just have a user series of menu sets. Within each menu set is a Developer menu, whose name is only defined if the logged in user is deemed to be a developer (we check the privilege set name, and the user record for verification).

The end result is the developer menu appears for us, but not for regular users.

This has saved a great amount of time because we didn't need to replicate all of the custom menus for us. It also means we can get the best of both worlds, when testing and debugging a solution, we can use the custom menus the user sees, and we can also have access to our own developer menu which contains useful debugging tools.

I would love to hear of anyone else's ideas for using this feature.

Final Thoughts:

While this is a lesser documented feature of FileMaker 11 - to the point of barely being documented at all - I think it is one of the coolest features and one that has limitless applications.

... Just be sure that you are building it for solutions that use FileMaker 11, otherwise you may not get the desired effect!

Example File

Download Example File

Quick Tips: Commenting Your Value Lists

Fri, 18 Feb 2011 21:38:00 +1300

Pretty much everything in FileMaker comes with some form of comment box to let you add more information - such as fields, menus, custom functions, calculations, scripts, and the graph. However the one area lacking in a comment box is value lists, unless that is, you think a little outside of the box:

Where is the comment box?

If you are anything like me, then you are an obsessive commenter of anything and everything in FileMaker. So when it comes to value lists, the lack of a dedicated comment box is somewhat annoying. Fear not, FileMaker graciously gave us a large comment box, they just got the name wrong.

"Custom Values"

If you use "custom values" value lists often, then it's pretty obvious what they are for given you can see the values right in front of you.

However sometimes a "custom values" list is simply not going to cut the mustard, especially when dealing with values from records, related data, conditional value lists and so on. So why not just use the custom values box as a comment box in this situation? Well fortunately you can.

It's Easy

Just choose the "Custom Values" option, type in your comment, and set your value list option back to its original type. Your comment be left greyed out, but still clearly visible

Final Thoughts;

Ditch those Flushes, Use Cartesian Join Instead!

Mon, 31 Jan 2011 11:58:00 +1300

All too often, the Refresh Window script step is used with the 'Flush Cached Join Results' option checked. Sometimes this is through lack of understanding, but other times it is required to refresh those pesky relationships which have trouble re-evaluating. This article explains why Flush Cache can be detrimental on performance, and offers an alternative and more efficient method for refreshing relationships...

Check out the full article here.

Ditch Those Flush Cashes, Use Cartesian Join Instead!

Sat, 29 Jan 2011 11:51:00 +1300

What is Flushing Cached Join Results?

The FileMaker documentation describes this as the following:

Select Flush cached join results to delete the results of queries for related records and cause related records to be refreshed. Do not select this option if you know your script does not affect related data, and if you want to minimize the performance impact of re-accessing related data (particularly when sharing a database over a network).

Whenever a relationship is evaluated (the query) the related records found are cached (downloaded) to your computer. If you are accessing the database over LAN or WAN, then the speed at which this happens depends upon your connection speed. Once cached, the relationship should perform much faster because the records now reside on your machine.

However, by flushing the cached join results, all results of relationships that have been done (i.e. all the records downloaded through relationships) are cleared from your cache, and you basically have to start all over again re-downloading related records when viewing them.

The reason why FileMaker states this should be avoided over network, is because of this re-download factor.

When is a Flush Cached Join Results needed?

Most of the time, a flush of the cached join results is not necessary at all, and typically it is used in error. People may think that because a calculation is not refreshing on their layout, it will require a refresh of the window to display correctly. While this may be true, all too often I have seen the "Flush Cached Join Results" option checked at the same time, merely for added insurance that the desired result will be achieved. Sometimes the performance hit is negligible so it goes unnoticed, but once the solution goes up on the network, that is when the real fun begins!

Flushing of the Cached Join Results should really only be used when dealing with a particularly complex relationship whose results are not re-evaluating as desired.

What causes problematic relationships to not refresh?

I have found over the years that the most problematic relationships are those which make use of globals, and unstored calculations whose calculations reference related records. Sometimes it may be necessary to build these types of relationships to achieve a desired result (notably when using an interface/data model).

The particular situations in which relationships have refresh issues always tends to elude me, but when it happens, the reasons are usually clear, and include one or more of the reasons above.

So, why not just flush the cached join results when it happens?

Well for starters, as mentioned earlier, every single downloaded record that you have downloaded and cached since you first open a file, will be cleared. This basically means that you are starting from scratch since the file was opened, and any record you viewed will be re-downloaded.

Over WAN this is where it is most noticed. When using a WAN hosted database, you may notice upon first use that portals and relationships may load slowly as the record is downloaded - scrolling portals may be slow, that sort of thing. But after more use, things speed up because the records are now being accessed from your cache. Flushing the cache puts you back to square 1.

In 99% of the cases your intention for wanting to flush the cached join results is merely to refresh one particular relationship, not the entire database. If only there was a way to do this...... well there is !

The solution: Using a Cartesian Join in your Relationship

The refresh problem arises because the relationship is unaware of its own need to refresh the results. The trick here is to tell the relationship that it should refresh itself.

Relationships will re-evaluate themselves if one or more fields on the source side of the relationship change explicitly. However, we know that any field put on the source side of a relationship will actually affect the results of that relationship.

The exception here is a cartesian join.

Cartesian join predicates, by definition, find ALL records through a relationship:

The above relationship uses a cartesian join, so will find all contact records through this relationship.

In this relationship, a standard "=" predicate is used. The result of this relationship will be all contacts whose status is "Active".

Here lies the key in this technique. The above relationship uses a standard "=" predicate, AND a cartesian join predicate. The result of this relationship? All active contacts. The cartesian has no effect on the relationship, EXCEPT as a means to refresh it.

We have managed to add a field into the relationship, which has no detrimental effect on the relationship, does not affect the relationships intended results, but is a field nonetheless which we can use to refresh the relationship.

So, how does it work?

Simple, just set the field you have used in your cartesian join predicate to any arbitrary value (non-empty). Ideally, you should create a field whose sole purpose is for the refresh of relationships. You could create one field per relationship if you wish to control specific relationships, otherwise you can use one field for all relationships that require refreshing. I have created one in this example called "PortalRefresh".

The field can be set either via a script, or more ideally using a script trigger. The script trigger would be perfect if you wish the relationship to re-evaluate upon changing the contents of another field (which itself indirectly affects the result of the relationship).

The refresh field you choose can be global or non-global depending upon your needs.

An Example for you to play with

I have included at the bottom of this article an example file which you can use to see the method in action.

Because these refresh issues are sometimes contrived, I have come up with a similarly contrived relationship to illustrate the purpose.

The example file comprises 2 tables - Home, and Contacts. There are 3 relationships on the graph as shown in the above image:

The first is a standard cartesian join to find all contacts through a relationship
he second makes use of the cartesian join technique for refresh
The third leaves off the cartesian technique and just finds a particular record.

On the Home table there is a calculation which obtains the Contact ID of the Nth record through the first relationship. The user enters a number into a global field which corresponds to the contact record they wish to view.

To cause the refresh issue, the global field the user enters the record # into resides on the Contacts table, and is pulled through to the Home table for use in the unstored calculation.

What it all boils down to is a relationship to a particular contact, which will not refresh without a little nudge :)

Using the Example File, a Demonstration

In the example file you will see a portal of all contacts, and their record number displayed beside them:

You will also see the following entry fields:

Enter a number into the Record # to show box. If you click out of this box, you will notice that the Found Record value does not change to the record you entered. This is the refresh issue. Due to the nature of the relationship & the fact it is based on an unstored calc that references globals in the contacts table, the relationship is not refreshing.

The button beside the field will run a script that either uses the flush cache method, or the cartesian refresh method, depending upon which tab you are using.

Beneath each record entry field is a script-trigger version of the field, which runs the associated script using an OnObjectModify trigger.

Both versions in the example file (flush cache & cartesian) exhibit the same issues, but each uses a different method of solution.

Final Thoughts
You should always use the flush cached join results option on the Refresh Window script step with caution. Don't just check it willy nilly to guarantee your refresh issue will be solved. Understand what it really means and what impact it has on your solution, especially when deployed over LAN or WAN.

Finally, consider the alternative method of refreshing a relationships results by using a cartesian join - you will retain your cached results, and only "flush" the specific relationship you need flushed, improving WAN performance in the long run.

Example File:

Download Example File

Quick Checkbox Selection of Portal Records for Users

Wed, 19 Jan 2011 07:51:00 +1300

There are many ways in which users can select records, so that each user can keep their own unique selection. This particular method uses a portal showing related records as a selection tool. The main technique involves using a value list & checkbox to easily achieve selection with no scripting required.

Setting the scenario:

Quite often it is necessary in a solution to let users select one or more records for a certain purpose. Because this is a user-level process, each user should be allowed to have their own lists of records without interfering with other users selections - this is a perfect use of a global field! Global fields are user-specific, so one users global field contents will differ from that of another user.

So, how can we make use of a global field to select records? One of the most common techniques simply involves maintaining a list of selected record IDs in the global field, and this is the technique that we will be using in this article.

A little bit about checkboxes:

The easiest way to construct a checkbox in FileMaker is to simply make use of FileMakers existing features. Value lists have a visual display option to show as checkboxes. Typically when you see a checkbox value list it looks something like the following:

The first box shows a standard checkbox value list containing 3 values. The second box shows what is actually stored in the field when options are checked. When a value is checked, it is either added or removed from the field. The field itself is just a return-delimited list of checked values.

So, with that said, is there any way to maintain our return-delimited list of selected records using a checkbox?

"Single-Value" Value Lists

To further help understand the technique (which I will eventually explain!) it pays to demonstrate the following technique that you can use with value-lists that only contain a single value:

In the picture above, the value list now contains just the single value "Apple". You can see that everything still works as expected - unchecking the apple box will remove apple from the field just as it did previously.

So, if a value list contains only one value, is it really necessary to show the label "Apple" beside it? If it is only one value, then surely the user knows what the checkbox pertains to depending on where the checkbox is located on the layout?

With a little jiggery-pokery, the checkbox field can be reformatted to give the appearance of a lone checkbox with no label:

This is achieved by doing a few things:

Reduce the width of the checkbox field so the label is hidden
Increase the font size of the field to make the checkbox larger
Remove field borders to remove the "double box" effect.

We now have a checkbox which when toggled, will select/deselect the word "Apple".

Applying this now to the portal:

So, we have shown how to build a single checkbox to toggle a value in a field. Applying this to our problem, it stands that to solve our issue we simply need to place this checkbox in our portal so it appears on every row. Toggling the checkbox in each portal row will need to toggle the selected portal rows record ID in our global field.

In order to do this, the value list is going to need to contain a single value - the portal rows record ID. Each portal row is going to require a different value attached to its checkbox - that being its record ID.

So, how do we produce different value lists for each portal row? You may think the answer would be to create many value lists - fortunately there is a MUCH easier and MUCH less time consuming way (note - creating many value lists will

Value lists have a context

This is key. The contents of a value list will change depending upon the context in which they are evaluated. Most value lists you see have a layout-level record context. This means that the values contained within the value list will change from record to record, depending on what record you are on. Other value lists may be contextless, such as ones that use custom values. For these, they will show the same values regardless of the record they are on.

A portal is a context, and as such you can have a value list evaluate within a portal on a row-by-row basis. This means in just the same way a value list can change its values on found-set records, they can also change on portal rows.

This property of defining a value lists context is achieved using the value list option Use Values from Field combined with the option to Include only related values starting from: - the latter of which provides the context for the value lists evaluation.

Because a related value is needed for this feature, we are going to require a new relationship to obtain the value lists values from. We only wish our value list to have 1 value which will be the records primary key value, so we need to create a self join relationship:

In the picture above you can see the layouts context Home, related to the portal of contacts we will be using. From the portal table occurrence, we have created a self-join relationship to a new Contacts table occurrence in blue. The relationship here is simply from primary key to primary key (Contact ID = Contact ID).

The image above shows how the value list that we will be using for the checkbox is setup. Note that the value list is set to show each portal rows Primary key Contact ID through the self-join relationship. The Starting context of the value list is the portals table occurrence. This means the value list contents will be evaluated at the portal level, giving unique value list contents on each row.

The picture above shows the result of putting our global field in the portal, and attaching our value list to it. I have expanded the width of the field so you can see the actual value of each value list. You can see that on each portal row, the contents of the value list changes to reflect that rows Contact ID.

The end result:

Putting it all together we end up with a nice checkbox on each portal row, which when checked will toggle that contacts record ID in our global field.

Final Thoughts:

The thing I like about this method is that it is quick, requires no scripting, and makes use of FileMakers existing checkbox as a selection tool.

While there are many other great methods out there for record selection in portals, hopefully this has given you yet another tool for this process. It really is a case of using the right technique for the right situation. This checkbox technique works best when the number of records in your portal is relatively small, otherwise visualising the selected records becomes more difficult. You could combine this technique with some conditional formatting in each portal row to achieve a better indication of the selected records, but generally if you were to go that far then other techniques that involve scripted maintenance of your list of IDs is probably more suitable :-)

Example File:

Download Example File

The Case of the Disappearing Sub-Summary

Sat, 15 Jan 2011 09:34:00 +1300

Recently I was working on building a large layout which is used for both printing and data-entry. One of the requirements was I needed to show a lot of "private" information that the data-entry person needed to see, but was not to be printed. The issue was solved using a very cool property of sub-summary parts.

First, the alternative possibilities:

Before I show the actual solution used, it pays to mention a couple of other possible solutions to the problem just to outline why they were not suitable.

Putting the information off to the side:

The first one would have been to just put all the private information off the right-hand side of the layout, beyond the edge of the page break.

This method would work, and would be fine depending on the situation. However it was not ideal for this example:

Small monitors would need to resize window and/or scroll to see it
Breaks the flow of the layout, vision is not drawn to a section off to the side

The main issue was that I wanted to keep the dimension of the layout the same as the printable space, to prevent the layout having to be widened during data entry.

The "Sliding and Hiding" method:

Another option would have been to put the information on the layout in a particular section, and then mark everything in it as "Hide When Printing" this would solve the issue of not printing the information. However, now I end up with a gap in the layout when printing.

So, can everything be made to slide up and fill the gap left by the now hidden information? The answer is yes, kind of...

Here is an example of some private contents in-line with the layout contents. Everything has been set to slide up & reduce size of enclosing part. The private contents have been set to do not print.

You can see green boxes in between the contents of the private section to indicate the white-space. The key point here is that this white space does not slide or disappear, it remains, leaving a gap.

The solution to this particular problem is to group the entire contents of the private section into a single object, and set that object to do not print, and slide:

The result is that the entire grouped object is treated as one object, so when it disappears, the only white space remaining will be the gap between the sections above and below the private section:

The problem I have with this however:

The sliding & hiding method would actually work quite well, and in some situations it would be perfect, such as if the private data section is located at the bottom of the layout.

However, my biggest problem with this was the affect it has on page-breaks, or more specifically, trying to construct the layout to fit properly on the pages.

As you can see in the picture above, because I have now added this section in-line, everything has been moved down, and the layout I worked so hard to build to fit on my pages, is now all out of alignment. Now it's all a case of trial & error when building the layout to ensure that the page breaks in the correct locations, I have to constantly accommodate the sliding and hiding of the private information section!

What I really want is a combination of the following:

The off-to-the-side method which does not affect page boundaries, AND
The in-line method which lets me see it, and let the layout flow.

Using a Sub-Summary part to show & hide the information

Finally, the solution was to use a sub-summary part!

I created a sub-summary part, and chose my tables primary key field as the break field. In fact, it doesn't matter what break-field you choose, so primary key is as good as any.

The key to this technique is as follows:

While in browse mode and form view, sub-summary part(s) will remain visible even if the records are not sorted

In order for a sub-summary part to actually print, the records have to be sorted, so lets just not sort the records! Amazingly, the sub-summary remains visible in browse mode, which is perfect as a means to let use it for data entry, putting in links, showing important information etc.

You can see in the image above, the sub-summary is placed at the top of the layout.

Best of all, the sub-summary part has no adverse effect on existing page-break boundaries, so I can still construct the layout using the page boundaries, making building the layout so much easier for printing purposes.

A note for FileMaker 9 users

Please note that because this technique makes use of sub-summaries in browse mode, this technique will not work for users of FileMaker 9 or sooner. Browse-mode sub-summary viewing was introduced in FileMaker 10. In this situation, the sliding & hiding method would be more appropriate.

Final thoughts:

To be honest I was completely surprised when I jumped into browse mode and saw the sub-summary part staring me in the face with the records unsorted. My original intention was to ensure the records were sorted by the break-field so that the sub-summary would appear in browse mode, and then use script triggers and custom-menu overrides for printing to ensure the records were then unsorted prior to printing.

However as things happened I was spared all of that work by an unusual quirk of FileMaker, I love it when that happens!

Example File:

Download Example File

Creating Tidy Popup Windows

Sun, 09 Jan 2011 07:38:00 +1300

Using Popup windows is common FileMaker technique for showing more information, managing dialogs, and running wizards to name a few. However, all to often little care is given to the aesthetics of creating and positioning a popup, leading to an unpolished and half-finished feel. This article gives some pointers on how you can create popups that are clean, efficient, and correctly positioned.

Why would you want tidy popups?

Consider any standard application on your computer, such as iTunes, Mail, Safari etc. When you open new windows in these applications, such as entering the preferences, what do you see? Typically, you will see the popup windows appear centered in front of your current window. They appear right away, and they appear all setup and ready to go.

Now, if an application can do it, then why shouldn't your database? Databases are just as critical as applications, if not more, so why skimp on the detail?

Having tidy popups makes your entire database feel tidy and polished, and can be achieved very easily.

All too often I see popup windows created in FileMaker with no care. How many popups have you seen in databases that appear in seemingly random positions, with the incorrect size, showing scrollbars or status area. Then, how many do their setup on-screen, so you see the hiding of the status area, the resizing of the popup, layout changes and so on? I don't know about you, but I see it all the time and it is one of my biggest bug-bears about database design - the lack of care taken on the user interface and design side of a system.

If you are building any kind of commercial database, then how it looks and behaves should be one of your top priorities, no one wants to buy a database that looks half-finished !

Setting up a popup without the user seeing

The creation of new popup windows that are not visible to the user has already been covered in one of my previous articles - "Using an Offscreen Window to do a Scripts Work".

The idea is that new windows are created with a large negative left coordinate value, this ensures the new window appears at a coordinate not visible by monitors, and so is not on-screen.

The article above concerns using these windows as temporary workspaces which can be closed when done, but the same idea can apply to creation of popups the user will eventually see. The popups can be created with it's width, height, and top coordinate set correct for the popup, but with the large negative left coordinate. When the popup is ready to be displayed, it can be shifted back on-screen in a single step using the "Move/Resize Window script step.

In the images above, you can see how the new popup window can be created. Local variables have been used to store the default top/left coordinates, and the popups default width and height.

Positioning the popup where you want

Depending on the purpose of the popup window you are creating, there may be many different initial locations on screen where you want the popup to appear. If you know the actual coordinates, such as wanting the popup to always appear in the top left corner of screen, you can obviously enter 0/0 as your coordinates.

However, more often than not the position of a new popup will be dependent upon the location of your current window. For example, if you wish to have the popup appear directly centered in front of your current window, then the initial coordinates of the popup are dependent upon the current coordinates of your main window.

Similarly, you may wish to position the popup in a location relative to an object on your layout. Small popup windows may be used to carry out an action specific to a location such as a particular button, or field. In this case, your popups initial coordinates are dependent upon the coordinates of the layout object.

Center-Aligning a popup window

To create a center-aligned popup window, I have created a couple of helpful custom functions that perform the necessary calculations to derive a top and left coordinate for your new window:

The popup_CenterLeft function takes your popups initial width as its parameter. This is required to position the popup correctly horizontally. Similarly, popup_CenterTop requires the popup height to center vertically.

I won't go into great detail as far as dissecting the functions, suffice to say they produce the coordinates using the popups dimensions, compared to the current windows dimensions and location on screen.

The image above shows how you can establish your popups coordinates in variables. Here, $Width and $Height have been previously set to the popups initial dimensions.

Establishing the popups initial dimensions

This is the most crucial part of the process in my opinion. In order to prevent visible scrollbars when you popup is displayed, you should set your width and height exactly correct for the popup. This is going to involve determining the exact dimensions. Some may think that this "hard-coding" of dimensions into your script is a bad thing, but I say that if you are creating a popup window, it is highly unlikely its dimensions will change unless you manually make changes to the layout, in which case your script should change accordingly. It is also important to get correct dimensions so you see no window resizing toward the end of the process.

In the image above I have set my width and height into variables. You'll notice the use of two more custom functions popup_GetWidth and popup_GetHeight. These functions help correctly determine your windows dimensions.

The reason for using these functions is because there is a difference in window dimensions depending on whether you are on a PC or a mac. On a PC, scrollbars are thicker and so the window will be larger. These functions take as their parameter the raw layout-mode width/height of your layout, and produce the resulting windows dimensions based upon what platform is being used.

To determine your layout height, you will need to obtain the pixel heights of your layout parts. If your layout has a header of height 50 pixels, and body part of 100 pixels, then your parameter to popup_GetHeight is going to be 150. Of course, if your popup is using list/table view, this becomes less important, and your popup dimensions should just be determined by what you wish the size of the popup to be initially.

To determine your layout width, select every object on the layout using cmd+A (ctrl+A) and in the inspector/object info panel, look for the right coordinate.

If you only ever use one platform, you can skip using the custom function and directly set your window width & height. To do this, open the popup window in browse mode & resize to fit, using your data viewer, obtain the values of Get(WindowLeft) and Get(WindowTop) functions respectively.

Putting it all together

All the required components are now known, and we can create the window, set it up, and move it back on-screen when ready.

The script above sets the required coordinates and dimensions of the new window. The window is created off-screen. Then follows the setup of the window, in this case switching to the desired layout. Finally, the window is moved back into its exact correct location using Move/Resize window.

Aligning popups relative to a layout object

The last type of popup I will be dealing with is those that are to be initially positioned relative to a layout object. Whereas the center-aligned method uses the dimensions of the current window, this will use the dimensions and coordinates of a layout object.

Again, two custom functions have been produced to assist in the correct positioning of the window, popup_ObjectLeft and popup_ObjectTop.

These functions take 3 parameters respectively:

-ObjectName - The object name of layout object to position relative to.
-Orientation - a keyword "top", "left", "bottom", or "right" to position popup.
-PopupWidth/Height - dimensions of popup depending on function used.

Again, not going into much detail about the functions, but just to say the functions make use of the GetLayoutObjectAttribute function to obtain coordinates & dimensions of the layout object, all information required to correctly determine the popups initial coordinates.

From here, once the coordinates are known, it's just a case of creating the window, setting it up, and then moving it back on screen as shown earlier.

A note about dock positioning on OS X

While writing this article I noticed a peculiar bug in FileMaker concerning obtaining a windows coordinates versus a layout objects coordinates. This is most apparent when your os x dock is positioned on the left edge of your screen.

In the picture above, my dock is on the left edge of my screen. You can see the left coordinate of the window when positioned right beside the dock is 0 pixels. This would suggest that when the dock is on the left of screen, window coordinates begin from the edge of the dock, rather than the screen itself.

However this is not the case for left coordinates of layout objects. As you can see, the gap between the edge of the window and the object is 126 px. You would think that this would mean the left edge of the button would be 126 px, you would be wrong! The left edge is in fact 176 px, a full 50 pixels more. So it turns out that when obtaining object coordinates, they do in fact begin from the left edge of your screen, and not from the edge of the dock as a window coordinate will.

This causes some problems in determining a correct popup window position because you cannot determine in FileMaker whether your dock is on the bottom of screen, or on left of screen. The functions mentioned in this article are assuming that the dock is at the bottom of screen, and thus the window coordinates and the object coordinates use the same 0 pixel coordinate location.

If your dock is on left of screen, you will find that the left coordinate of the popup window is slightly offset to the right of the object when using the object-aligning technique. This can be modified in the functions themselves, but is not a good solution, as users can always change their dock location whenever they want.

Note that the coordinate bug is not a factor when center-aligning a popup in front of the parent window.

Final Thoughts:

If any database is to be taken seriously as a professional looking, polished solution, then care needs to be taken in how you create your popup windows. Unnecessary window flashing, resizing, or visual setup of a popup should be avoided, as it makes a database feel unpolished and even unfinished. Correct positioning of popups is not a difficult thing to do given the proper tools, and can go a long way to improving the usability of your solution.

Example File

Download Example File

Complex Filtering Using Related Record Information

Sat, 08 Jan 2011 10:10:00 +1300

This article demonstrates how you can filter a relationship to one table, by using information located in a related table. The example we will be using is filtering a relationship to a Customer table, but by searching on a customers related Contacts, which are in an entirely different table.

What are you Talking About?

We are talking about the filtering of a relationship. There are a few various methods as to how this can be done, but we will be using a search field, that will match the contents of a key field generated on the related table.

This article is going to assume you have knowledge about basic concepts behind filtering. If you are unfamiliar with the concepts, there are a number of sites offering techniques on how to achieve this. A quick google search for "FileMaker Relationship Filter" will yield some results, or you can check out this great article on relationship filtering by Danny Kohn of FileMaker Inspirations. This particular article does not use the exact technique mentioned in order to keep the complexity level to a minimum, but the technique mentioned in the article is a great one nonetheless.

Setting up the Example Case

The example we will be using to demonstrate this technique is a simple one using two tables - Customers and Contacts. The relationship is that a Customer can have many Contacts, and so the foreign key field "Customer ID" is placed on the Contacts table.

Both tables contain basic fields you would expect to find in these types of tables. Primary keys are Customer ID and Contact ID respectively.

The zLocatorKey fields found in both tables, are special key fields used to accomplish the filtering of the relationship. While this type of key is not exactly the most efficient in terms of size, it is relatively easy to grasp how it works to achieve the filtering. In order to build this key, we have used a couple of custom functions, which we will not be going into detail about given the scope of this article, suffice to say you can check them out in the example file.

The Goal We are Trying to Achieve:

So, with all of this said, what is it we are actually trying to achieve here? The goal is to produce a portal based on the Customers table, which can be filtered by typing into a search field.

We wish to allow the user to search by customer name, which should be a fairly straightforward task given that it is the customers table being filtered, and so the customers name resides on the table we are filtering.

HOWEVER, we also wish for the user to type in a contacts name, and have matching customers also appear. How would we do this? Contact information is not kept on the Customer table at all. The only association between the two is via the primary/foreign key relationship.

You might think the answer would be to place the related contact information on the Customers table, but stop! Any calculation placed on the Customer table to pull through related contact information is going to be unstored, and thus any relationship based on this calculation would break. The destination side of any relationship must have all predicates stored.

Perhaps the answer then is to store contact information on the Customer table, thus allowing us to filter customers directly. Well, in order to do this, a great deal of extra work and scripting will be required:

Any change to a contact name would have to be updated on the Customer record
Any adding/deleting of contacts would have to be updated also
This would have to be done via script triggers, scripts, server-side scripting etc.
In addition, you are essentially storing the same data twice.

The Proposed Solution:

To best illustrate the solution to this problem, have a look at the following diagram:

Step one is to carry out the filtering on a Contacts table occurrence. The filtering is setup just as if we were filtering contacts. The users enter a value into the search field, and matching contacts are found. If the relationship yields matching contacts, then we know which customer they belong to by way of their Customer ID foreign key.

Step two involves obtaining the contact results. The important piece of information concerns the customer the results belong to - Customer ID. This information is pulled back to the base context which in this case is "Home". The results are pulled back by using the List function to produce a return-delimited list of Customer IDs.

The final step now uses these resulting customer IDs in the relationship to the customers table. Any customers found through this relationship, we know have contacts that match the entered search term, because the customer IDs were obtained originally from a search for contacts.

That is the basic process in a nutshell. Depending on how you tweak these relationships further, you can achieve your desired behavior.

Example File Explained:

In the example file provided, the context for these relationships is "Home". The Home table contains the following fields:

Filter Search: Global text field the user enters search term into
Filter Key:Match field used in relationship to Customers to drive the portal
Filter Customer IDs: Return delimited list of Customer IDs obtained from the match through the Contacts relationship.

The relationship graph is setup as follows:

The first relationship is between Home & Contacts, and is used to obtain matching contacts based on the search value the user enters:

The relationship is to the Contacts zLocatorKey field. This field has been setup as a basic return delimited list of possible search terms for a contact, mainly just their given, family, and full names.

The second relationship is between Home & Customers, and is used to display the desired results in the portal.

This relationship is from a special key field called Filter Key.

If ( IsEmpty ( Filter Search ) ; "*All*" ; List ( Filter Search ; Filter Customer IDs ) )

If the user enters nothing into the search field, a special keyword "*All*" is used. The purpose of this is purely to determine how the portal will look when the user has not searched for anything. There are two possibilities here, either the portal shows nothing, or the portal shows all records. In this case, we have decided to show all records.

In order for the portal to show all records, we need to ensure the relationship is setup to find all records. In the zLocatorKey field in the Customers table, we have ensured every customer record contains the "*All*" identifier in its key, thus every record will be found through the relationship in this case.

Back to the calculation, if the user HAS in fact entered a search term, the following is used:

 List ( Filter Search ; Filter Customer IDs )

This is a return delimited list of both the users search value, and a return-delimited list of customer IDs obtained via the search on contacts earlier.

The end result is a key which should find all matching customers by both the customer names, AND by contacts that were matched by their names.

The contents of the Filter Customer IDs calculation field is simply a list of customer IDs through the Contacts relationship.

NOTE: About use of List function:

While this is a useful technique, it needs to be used with caution in some situations. This is because of the use of the list function to pull back customer IDs from matching contact records.

Whenever the list function is used, FileMaker downloads the entire record from records being listed, not just the field being listed. Because of this, if you search for "David" for example, and there are hundreds of David contacts in the system, then FileMaker will download all of those records in order to achieve the list of their Customer IDs. Over a local file, or LAN, this might be acceptable. Over WAN however, this may exhibit itself as slow filtering, given all records need to be downloaded.

For this reason, the example file has not been implemented with a live filtering functionality.

Final Thoughts:

This is a useful concept for carrying out complex filtering of relationships. The core idea is that you can filter relationships using other related tables, by pulling the results back to your main context, and then using them in your primary relationship.

As with most techniques, there are always drawbacks, the primary one in this case being the use of the List function to pull back results. This can have implications in solutions distributed over WAN or even LAN depending on the size of the tables concerned.

Example File

Download Example File

FileMaker Weetbicks Arrives

Mon, 03 Jan 2011 14:53:00 +1300

Digital Fusion is proud to announce the arrival of FileMaker Weetbicks. This is our gift back to the FileMaker community, and is where we will be publishing FileMaker related tips, techniques and example files, for users and developers alike.

Created originally by our developer Daniel Wood, the articles have been published before on a few other websites, but are now all in one place on our website for everyone to enjoy.

If you are a FileMaker developer, user, or just have a keen interest in FileMaker, be sure to check back regularly for new articles. We will also be using both Facebook and Twitter as ways to keep people up to date when new articles are released.

Cheers!

Build a Navigation System Part One - Starting Out Simple

Mon, 03 Jan 2011 00:00:00 +1300

Introduction

The first in a series on the subject. This article presents a very simple and easy to setup method of navigation for a database, making use of repeating fields.

Why do I need to create a navigation system, why not just use the layout menus?

Good question. Of course there is nothing stopping you from just giving users access to the layout menu via the status area, or Layouts menu, but there are a number of reasons why this is not always an ideal method of navigation:

Large number of layouts may confuse the user
User may not be required to see all layouts
Layouts may be placed in groups, increasing time required to navigate
Developer may use their own layout naming scheme for manageability, but will only confuse the user
Makes a solution feel less polished

It is my opinion that while the layout menus could be useful in a very simple solution, if you are designing a solution where you want it to look good, and have it feel more like an actual solution, then the layout menus should be avoided, keep them for the developers!

Method of Navigation: The Navigation Bar

The navigation system that will be built in this article is a very simple navigation bar, build using global repeating fields.

So, How Is It Built?

The navigation bar pictured above contains 10 different screens. Each screen in the navigation bar comprises of both an icon, and a text label that appears underneath.

This is achieved using 2 global repeating fields, each containing 10 repetitions, and positioned horizontally across the top of the layout. The first repetition is for the icons, and the second is for the labels:

These repeating fields have been placed in a table called "Navigation". This table only contains one record (though in actuality it need not contain any given all fields in it are global).

When setting up the navigation bar, remember that corresponding repetitions in both fields make up a single screen on the navigation bar. For example the fourth repetition of both fields will be the icon & label for the fourth screen on the navigation bar.

The Importance of Being Global

By having the navigation system based upon global fields, it means we can easily copy/paste our navigation bar onto any layout and it should just work. We will not need to re-point any of the component fields to any other table occurrence. The relationship graph simply requires one table occurrence for Navigation, and this is what is used at all times.

So How Does It Actually Navigate?

Another good question. What we currently have is the appearance of a navigation bar, but no functionality. We need to attach a script or script step to each screen in the navigation bar so we can actually go to that screen.

This is done by placing a button over top of each screen (corresponding repetitions) in the navigation bar. Unfortunately, you cannot simply turn a repeating field into a button and have each repetition act a its own button, which is what we want (though that would be a great feature, c'mon FileMaker!)

In the picture above, the black outlines are the buttons that have been placed on top of each "screen" in the navigation bar. By having individual buttons, we can tailor each one to go to its correct screen.

In order to navigate to a layout, we need to know what that layout is. We cannot hard-code navigation to a layout, because the very nature of this navigation bar means it is built in a "soft" manner - we can completely customize it based on what is put into the repeating fields. For this reason we also need to soft-code the layouts.

This is done by the introduction of a new repeating field into the Navigation table, for the purpose of storing the layout names corresponding to each screen:

With the navigation table now complete, I can setup the buttons for each screen in the navigation bar. Here is an example of how the fourth screen is setup:

As you can see, Go to layout by Name is the method of navigation. We obtain the correct layout name by referencing the repetition of the Layout field, that corresponds to the screen clicked. Each button is placed over a specific set of repetitions, so we can use that number on each button. Indeed each button is setup to go to a different layout repetition.

Is a Layout Field Required?

The answer is yes and no. This depends on how you name your layouts.

If you have a very simple layout naming scheme, and your label names are exactly the same as your layout names, you can just use the label repeating field in your Go to layout by name step.

However, even if this is the case, I would recommend always using the layout repeating field. More often than not, the layout names will differ from the label you wish to present. Label length is constrained by how wide your navigation bar is, and so you must choose your labels carefully. For example consider a screen for Purchase Ordering. That is a pretty long label, so you may wish to shorten it to "Purchases". However, you would really want to keep the layout name as "Purchase Orders" so you know exactly what it is when developing.

What if I Want to Use a Script For Navigation?

Sometimes you may need to do something upon navigating to a layout, such as showing all records, establishing a found set, etc.

If you wish to use a script for your navigation purposes, then you can easily do so. You can pass the selected screens repetition number as a script parameter to the script, and then that script can carry out the navigation to that screen using the repeating field when it is ready to do so.

Taking Things Further

The navigation bar built in this article is a pretty basic, straightforward, bare bones type of navigation bar. There are a wide number of things that can be done with it to extend its usability, design, and flexibility.

In the next article in this series, I will demonstrate some of these extensions, such as:

Colouring/Bolding the selected screens label
Background fill under selected screen in navigation bar
Increasing flexibility of colours/formatting using additional fields
A script to quickly and painlessly reorder screens in the navigation bar

And future articles will cover areas such as:

Customised Navigation for each user
Integrating as a Custom Menu
Alternative Navigation Styles, ie Portals

Final Thoughts

While using layout menus is a quick solution for navigation of a database, there are a number of drawbacks.

The main benefit of the navigation bar demonstrated, is that it is global, and fully customizable. It is setup once, and in one place, which is reflected across all layouts containing the navigation bar.

Example File

Download Example File

Sorting Records Using Your Own Custom Ordering

Tue, 21 Dec 2010 07:41:00 +1300

You may be familiar with the Sort Records dialog in FileMaker which allows you to display records sorted by one or more fields. What you may be less familiar with is the ability to more explicitly define a sort order with the assistance of a value list. This article gives an introduction to this often overlooked feature, and provides a few examples along the way.

Sorting Records

Sorting of records in FileMaker is achieved using the Sort Records dialog.

The dialog is available via Sort->Records in the file menu, and as a script step. You can also sort records by right-clicking while in browse mode somewhere on the layout, and choosing "Sort Records". The shortcut key ctrl+S (command+S on mac) will also bring up the sort dialog.

Move fields from the left side to the right side in order to sort by those fields. You can choose to sort by one or more fields, in either ascending or descending order. For most cases this is enough, and these sort options give you what you want.

There are however some situations where you wish to sort by a field, but the resulting sort is not what you want. This occurs when the sort order is to be custom, and not alphabetical.

As an Example:

An example of this situation may be sorting records by month name. If you were to simply sort your records by the month name, the resulting order would be:

April
August
December
February
January

.....

Months are being sorted alphabetically, which is meaningless as a sort order. Ideally your sort order should be in correct chronological order, so how is this achieved?

The answer is to use the Custom Order Based on Value List option that is available when sorting:

Here, I have specified to reorder based on a new value list called "Month List", lets take a look at that value list:

The value list is setup as a custom value list, and in the correct chronological order. It is this order that the record sort will use. Any matching value found in our sort field will be placed in the order as specified by the value list.

An Important Thing to Note Here:

One of the downsides of value lists I find is that when constructing a value list using values in a field, or from a related field or table, any sort order is lost and the values will display in the value list in alphabetical order. If you were to use this method in constructing your value list, and then apply it to a sort as your order, you may find that you lose the sort order you want given the fact the value list is alphabetical.

This method of reordering sorted records based on a value list is most suited when using a custom values value list. When using this option, you can specify the exact order you want, and the value list will retain your order.

As always there is a downside - you must explicitly define these values within the value list itself, meaning the value list contents cannot be stored in a field. However, in most situations this is acceptable. For example, the months case is fine because there are only ever 12 months, and their order never changes.

Back to the Example - Sorting Job Statuses

For this example I have constructed a simple database containing 10 jobs. Each job has some basic details such as customer, date raised, month raised, job status and priority.

In this solution, I wish for the user to be able to sort jobs by their status. Job statuses however have a very specific order to them - not alphabetical. The status order of jobs has been defined earlier by the owner of this database to be:

Pending
In Progress
In Invoicing
Completed

No problem! All that is required is to construct a value list of job statuses in that order. In fact, it is very likely that the value list would already exist as a method for selecting a jobs status.

You will note that a sort field has a little icon that appears beside it. The icon is either the standard for ascending or descending order. However if you choose a custom order, the icon appears different:

This icon indicates that a custom sort order has been used that is neither ascending nor descending.

As you can see in the above picture, the records have been sorted by job status, and are now displayed not in alphabetical order, but a custom defined order as specified by the value list.

A Final Example, Sorting by Job Priority

Up until this point, when we have reordered our sort by value list, the exact order of the value list itself has been used.

Jobs also have a job priority. A jobs priority from lowest to highest is:

Low
Medium
High
Urgent
Critical

A value list has been set up of job priorities in this order, and has been used elsewhere in the solution as the value list used when selecting a jobs status. It is in this order because from a data-entry perspective, the user of this database has requested it from lowest to highest.

However, when jobs are displayed sorted by their priority, it would make sense to show the highest priority jobs at the top of the list. This will ensure that high priority jobs are not missed at the bottom of the list. Having them at the top makes them clearly visible to users. Lower priority jobs can appear further down the list given that they are not as important.

Here is the sort order defined for this example. Records are sorted by job priority, and the custom order based on value list has been used.

The jobs are sorted however from lowest priority to highest, which is not what we want, but is what we would expect given the order of the value list.

So, is there any way to reverse the order? The answer is yes, but unfortunately there is no nice option to reverse the order.

The only way to achieve the opposite order is to create a new value list of job priorities in reverse order, and reorder using that list instead. The Sort dialog does not allow you to order by value list in that value lists reversed order.

Here I have specified the order based on a new value list called Job Priorities Reversed

End result is jobs sorted by priority in order from highest priority to lowest priority.

Multiple Sort Order Fields using Custom Orders

You can extend this further to have a sort which uses more than one sort order, and have each use a custom order.

Consider the following example:

Here I have chosen to sort my jobs by month name, using the custom month order defined in the value list. The second order is job priorities, where I have chosen to sort using the custom value list of job priorities from highest to lowest, the end result is:

Looking at the months first, you can see they are sorted in chronological order from July thru December. Within each month, the jobs are then sorted by priority from highest to lowest. Looking at December as an example jobs are shown from Critical thru Urgent thru to Low.

Not Just for Sorting Records on a Layout:

The option to reorder based on a value list is available wherever records can be sorted, this extends to:

Records on a Layout (as shown in this article)
Sorting a Relationship
Sorting a Portal

In these three situations, the reorder option behaves just like as described in the article.

Final Thoughts:

The option to reorder by value list is an often overlooked sort feature, but a very powerful one. It excels when the field(s) being sorted contain relatively few possible values, such as month names, statuses or priorities. The reason being that a custom value list must be used, where explicitly entered values are put directly into the value list. This method would not work quite as well if the field contained many hundred possible values - unless you decided to create a value list containing every possible value in its correct order!

Example File

Please find attached an example file. This file was used for all the screenshots in this article, and is provided to help you fully understand what is going on in this article.

Download Example File

A Very Nice Way to Format a Sorted Portal Using Conditional Formatting

Wed, 15 Dec 2010 10:37:00 +1300

In this article I will demonstrate a very nice way to format a portal using conditional formatting. This method is suitable for portals whose underlying relationship is sorted by a grouping/category field - similar to if it were like a sub-summary report. The easiest way to explain it is to just get stuck in with an example, so here we go....

In this example I will be using a very simple Customers table. In this table, there are 3 main fields:

Customer ID - the primary key
Customer Name
Region

Each customer has a specific region, so it stands that a region may contain multiple customers. On our layout, we have a portal showing all customers. The relationship this portal is based upon, is sorted by Region, so that in our portal, all customers who belong to the same region, will appear together as shown:

Now, this could be the end of the story - the records are sorted as you wish, and you can clearly see the region for each customer, but is it really that nice visually? The region name is appearing multiple times in each row, which is quite distracting, and also makes the portal feel cluttered. Also, is there any reason for the region to appear in each row? What if we could have the region appear in the first row for those customers only? Indeed, this is possible with a little conditional formatting.

The Conditional Formatting

The conditional formatting calculation I am going to attach to the Region field in the portal is as follows:

Let ([
This = Customers Filter::Region ;
Record = Customers Filter::zRecordNumber ;
Previous = GetNthRecord ( Customers Filter::Region ; Record - 1 )
];
This = Previous
)

So, what is going on here? The calculation is broken down into simpler chunks using a Let statement to make it easier to follow:

This = Customers Filter::Region

The variable "this" is simply set to the region of the portal row this conditional formatting is evaluating in. Note that each portal row calculates it's conditional formatting independently of the others, so when I reference the Region, it is evaluating the region for its own portal row only.

Record = Customers Filter::zRecordNumber

Perhaps the most complex step in the calculation. zRecordNumber is a special unstored calculation field that is required on the Customers table to achieve this desired effect. The calculation is set to Get ( RecordNumber ). Why? The reason will hopefully become clear soon.

Previous = GetNthRecord ( Customers Filter::Region ; Record - 1 )

So, this is the step that ties everything together. This variable will be set to the Region of the previous portal row to the one currently being evaluated, or in other words, the portal row directly above the one evaluating. The GetNthRecord function is able to return the value from a record through a relationship, where you define the exact record number to obtain.

Going back to the second step now - zRecordNumber is the way in which our conditional formatting calculation is able to obtain it's own record number in the relationship. So, the 10th record in the relationship (ie the 10th portal row) is able to know that it is #10 by referencing this calculation, the second row knows it is #2, and so on. This is the only way I could find to obtain this information for each portal row. Sadly, there is no Get ( PortalRowNumber ) function, and the closest one - Get ( ActivePortalRowNumber ) - only works if a portal row is active (funny that!).

When Get ( RecordNumber ) is evaluated through a relationship, the result is the record number of the portal row being evaluated. The function has to be in an unstored calculation on the table - simply referencing "Get ( RecordNumber )" in the conditional formatting calculation will always return 1 for each row - because in this situation it is obtaining the record number of the parent record, which is the same for all portal rows.

Back to Step:

So, with that known, the conditional formatting calculation now knows it's own record number. This is then used in conjunction with GetNthRecord to obtain the previous records Region.

The Final Step

The final step in the calculation is the actual conditional test to determine whether the formatting is applied or not. Now, remember that our aim here is to show the region on the first portal row for that regional group. Taking the opposite of this - we wish to HIDE the region on all rows which are not the first row for that region.

We know the region of the current row, and we know the region of the previous row. Thus, if the current rows region is the same as the previous, then the current row cannot possibly be the first row for that region, and as a result we wish to hide it. Hiding it is done by setting the text colour of the conditional formatting to white.

If in fact it was the first portal row for a given region, then the previous portal row will be different, thus the conditional formatting test returns false, and no formatting is applied, leaving the region visible.

What About the First Portal Row

The first portal row is handled gracefully, as there is no previous portal row, so the region in the first portal row will always be different from the previous. GetNthRecord of the 0 record will return blank.

Some Limitations:

It should be noted that there are some limitations to this method. First, it is the relationship that must be sorted here, not the portal itself. The reason is that both the zRecordNumber calculation, and GetNthRecord function, all work at the relationship level, not the portal level.

Second, this method will not work with portal filtering in FileMaker 11. The reason again is that filtering occurs at the portal level, while the conditional formatting is working at the relationship level. If you wished to use filtering, you would have to filter the relationship instead.

The End Result

Putting it all together you end up with something like this:

Some Further Formatting to Make it Even Nicer

The above is nice, but it is still lacking something. What it is lacking is some kind of separation between the regions. One region just follows on to the next without any kind of dividing line. Fortunately, we can make a slight adaptation of the conditional formatting we already have used, to produce a separating line.

First things first - you cannot conditionally format a line object. For this reason, we need to somehow hide the line under some circumstances. This is exactly the same as what we did for the region field.

In this case, we hide the line by overlaying a conditionally formatted object (a button/text label) , which fills itself the portal background colour:

The picture has been zoomed & exaggerated to illustrate the effect. The green box is a button with no action attached. It sits in front of a grey line. Both objects will be in the portal. The best place to put them is at the top of the first row as close to the top as you can get. Make sure the button has 0 line width (it has one here just so you can see it). The minimum height of the button you can achieve is 4 pixels so make it this.

The conditional formatting calculation on this is very similar to that of the region field, with one slight modification:

Let ([
This = Customers Filter::Region ;
Record = Customers Filter::zRecordNumber ;
Last = GetNthRecord ( Customers Filter::Region ; Record - 1 )
];
This = Last or Customers Filter::zRecordNumber = 1
)

The difference here is the last line. We wish to hide the line on the first portal row as it is not required there, so we test if the record number is 1, and if so, we hide the line.

Putting it all Together

Here is what you end up with when all the pieces are put together:

Looks very tidy and nice if I do say so myself! Each regional grouping is separated by a line. No need for region to appear on every line here, and it is clearly obvious what customers belong to what region.

Taking it Even Further, More Possibilities

This concludes the article, but if you were wanting to take it further, there are more possibilities to explore:

Modifying the conditional formatting, so that the regional name is shown every Xth row for that region. This would be useful for example if a region had a large number of customers. If this was the case, then as the user scrolled the portal, they may no longer be able to see the region name, and thus not know what region the customer belongs to. If this were the case, then putting the region name on every 10th row of that region would solve this problem.

Adapting for use in List-view on a layout. This could be achieved fairly easily given the fact both GetNthRecord, and Get ( RecordNumber ) will operate quite nicely on a found set of records as well as through relationships.

Example File

Please find attached an example file. This file was used for all the screenshots in this article, and is fully commented to help you fully understand what is going on in the file.

Download Example File

How Many FM Dialogs Can I Open in 60 seconds... and other Musings

Wed, 15 Dec 2010 10:36:00 +1300

I've always wondered how many FileMaker dialogs you can have open at once, or more specifically, how many can you "string" together before hitting the limit, if there is one. So, though a little trial and error, I set out about trying to find the path to the most dialogs, and here is what I came up with:

What follows is my string of dialogs, and how to get to each:

File -> Manage -> Custom Menus Manage Custom Menus
New Menu Set Edit Custom Menu Set
Click add to select menu Select Menu
You are now in the Edit Custom Menu
add a menu item, check "Action" Specify Script Step
Select "perform script", hit specify Specify Script
Hit + to create new script Edit Script "New Script
8. Add Set Field Script step and go to Specify Field Specify Field
Click "Specify" next to repetition number Specify Calculation
Click the TO list & go to "Manage Database" Manage Database
Select/Add a Text field & go to options Options for Field
Go to Validation, Member of Value List, manage value lists
Create a New Value List Edit Value List
Click "Use values from field" Specify Fields for Value List
Click use values from first field, manage relationships
Create a relationship & click on relationship Edit Relationship
Click sort records Sort Records
Select field, "reorder based on summary field specify" Specify Field

... That's about as far as I got, before I hit an interesting point, because once you get here, you can then...

19. Manage Relationships
20. Repeat from Step 16-20 ad infinite

Indeed, you can keep repeating this step and opening more and more and more manage relationships dialogs - of course they're all modal so you can only work in one at a time.

Then I got to thinking - well, what happens if I make a change in one of my manage relationships dialogs, and then "wind back" the dialogs to the previous manage relationships dialog, what would I find?

Here are two manage relationship dialogs I have open. The one on the left is the front-most and the only one I can edit at this time. I have added the Yellow TO. From here, I wound back the dialogs by clicking "OK" on them all, effectively saving my changes rather than discarding.

Now I have wound back to my first manage relationships dialog. Interesting to note, the yellow TO is nowhere to be found - does this mean it has not yet been created? Is the TO just failed to show up because of a FileMaker bug? In any event, I leave my mark in this dialog by adding another green TO. Finally I wind my way allllllll the way back to the start, OK'ing every dialog I come across.

When I finish, I go back into the relationship graph to see what I have:

Interesting - both TO's are there ! by committing every dialog all the way back to the start, basically everything I did was saved, including both changes to the relationship graph from different dialogs.

Hmmm, I think to myself:

This leads me to try a few more tests, what happens if:

I delete a table occurrence in the front-most dialog, but then try to use it in a previous dialog
I add a Table occurrence in the front-most dialog, then try to add one with the exact same name in the previous one

Here's What Happened:

In the first case, interestingly, when I deleted a few table occurrences in my front-most relationship dialog, and then rolled back to the previous one, they did disappear from the dialog when I returned to it. Granted, I did have one of the relationships selected of the deleted Table occurrence which may have had a factor, but in any event they disappeared.

This time, I cancelled my changes as I rolled back in an attempt to get them back, were they really gone? the answer was no. Once I returned to the original main "Manage Database" dialog I had open, and tried to cancel this, I was asked to revert my changes, and upon doing so, the table occurrences came back.

FileMaker does a great job at keeping it's transactions nicely separated, even though it appears I have many many dialogs going, They always all relate back to a single dialog, and anything done in subsequent dialogs can always be reverted.

And in the Second Scenario?

This one was particular unexpected. In my front-most relationship dialog, I added a table occurrence "Test". I then OK'd my dialogs back to the previous one. Test was not on it, and when I went to add another Table occurrence called "Test", FileMaker automatically renamed it to Test 2 - even though visibly there was no "Test" table occurrence on the graph. Filemaker knew I had created the Test TO in another dialog, and even though this one was not showing it, it was still smart enough to not let me name another Test. Upon OK'ing all the dialogs and then jumping back into the relationship graph, both Test, and Test 2 were present.

Final Thoughts:

If you want to play around with this, you don't need to repeat all the steps I mention above, you can bring up multiple relationship dialogs by:

Going into relationship graph
Ensure you have a relationship, click on it and click sort
Choose a field and choose "reorder based on summary field"
In this dialog, click the To list and choose "manage relationships"
Repeat...

The Replace Field Contents Command - Why It Is So Cool

Wed, 15 Dec 2010 10:35:00 +1300

The Replace Field Contents command/script step is a very powerful tool for updating field values across records in your found set.

The above version of the dialog, is the one that you will see when using the script step. The dialog appears slightly different when running it via the command from the Records menu. There are three possible options you can use:

Replace with Current Contents

This refers to whatever the value is in the field you are replacing on the current record you are on.

This is quite useful, most particularly when you are running the replace manually using the command. Imagine you are on a layout and wish to set "Hello" into records in your found set. The easiest way, is to put "Hello" into the field on your current record, then run the command.

You can see the dialog will show you what records in the found set will be set to. There is another way to get the word "Hello" into the field using a calculation, but this is the fastest way when using the menu command.

Some things to note:

The # of records that will be updated is displayed in the first sentence.
The command works on a found set of records, if you have no found set, the command is unavailable.
When using the command, it is required your cursor be in the field you wish to update. For the script step option, this is not required, because the script step allows you to specify the field being replaced.

Replace with Serial Numbers

Use this option to set sequential numbers into each record in your found set. The first record in the found set is assigned the initial value. Note that it does not matter what record of the found set you are on initially, numbers will always begin from the first record.

If the field you are updating has the auto-enter serial number option enabled, you are given the ability to update the next serial number for that.

Some things to note:

Both the next serial number, AND the increment value will be updated within the fields auto-entry option, providing the update option is checked.
If checked, the next serial value is value of last record in the found set serial number, plus the new increment value set in the command you just run.

Replace with Calculated Result

Perhaps the most powerful option,this allows you to define a calculation which will then be applied to each record in the found set. The calculation you define is evaluated independently for each record.

For example, take a table with 2 fields - A and B. The table contains 3 records. Lets say now that on our found set of all records, we wish to replace the contents of field A. The calculation used is "B + 10":

Value of A	Value of B	New Value of A
1	8	18
99	10	20
12	17	27

As you can see, the calculation is applied to each record individually.

Some things to note:

Referencing related values within the calculation works on a per-record basis.
As mentioned in the "current contents" section - the other way to put the word "Hello" into the field on each record, would be to make the calculation be the string "Hello".

After the replace, a cautionary table about record locking.

If the replace runs successfully, you will see nothing afterwards - the fact that you see no dialog means it all worked. However, if something went wrong, you may see the following kind of message:

This dialog - as informative as it tries to be - only tells you that one or more of the records in your found set, were unable to be updated. There are two reasons why this can happen. The first is that another user of the database is modifying one of the records in your found set. Because of this, they have the lock on that record, and so you are unable to update the record.

Important Note about Errors

FileMaker unfortunately does not tell you which record(s) failed. This is a shame, especially if your replace is run using the script step. If you are updating hundreds of records with important data, then having some fail could cause significant issues later on. Not knowing which ones failed means you either have to re-run the replace at a later time, or bite the bullet and hope nothing bad crops up :) In some cases, the replace field contents step might not be the best method of record updating, and you may instead opt for a looping script, that tries to obtain record lock on each record before attempting to update the field contents.

Even more perilous, is running the replace field contents script step, with the "perform without dialog" option checked. While this will suppress the initial parameters dialog, it will NOT suppress the error dialog if any records were not be updated. To suppress this dialog, you must prefix the replace field contents step, with the Set Error Capture step.

If you suppress the error dialog, you may still need to check for errors in your script. You can do this by evaluating the Get(LastError) function. If the replace failed to update record(s), the error code is 201.

Replacing Related Field Contents

The Replace Field Contents step is perhaps more used, and easier to understand, when it is used on a field which is on the found set table. What you may not know, is that the command can work on related fields as well.

If running the replace via command, the rule is the same - place your mouse cursor in a related field on the layout, and run the command.

The replace will update EVERY related record of EVERY record in the found set!

This concept is critical, you may end up replacing more related records than you had anticipated. Often, you may wish to only update all related records of a single record. To do this, you must make the found set your current record only. You can do this by using the following three commands/script steps in order:

Show All Records
Omit Record
Show Omitted Only

The power of the replace field contents step to update related record values - as well as records in the found set - is very useful and can save time in scripting, but it must be used with great care because it suffers from the same record updating issues as previously mentioned - if not more so !

With all it's potential pitfalls, it can greatly reduce the number of script steps you need to use to achieve certain tasks.

As a final example, consider a parent table "Customer" , and child table "Contacts". For various reasons, the customer name is needed to be stored on each of the Contact records. The name can intially be set onto the child records using an auto-enter calculation on the contacts "customer name" field. But what if the customers name changes after the contact record is created? The auto-enter calculation will not pick up the change. Instead, the change must be forcibly updated on each of the child contact records.

Assuming you are currently on the customer record, you can achieve this many ways, here are 4:

#1: A long way, but potentially safer way

Set Variable [ $CustomerName ; Customers::Name ]
Set Variable [ $CustomerID ; Customers::Customer ID ]
Go to Layout [ Contacts ]
Enter Find Mode []
Set Field [ Contacts::CustomerID ; $CustomerID ]
Set Error Capture [ ON ]
Perform Find
Set Error Capture [ OFF ]
Loop
Set Field [ Contacts::Customer Name ; $CustomerName ]
Go to Record/Request/Page [ Next ; Exit After Last ]
End Loop
Go to Layout [ Original Layout ]

#2: Another long way

Set Variable [ $CustomerName ; Customers::Name ]
Set Variable [ $CustomerID ; Customers::Customer ID ]
Go to Layout [ Contacts ]
Enter Find Mode []
Set Field [ Contacts::CustomerID ; $CustomerID ]
Set Error Capture [ ON ]
Perform Find
Set Error Capture [ OFF ]
Replace Field Contents [ No Dialog ; Customer Name ; $CustomerName ]
Go to Layout [ original layout ]

#3: A shorter way (but essentially the same way)

Set Variable [ $CustomerName ; Customers::Name ]
If [ not isEmpty ( Contacts::Contact ID ) ]
  Go to Related Records [ Contacts ; using layout "Contacts" ]
  Replace Field Contents [ No Dialog ; Customer Name ; $CustomerName ]
  Go to Layout [ Original Layout ]
End If

#4: Short, sweet, possibly nasty (setting thru relationship)

Replace Field Contents [ No Dialog ; Contacts::Customer Name ; Customer Name ]

Final Thoughts:

Hopefully this article has shone some light on the replace field contents step, and what can and cannot be achieved with using it. While it is a very powerful step, with that comes a responsibility to ensure that it is used correctly and without error.

Looking at the various methods in the code above, #4 is definitely the method that I use the most, even though I have rated it as one of the most dangerous. In fact, it is no more or less dangerous than methods 2,3 and 4 - given that all of these steps use the replace step. So if you are going to use any of those 3 methods, you may as well go with the easiest one to write !

I rated method 1 as the safest. It is not shown in the code, but that method - of doing each record update explicitly - allows you the ability to check for record locking before doing your field update. This may be considered overkill for most simple solutions, but depending on how critical it is that records are updated with the correct field values, this may be the safest approach.

Be careful out there !

Safe Scripting: Check Before You Do Anything!

Wed, 15 Dec 2010 10:35:00 +1300

When writing a script to carry out a particular task, ask yourself

"What conditions need to be true for this script to run properly?"

Sometimes, a script will do something which can potentially fail, and cause a cascade effect or errors, IF the initial conditions were incorrect. It is always a good idea to check for suitable conditions before doing anything in the script.

Updating a record

Consider a script that carries out a number of various operations on the current record. What do we need for the script to run properly? The answer is - a record. If your found set consists of 0 records, then why bother running the script? This is a potential scenario, for example, if you do a search which yields no results, your found set will be empty. If a user then tries to run the script, chances are pretty much every script step is going to fail.

This can be avoided by inserting the following few lines of code at the beginning of your script:

If [ Get ( FoundCount ) = 0 ]
 Exit Script []
End If

This simple If statement will check if you have at least one record in your found set, otherwise it will exit immediately.

In fact, it is good practice to follow this guideline when writing all of your scripts. You should first carry out any checks or tests to ensure conditions are right for the script to begin executing. Exit the script immediately if any of the conditions are not right. After your error checking, just begin the script as usual - if execution reaches the point beyond your tests, you know that the tests all passed.

Structuring your error checking

Consider the following example - you have a script that is programmed to duplicate the current record, and do some various actions on the new record such as setting fields, BUT ONLY if the value of the 'status' field is "Completed".

Quite often, this script is written in the following style:

If [ Status â  "Completed" ]
   Show Custom Dialog [ "Error" ; "Cannot duplicate if record is completed" ]
Else
   Duplicate Record
   Set Field [ a ; "a" ]
   Set Field [ b ; "b" ]
   etc.....
   Show Custom Dialog [ "Done" ; "Record Duplicated" ]
End If

While there is nothing particularly wrong with this style, it can make for a script that is difficult to read. Now, consider the alternate style, of error checking, followed by carrying out the action:

/* Check for suitable conditions */
If [ Status â  "Completed" ]
   Show Custom Dialog [ "Error" ; "Cannot duplicate if record is completed" ]
   Exit Script []
End If

/* If script execution gets here, all tests successful */
Duplicate Record
Set Field [ a ; "a" ]
Set Field [ b ; "b" ]
etc.....
Show Custom Dialog [ "Done" ; "Record Duplicated" ]

The main difference is readability - all of your error tests are at the start of the script, and can quite easily be separated for ease of reading. You can group many checks by using "Else If" , or you can keep them individual using separate If/End If blocks.

The other difference is indenting of script steps - the majority of script steps are in the duplication area of the script, it is nicer to have the majority of the script not indented, rather than nested inside an If statement.

Checks within your script execution

Checking for suitable conditions may not necessarily only occur at the beginning of your script, sometimes they are required mid-way through your scripts execution.

Taking the first example one step further, lets assume this time that the record we are duplicating has potentially many child records that are displayed in a portal on the layout. When we duplicate the parent record, we also need to create duplicates of all of the children records also.

Our first check still stands - we can only duplicate when the record status is Completed. Even if the record has no child records, we still need to duplicate the parent record. So what happens when it comes time to duplicate the children?

/* Check for suitable conditions */
If [ Status â  "Completed" ]
   Show Custom Dialog [ "Error" ; "Cannot duplicate if record is completed" ]
   Exit Script []
End If

/* If script execution gets here, all tests successful */
Duplicate Record
Set Field [ a ; "a" ]
Set Field [ b ; "b" ]
Set Variable [ $ParentID ; Parent::ID ]

/* Now, duplicate the children records */
Go to Related Record [ show only related records; from table "Child" ; using layout (Child) ]
Loop
   Duplicate Record/Request
   Set Field [ Child::Parent ID ; $ParentID ]
   Omit Record
   Go to Record/Request/Page [ First ]
   Omit Record
   Exit Loop If [ Get ( FoundCount ) = 0 ]
End Loop
Go to Layout [ Original Layout ]

Show Custom Dialog [ "Done" ; "Record Duplicated" ]

Here, we test for the parent records condition, then we duplicate the parent record. Next, the script uses the go to related record step to make the found set be that of the children records, on the children layout, it then loops through the records, duplicating them and linking them to the new parent record, before returning to the original layout.

NEVER DO THIS !!!!

The script above fails to test whether there are any children records before it executes the duplication part! If there are no children records, then the Go to Related Records script step will NOT switch layout.

As a result, after the go to related record step, the layout & found set will remain exactly what it is on the Parent layout - the script continues and starts to duplicate parent records - duplicating every single parent record in the found set ! - This is a classic example of failing to check for error, and a script cascading out of control.

It is crucial that you script defensively, checking for any potential issue before it happens!

Now, consider the same script, with a small modification before the Go to Related Record code:

/* Now, duplicate the children records */
If [ not isEmpty ( Child::Child ID ) ]
   Go to Related Record [ show only related records; from table "Child" ; using layout (Child) ]
   Loop
      Duplicate Record/Request
      Set Field [ Child::Parent ID ; $ParentID ]
      Omit Record
      Go to Record/Request/Page [ First ]
      Omit Record
      Exit Loop If [ Get ( FoundCount ) = 0 ]
   End Loop
   Go to Layout [ Original Layout ]
End If

Show Custom Dialog [ "Done" ; "Record Duplicated" ]

Here, we are making use of the fact that a relationship exists between the parent & child records. We are doing a test to ensure that there exists at least one child record through the relationship. This is done by using the isEmpty function, checking the primary key field on the children table. A primary key field is guaranteed to have a value in it for every record. So by checking for the existence of a value through the relationship - we are actually checking for the existence of a record. All we care about is if there is at least one record, so this test is sufficient.

If there is a record through the relationship, then the block of code for duplicating child records can execute, otherwise the If statement contents is not executed at all.

Earlier, I noted that you should try to avoid indenting large blocks of code if at all possible - unfortunately this is one time where it is not possible when doing a check like this (FileMaker lacks the ability to "go to" a specific part of a script, thus bypassing a block of code).

One alternative you could employ however, is to create a new script which is responsible for duplicating child records, and your code can then be tidied up as such:

/* Now, duplicate the children records */
If [ not isEmpty ( Child::Child ID ) ]
   Perform Script [ "Duplicate Child Records" ]
End If

Show Custom Dialog [ "Done" ; "Record Duplicated" ]

Final Thoughts:

The more defensive you are with your scripting, the less problems you will have later on. It is a good idea to ensure at the beginning of your script that you test for the conditions (or lack of) that need to be present for the script to execute correctly, such as:

Whether you have a record
Whether one or more field contents is what you need them to be
Whether you have any related records if required
Anything else you can think of that may need to be true in order for the script to run properly

Create yourself a section at the beginning of your script to place these checks, you can use comment script steps to detail each test, and to keep the tests separate from the actual execution of the rest of the script.

Checking for tests at the beginning of the script not only saves the script executing incorrectly later on, it also saves time by not running the script if conditions are not right. While some scripts might run without trouble even if conditions are not right, it will save time to not run them at all rather than run them and have them do nothing of any use !

Error and condition checking is not restricted to just the beginning of your scripts, it may be necessary to test for conditions mid-way through a scripts execution. If possible, try to test for the condition before running the script action - this will save you post-action error checking. Better to not do the action at all, rather than do it, and then have to check if something went wrong, and restore anything that may have happened.

Join My Table Pt 3 - Putting on the Finishing Touches & Extra Features

Wed, 15 Dec 2010 10:33:00 +1300

In part two, I demonstrated how to implement the basics of the join table solution in FileMaker. While the solution works fine as an illustration for join tables, it lacked many of the basic interface features that would make it a usable solution.

In part three, I will show how to implement some of these features, namely the following:

Better selection of a Student for an Enrollment
Deletion of Enrollments
Prevention of over-enrolling a course

Better Selection of a Student:

In part two, selection of a student for a new enrollment consisted of knowing the students ID number and entering it into the field. There was no feedback of whom the student was at any point not very useful for anybody.

A much better way would be to build a value list of students, and allow the user to pick from a pre-defined list. This will give them a visual on the student names. For starters, we will just create a basic value list for students.

We have used the existing Students table occurrence to build the value list, which has also been setup to show all students. This value list uses the option to display a second value. Rather than deal with the students ID number, we have chosen to display the students full name as the displayed field. Underneath, the students ID is still being chosen and inserted into our Enrollments::Student ID field.

Now, attach the value list to the Enrollments::Student ID field in the Enrollments portal. You will see that the students full name is instantly displayed if you are using the pop-up menu option.

Now students can be selected for an enrollment via the pop-up menu. Now, this implementation is still not perfect. For example, there is no restriction on enrolling the same student twice. Also, if you have a large number of students, a pop-up menu is not the best option. A better option would be to use a drop-down menu, which brings with it some advantages and disadvantages. For now, we will stick with the popup-menu to demonstrate the technique, but may come back to these issues in a future article.

Deletion of an Enrollment:

This is a simple one, but a necessary one. We need some way to delete an enrollment. By far the easiest way is to insert a button into the enrollments portal, and attach to it the single script action Delete Portal Row. If you disable the dialog within this script step, the enrollment will be deleted instantly.

Sometimes however, this might be a dangerous action. Hitting the delete button by accident will cause the enrollment to be deleted right away, so you might want to ask the user for confirmation before deleting. Whether a confirmation is ever required is a topic that could be debated endlessly, but the technique would be as follows. First, it is going to require a new script, called Delete Enrollment. The script itself would look something like:

A custom dialog is presented to the user, asking them if they really wish to delete the enrollment. The users action is then captured via the Get ( LastMessageChoice ) function. 1 corresponds to the default button action, typically (though you can specify any action for the default button). If the user has clicked OK, we delete the portal row, otherwise we don't.

Prevention of Over Enrolling a Course:

For this feature, we are going to need to record exactly how many enrollments are permitted for a given course. This is going to be done by introducing a new field into the Courses table called Max Enrollments, type number.

We create enrollments currently by using the relationship option Allow creation of records in this table via this relationship. This has been fine up until this point. But now that we wish to control how many enrollments are created, it is going to make more sense to disable this feature, and script our enrollment creation instead. By scripting the creation process, we can check whether the maximum number of enrollments has been reached, and prevent the user from adding more gracefully. (also, not to mention that having a blank portal row in the enrollments portal as a means to create enrollments is not exactly intuitive for users).

For this, we will need to do three things:

Disable the relationship creation option.
Place an Add Enrollment button to the layout
Create a script Add Enrollment to handle the creation of enrollments.

The script is going to need to do the following things:

Determine if the maximum number of enrollments reached
If yes, then do not create a new enrollment.
If no, then create an enrollment.

Here is the script might look like:

The first thing this script does is two error checks:

If the max number of enrollments field has not been set, then do not proceed, exit.
If the number of course enrollments matches the limit, then do not proceed, exit.
If these error checks pass, then create the enrollment, and set the course ID into it.
Finally, go back to the Courses layout, and place the user on the new enrollment.

Here you can see the new layout design. The blank portal row for creation of enrollments is gone. In its place is an Add Enrollment button. The new field Max Enrollments is also present, and has been set to 3. This means that we should only be allowed to create three enrollments.

It may be a little difficult from this picture to tell what has happened, but I have reached my limit of three enrollments. Now, clicking the Add Enrollment button does nothing.

Can this be made any more intuitive to the user? Well, we could easily place a custom dialog into our Add Enrollment script when the user tries to click the button when the maximum number of enrollments is reached. OR, we can use conditional formatting to convey to the user visually that this is the case, saving them the attempt at clicking the button.

First, we can conditionally format the button to appear inactive when the maximum number of enrollments is reached:

The same type of conditional formatting can be applied to the Max Enrollments field also if you wish.

Every solution presents its own problems. As you may have realised, there is nothing stopping a user from increasing the max enrollments number, creating enrollments, and then reducing the max enrollments number. This is a way for a user to bypass the restriction imposed on the Add Enrollment button. I won't go into detail as to how this can be resolved, but some options would be:

Field Validation on the Max Enrollments field, so it can never be less than the number of enrollments that exist
Script the setting/changing of the Max Enrollments Field
Script Triggers to prevent a user from modifying it to a number less than the number of enrollments that exist.

All would be viable solutions, and perhaps might be discussed in a future article.

This concludes the series on Join Tables for now. Hopefully you have learned something out of these articles, and perhaps picked up a few tips and techniques along the way which will help you turn your basic join table, into something more powerful and user friendly.

Example File:

Please find attached an example file. This file was used for all the screenshots in this article, and the other two parts to the "Join My Table" series of articles. It is fully commented to help you fully understand what is going on in the file.

Download Example File

Join My Table Pt 2 - Building the Example Solution

Wed, 15 Dec 2010 10:32:00 +1300

This implementation assumes you have a basic concept of relational database theory, in particular the use of primary and foreign keys in tables.

As a brief catchup, a primary key is a field in a table which has a unique value for each record. A perfect example would be a serial number field, which has a different number for each record. As good database practice, every table in your solution should have a primary key field, regardless of whether it is used or not.

A foreign key on the other hand, is a field in a table, which contains the primary key value of a record from another table. This is how two records in different tables are linked/related to one another, and indeed is how we are going to link an ENROLLMENT to both a STUDENT and a COURSE.

Table Setup

This solution is going to require the three tables mentioned above. It is very straightforward to create the tables. Each table will require a primary key, plus whatever fields you wish to capture information for, as a very basic example:

STUDENTS:

Student ID (Primary key)
First Name
Last Name
Phone Number

COURSES:

Course ID (Primary key)
Course Name
Location
Start Time

ENROLLMENTS:

Enrollment ID (Primary key)
Enrollment Date
Fee
Grade
Student ID (Foreign key)=
Course ID (Foreign key)

You can see that ENROLLMENTS has two foreign key fields, because we wish to relate an enrollment record to both a STUDENT record and a COURSE record.

Relationship Setup

How you setup your relationship graph is dependent upon personal preference. In fact, you can successfully implement this solution without having any relationships between the tables at all. However if you want to be able to see enrollments for either a student or course perspective on your layouts, you will need relationships.

In this example I will setup the most simplest of relationships. I have related ENROLLMENTS to both STUDENTS and COURSES via the key field associations as mentioned in the above section.

Enrollments::Student ID = Students::Student ID
Enrollments::Course ID = Courses::Course ID

Building a Course Layout

This solution is going to require layouts for data entry. It will most likely have a Students layout, a Courses layout, and an Enrollments layout.

For this section I will focus on the Course layout only. Adding course-specific fields to this layout is easy. The layout is based on the Courses table occurrence, and so you can place course fields straight onto it.

A useful thing to have on this layout would be a list of all the enrollments for the current course. This can be achieved by placing a portal on the layout. The portal will be based on the Enrollments table occurrence. Be sure to select the related Enrollments table occurrence the one that has the relationship between itself and the Courses table occurrence.

The fields you will want to put in the portal are basically all the fields from the Enrollments with the exception of a couple. First, it makes little sense to put Enrollment ID in the portal unless you are using this to identify your enrollments. Second, putting Course ID into the portal is redundant, since we are guaranteed that every record that displays in the portal will have the same Course ID as the parent course record, the relationship defines this condition.

I have pre-populated all tables with a few records to illustrate how this will look. You can see here that the course has three enrollments.

This layout is fine for viewing course enrollments, but more often than not users wish to directly add enrollments from this layout. The easiest way to allow this is to turn on the Allow creation of records in this table via this relationship option on the relationship dialog. You will want to turn it on for the Enrollments side of the relationship, since it is these records you want to create.

Now, enrollment records can be created directly from the Courses layout by entering information into the last portal row.

While this is a fully workable solution so far, it lacks many nice features which make it usable for the average user. Current limitations include:

User must know a Students ID to add an enrollment
No visible way to delete enrollments
No restriction on number of enrollments created

This solution can be taken much further with a few simple techniques, some of which will be discussed in part three to this article coming soon!

Example File:

Download Example File

Join My Table Pt 1 - Intro

Wed, 15 Dec 2010 10:31:00 +1300

Perhaps one of the most asked questions that I see asked here on the FileMaker Cafe is in regards to join tables. While some users have an understanding of what they are, they may lack the FileMaker skills to implement them. Others are unfamiliar with the concept altogether, but will explain their real world example. Usually it is a prime candidate for a join table. This article provides a real world example that will give you an understanding of why join tables are important, and in what circumstances they should be used. The example will then be implemented in a simple FileMaker solution.

Lets get started

Ponder this real world scenario:

Joe wants to build a database to manage the computer courses he offers to senior citizens. Being a one-man business, he only offers five courses. He wishes to capture information on his students, his courses, and who has enrolled in which courses."

This scenario is very easy to understand when reading in plain english. Now lets deconstruct this scenario further.

When building a database from a users specification, one of the first things you should do is identify the potential tables:

Joe wants to record info about his students, so we will need a STUDENTS table.
Joe wants to record info about his courses, so we will need a COURSES table.
Joe wants to record who has enrolled, so we will need an ENROLLMENTS table.

With the main tables identified, can you begin to spot what might be the join table? Perhaps one last step will make it more apparent. Lets define in more specific terms which each table will capture within a single record:

STUDENTS: Information about a particular student.
COURSES: Information about a particular course
ENROLLMENTS: Information about a particular student AND a particular course

How about now? Can you spot the join table? I think it is time to let the cat out of the bag. A join table is a tool by which you link two other tables together, or to put it in more defined terms:

A join table is used to establish a many to many relationship between two tables.

What does many to many mean? Well, in terms of the scenario it means this:

A student can take MANY courses
A course can be taken by MANY students

By using a join table, you are giving yourself much more freedom to capture as much information as you want, without compromising the integrity of your other tables. The STUDENTS table should only capture information about the student, such as their contact details. Likewise, the COURSES table should only capture information specific to a course, such as it's name, location, and start time.

An ENROLLMENT is a thing, it's a tangible, legitimate thing that you will want to capture information about, so it should have its own table.. It will capture who the student is, and which course they are enrolling in. In addition to that, it could capture information such as:

Enrollment Date
Fee
Grade

This information only makes sense if it is pertaining to a person for a specific course a grade is meaningless to a course if you don't know whose grade it is. Alternatively a grade is meaningless to a student if you don't know for which course it was obtained.

Please Do Not Try This At Home:

So why not capture this enrollment information on the students table, and save us the extra table?

Doing this is bad. It is so bad in fact, that words cannot describe that badness it brings, on a badosity meter it would be off the charts. If someone were to try it, lets see how it would go.

Right, so we want to capture enrollment information on the Students table. Well, lets start by capturing information about the first enrollment a student takes in a course. We will probably need some fields to capture this information:

Course ID (foreign key)
Enrollment Date
Fee
Grade.

So far so good. Oh look, Peter Jones just enrolled Join Tables for Dummies which has a Course ID of 5. So I will now go to Peter Jones record, and fill in my information:

Course ID = 5
Enrollment Date = 11/06/2009
Fee = 25.00
Grade =

Great. I have successfully captured all the enrollment information I need for Peter Jones enrolling in this course. When the course ends, I can fill in his Grade and all will be good: But wait.. Peter also wants to enroll in Bad Database Design. Where am I going to record THAT enrollment information? Well lets see, I could just create more fields to capture it, so all do that.

Course ID 2 = 10
Enrollment Date 2 = 11/06/2009
Fee 2 = 50.00
Grade 2 = C

Phew, glad that is over. I have still managed to capture information on his two enrollments:

6 Months Later:

WHAT?? Peter wants to enroll AGAIN in MORE COURSES??? What am I going to do?? I know: MORE AND MORE FIELDS !!!!!

Wrong.

Already this method has gone down the toilet. I am making the problem much worse by adding a new set of fields to the table for every enrollment. Every time a student enrolls in a course, the database schema must be modified. In short, avoid this like the plague. You don't want to know what kind of problems you will get into when you want to start running reports! Some people who have tried this method have also gone the way of repeating fields. Rather than 1 field per enrollment, they create 1 field, with many repetitions one repetition per enrollment. This is just as bad.

Please see part two where I begin to build a system making use of join tables for this example.

Example File

Download Example File

Making Creation of Records in a Portal More User Friendly

Wed, 15 Dec 2010 10:30:00 +1300

FileMaker provides us with the ability to create related records directly from a portal. This is a great and easy way to generate records without the need to script the process, and for that reason it is a popular technique among both new users and Developers alike.

In this example I have a simple relationship setup between customers and contacts. A customer can have many contacts. In order to create records through a portal, the option Allow creation of records in this table via this relationship must be checked on the portal side of the relationship.

Creation of related records works because FileMaker automatically populates fields on the new record that are in the relationship. So in the example above, the field Customer ID will be automatically set on the new record created, thus making it a related record of the current Customer.

However, with great power comes great user interface responsibility :) The default interface is not the most intuitive of designs:

But, with a little bit of conditional formatting, you can make this interface more presentable for users.

FileMaker places a blank row as the last row for creation of records. But to the average user, this might just look like a blank record. It would be nice to show the user that this row is for adding a new record. There are numerous ways to do this, but here is a simple method:

Here, I have placed a label on the last row which tells the user to enter the name of a new contact into this row. Because everything you place inside a portal will potentially show on every row, we need to hide this label on every row except the last row, here's how:

First, place the label inside the portal, ensuring it is placed behind the field.

Next, make the field transparent fill, allowing you to see the label behind.

Now, add a conditional formatting clause to the field. Remember we want to hide the label, so filling the field with a solid colour such as white, will accomplish this.

We wish for every row to fill the field white except for the last row. In order to achieve this, we need to find a distinction between the last row, and all the others. Fortunately there is one - the last row is not actually a record at all. You can tell a record from a non-record by whether or not the row has a primary key value. For contacts - our primary key field is the Contact ID field. Primary key fields should always have a value in them, so we can test whether our row has a value for the Primary Key - if it doesn't then the row must not be a record at all:

The conditional formatting evaluates true for any row that contains an actual record, and false for our special row used for the creation of a record.

Deletion of Records

Finally, using the same idea for the label, we can make deletion of records more intuitive. Consider a simple "X" piece of text in the portal which represents deletion of a portal row:

Again, there is no point in showing the X on our special portal row, because we can't delete it - it isn't even a record!

We can however use conditional formatting to hide the X - this time, we can set it's text colour to the same background colour as the portal

This time, we wish to apply the formatting on just the blank row only, so we do this if the primary key field is Empty.

The end result is quite nice. In this situation I have attached the "Delete Portal Row" script step to the X. However you should note that if you choose to run a script to handle your record deletion, it is always a good idea to check whether the row you have chosen is an actual record, or the special portal creation record, ie:

If [ isEmpty ( Contacts::Contact ID ) ]
  Exit Script []
End If

This block of text should go as the first thing in your script. By doing so, you script will never run it's steps if the user happens to try to delete the special row. Certain actions within your script can in fact create a record rather than delete it ! For example, if your script tries to set a field on the blank row, this will create a record right away. to avoid all issues, do your existence check as the very first step.

Example File

Please find attached an example file. This file was used for all the screenshots in this article, and is fully commented to help you fully understand what is going on in the file.

Download Example File

Conditional Value Lists Pt 2 - Building for Use in Portals

Wed, 15 Dec 2010 10:29:00 +1300

Part two in this three-part series deals with constructing conditional value lists that are to be used within a portal. In part one, the conditional value lists built were for use on a single record on a layout. Portals however may contain many rows, each row being a record with it's own field values.

When a portal is setup, you have the option to specify fields to go into the portal, and the option to attach one value list to each field. This means that the value list you assign must be setup in a way so that it's values can change per portal row as opposed to per record as illustrated in part one.

Here is the relationship graph of the example file. The two table occurrences in blue are those used in part one to build the conditional value lists.

In this example, the two table occurrences in purple will be used to construct the conditional value lists for use within a portal.

Looking at the graph, you will notice these purple table occurrences are related to a table occurrence that is one-step away from the base table occurrence (home). This table occurrence is that of a portal. So the first thing to note is that the table occurrences are related to the portals context, not that of the layout as shown by the blue table occurrences.

The notion of context is important when building value lists. In part one, our context was the layout (Home). Value lists were constructed related to the context.

In this example, the value lists context will be the portal, and so our relationships must be constructed related to the portal context. The reason why will be shown next. Also note that the conditions in the relationships are no different than used in part one - still relating from Sport Category to Sport Category to produce the Sport Name value list, and to produce the Sport Equipment value list - two conditions are used - Sport Category matching Sport Category, and Sport Name matching Sport name.

Here is the setup for the Sport Name value list for use in the portal. The field chosen is "Sport Name" from the first Purple table occurrence. The important thing to pay attention to here is the "show only related values from" option. This is equivalent to the context we want the value list to operate in. For this example, our context is that of the portal, and so I have chosen the portals table occurrence as the context.

By choosing the portal as the context, each row of the portal will build it's value list independent of other rows, and so each row will have it's own value list based on the values of the other fields in the row. So in the same way that the value lists in Part one of this article were built to change on a per record basis on the layout, this value list is built to change on a per portal row basis.

The portal above shows many records, each of which contains a sport category, name and equipment item. Value lists are attached to all three fields, and values were chosen on each row using the same set of 3 value lists.

Final Thoughts:

The trick to having a conditional value list change per portal row, lies within the context you define when setting up the value list. The context (ie the source/left hand side of your relationship) is no longer the layout, but rather the portal. By changing the context to the portal, the value list is generated for each individual portal row so that each row can produce it's own value list contents.

Example File:

Please find attached an example file. This file was used for all the screenshots in this article, and is fully commented to help you fully understand what is going on in the file.

Download Example File

Conditional Value Lists Pt 3 - Assisting with the Selection Process

Wed, 15 Dec 2010 10:29:00 +1300

Note, reading the first two articles will help your understanding of part three greatly. If you already know what value lists are then you should probably be able to follow this article.

In part one, we built a couple of basic conditional value lists to select sport names & equipment items. Part two demonstrated how the conditional value lists could be tweaked for use within a portal. The last part in the series gives some basic techniques to help the selection process from your drop-downs, and ensure that the chosen values remain consistent and correct.

A Possible Scenario:

Typically when using conditional value lists, the whole idea is that the user will select values in a specified order. In this case, the user should select a sport category first, followed by a sport name, and finally a sport equipment item. If the user were to try and choose a sport name without a category, the value list would not be present, given that no category was chosen. The same applies when choosing a sport equipment item without a name or category chosen.

By placing the fields in order on the layout, this provides an intuitive order for the user to select items, and in most cases this is sufficient, the user will quickly learn the order in which to select items.

Lets assume now that a user has chosen a category, name and equipment item. What happens now if they decide they chose the wrong item, and have to repeat the process?

If the user now chooses a different sport category, this may happen:

The new category is chosen, but the sport name & item remain unchanged. The name & item no longer match the chosen category.

Because the user is going to proceed and select a name & item in most cases, this may not seem like an issue. But we can automatically clear the name & item fields to ensure they do not leave it as it stands. This can be done with simple auto-enter calculations.

Putting it into English, we want the following to happen:

When Sport Category changes, clear Sport Name
When Sport Name changes, clear Sport Equipment

By way of inference, when sport category changes, we would expect sport equipment to also clear.

Auto-Enter calculations are calculations which will re-evaluate themselves when any referenced field within the calculation changes it's value - so long as the referenced field is a) in the same table, and b) is a stored (indexed) value.

The auto-enter calculation for the Sport Name field looks like:

Let ( Trigger = Sport Category ; "" )

In this calculation, the referenced field is set as Sport Category, and the result is to set the field (Sport Name) to blank. Note that a Let statement has been used, for the sole purpose of referencing another field, without having to use that field in the calculations result. this is a great technique for any auto-enter calculation you want to trigger.

Similarly, the Sport Equipment fields auto-enter calculation is:

Let ( Trigger = Sport Name ; "" )

Whenever sport name value changes, sport equipment is cleared.

By way of inference, changing Sport Category forces Sport name to re-evaluate, clearing itself - and this action forces Sport Equipment to re-evaluate, also clearing itself.

To see this in action, check out the example file.

Script Triggers to Ensure Correct Selection of Fields in Order:

Script triggers can also be used to ensure that the user selects fields in the specified order. Imagine a simple layout with our 3 fields on it. The user must choose the category, name, and item in that order.

If the user clicks into either the sport name field, or the sport equipment field, without having a category chosen, this action should be disallowed.

A simple script can be written to achieve this, and attached to the onobjectEnter trigger for each field. Consider the script for the Sport Name field:

If [ isEmpty ( Sport Category ) ]
 Go to Field [ Sport Category ]
End If

If the user tries to enter the sport name field, without there being a value in sport category, the script will automatically put the user into the sport category field, in the hope they will then select a category.

A similar script can be written for the Sport equipment field:

If [ isEmpty ( Sport Category ) ]
 Go to Field [ Sport Category ]
Else If [ isEmpty ( Sport Name ) ]
 Go to Field [ Sport Name ]
End If

In this case, the script first ensures a category is chosen, and if not, the user is taken to the category field. If a category is chosen, but a name is not, the user is put into that field. If both category & name are chosen, the user is allowed to proceed and choose a sport equipment item.

Example File

Please find attached an example file. This file was used for all the screenshots in this article, and is fully commented to help you fully understand what is going on in the file.

Download Example File

Building a Timed-Delay Search Filter for WAN Performance

Wed, 15 Dec 2010 10:27:00 +1300

Please note that this article is not in regards to portal-level filtering introduced in FileMaker 11. It concerns filtering of relationships by altering contents of fields that are used in the relationship.

This article is also aimed at an intermediate level user. It assumes you already know the basic ideas behind filtering relationships using a filter field.

Introduction

With the introduction of script triggers in FileMaker 10, live filtering or portals was made possible. Numerous techniques were introduced to help achieve this. In conjunction with existing filtering techniques, the "Live" aspect was achieved usually by introducing an OnObjectModify script trigger to the filter entry field. As soon as the user enters a value into the field, the triggered script would force a save of the fields contents, thus updating the relationship in question, which in turn updated results in a portal on screen.

These filtering techniques work fine on local solutions, and solutions over a Local Area Network, but what happens when the same techniques are used on systems that are used over a wide Area Network - such as the internet?

A basic live filter example

A typical implementation of a live filter is using an OnObjectModify trigger in conjunction with a script. For example:

This script first remembers the cursor position & selection. It then sets the active field to itself, which is sufficient to save the field contents and so force a portal to update its results. The final part of the script restores the mouse cursor position.

When this script is attached to a field using the OnObjectModify trigger you have a basic live filter field ready to be used in a relationship.

Some drawbacks over WAN

The above method updates the field contents after EVERY character inputted. Locally or over LAN, this operation is usually unnoticeable, but over WAN it can be crippling.

In FileMaker, when a record is displayed in a sorted portal, EVERY record in a portal is downloaded to the client machine - regardless of whether it is visible in the portal or not. In addition to this, the ENTIRE record (excluding unstored calcs & container fields) is downloaded to the client. If you have a portal showing 10,000 sorted records, then all 10,000 records are downloaded to your client. If you are connecting over the Internet, then this can be a time consuming operation. They must all be downloaded in order to achieve the sort - an action that happens on the client machine

If you are filtering a portal as you type, then after every keystroke, FileMaker needs to obtain any new records now showing thru the relationship by downloading them. During which time, you will be unable to continue typing into the field until this is done.

When filtering portals there are two ways you can begin - with the portal showing NO records, or showing ALL records. If a portal begins by showing no records, then as soon as you begin typing into the filter field and records are found thru the relationship, they'll need to be downloaded, and this will cause a major slowdown on the initial keypress (or whenever the first set of records are found thru the relationship).

If the portal/relationship begins by showing all records, and you narrow down that set, the slowdown effects of filtering the portal are reduced, but at the cost of a large performance hit in initially loading the portal.

For relationships/portals that are unsorted, FileMaker will download visible records in the portal, so initial load times might be faster, but it still suffers the same fate as you begin to filter, because new records are potentially being displayed in the visible portal which must be downloaded.

The overall performance hit over WAN is noticeable. Users who use filter fields tend to type at a reasonable speed into the filter field - if the speed at which they can do this is reduced due to download times of records, the filter field becomes sluggish and feels unresponsive, which can lead to user frustration.

A nice alternative for WAN performance

Think about a users end goal when typing in a filter field. Most users will know the word/s they want to enter into the field, and will go about typing the entire word until it's entered. For example, if you wanted to locate all people in a database whose name is "Daniel", would you be more inclined to just type "Daniel" and look at the results, OR would you begin typing .... D - (look at results) - A - (look at results) - N (look at results) ... and so on until you see the record you want? I think the first approach is the more common.

So, what about a filter entry field that only shows results once the user finishes typing whatever they want to type? How can FileMaker detect when a user finishes typing into a field? Well, prior to script triggers, a user would have to manually exit the field in order for FileMaker to update the portal. But, by a cunning use of the OnTimer script step in conjunction with an OnObjectModify script trigger, it is easy to detect a pause in a users typing pattern. This pause can be used to update the portal.

This method will allow the user to type their search term at full speed, without constant portal refreshing impeding their data entry. It will then show results when it detects the user has finished typing, or paused for a period of time.

So, how does it work:

At it's most basic level, the method requires two scripts, and a filter entry field.

Script A - Typing Trigger

Script B - OnTimer Trigger

What's Going on in The Scripts?

Lets start with Script A. In this script, you can see it is being passed a script parameter which is set into a variable $ObjectName. The parameter passed is the object name assigned to the filter entry field - this is useful because it makes these two scripts completely generic and they can be reused for any number of filter entry fields in your solution.

The main part of the script is the installation of the OnTimer Script - Script B. We pass the object name to the second script also. I have set a delay of 0.25 seconds on the ontimer. Note that this delay will be the delay between when the user finishes typing, and when the portal results are updated.

The key aspect of this whole thing is that this particular script is the one that is attached to the filter entry field as an OnObjectModify script trigger.

The first time the user enters a character into the field, the onObjectModify script is triggered
The triggered script installs an OnTimer of the second script with a delay of 0.25 seconds.
This means that after 0.25 seconds of no activity, script B will run
HOWEVER, if the user enters another character into the field before the 0.25 second delay, Script A runs again
When it runs again, it RESETS the onTimer for Script B back to 0.25 seconds.

To put it simply, every time the user enters a character, the time to which script B will run is reset to 0.25 seconds. Script B will only run once the user stops typing for that 0.25 seconds.

Script B is responsible for doing the normal filtering tasks. The last step of the second script is to disable the OnTimer script for itself. This ensures that once the user stops typing, this script will run once and once only. If the user then continues typing, then Script A runs and the process repeats itself all over again.

The end result

the end result is a portal which updates it's results after 1/4 second pause of data input by the user into the filter entry field. While the user is typing, nothing happens to the relationship or the portal, resulting in no slowdown of data entry due to records being downloaded. Once the user stops typing, only then is the field contents saved and the relationship/portal updated.

Taking it a step further

I implemented this method in a rather large solution with great results. The system had upwards of 20 filter entry fields on various screens. It soon became apparent however, that for some filter entry fields, numbers were the common type of data entry, whereas others were text/words. For most users, the entry of numbers via a keyboard is a slower task than typing a word. I quickly found that the 0.25 second delay was sufficient for text filter entry fields, but not for those that required number entry, or a combination of text and numbers.

The solution was to pass the Delay to the Typing Trigger script (Script A) as a second script parameter. Now, this script accepts two parameters - the object name, and a delay. For numeric entry fields, a delay of 1 second is more useful because it gives the user time to type in their number. For text fields, the delay can be decreased. To go even one step further, you could make the delay a user preference in the database, so touch typists could have a shorter delay, while a longer delay could be given to "two finger" typists.

Final Thoughts:

While "instant" live filtering is looks great, and provides great visual feedback when filtering, it does have some performance drawbacks most notable over wide area network deployments of FileMaker solutions. Sorting of the relationship/portal also has a great drawback in these situations.

By implementing a short delay between when the user enters into the filter entry field, and when the relationship/portal is updated, an increase in filtering performance can be achieved.

Data entry into the filter field is faster because while the user is typing, no actual filtering is occurring
When the user finishes typing, the results that will be found will typically be fewer and more specific records given that the filtering is now occurring on a full word, or more characters.

Quick Tips #1: Quick Select/Deselect of Mapping Fields in FM11 Import

Wed, 15 Dec 2010 10:26:00 +1300

The issue:

In versions of FileMaker prior to 11, working with the Import Records mappings dialog was easy. You could very quickly select and deselect all mappings by selecting all fields and then clicking one of the arrow mapping icons between any two fields in the mapping.

Clicking on any of the arrow icons above will deselect every arrow.

The behaviour in FileMaker 11 has changed slightly, and so it may appear at first that this feature has been removed.

If you try and click one of the arrow icons in 11, all you succeed in doing is deselecting the selected fields, the arrows remain. Of course you could click each arrow individually, but if you are dealing with large tables that can be a real pain.

The 11 change is subtle - you must now hold down the shift key while clicking one of the arrows, this will select/deselect the mappings for all selected fields.

If you hold the shift key down while selecting the records you can combine the steps. Start by selecting one of the fields, hold shift, and click on the arrow in the row which you want to be your end selection of rows. This will select all the rows between your two clicks, and select/deselect the mappings at the same time.

Putting One Object Into Multiple Tabs

Wed, 15 Dec 2010 10:25:00 +1300

Here is a nice quick technique that will allow you to place a layout object or objects into more than one tab on any given tab control object.

The Problem

With tab control objects, when you place an object inside a tab, then that object is now enclosed within that tab. Switching to a different tab will effectively hide the object, because being on the other tab it is no longer visible.

The Reason

Sometimes however, you may have a layout object or objects which you wish to remain consistent across multiple tabs. It could be a portal, web viewer, text label, or series of fields.

The first solution that might come to mind would be to make copies of the layout object(s) and place them into each individual tab control object, there are some downsides to this method:

Having copies means any change you need to make to one object, you must repeat changes to all.
Being unique layout objects, if you are naming objects for various purposes (ie scripting navigation), then each object requires it's own name, adding some complexity to navigation to the object.
In the case of portals, being different objects means each will have their own scroll bar position, switching tabs may yield a different set of visible records in the portal if the scroll positions are different.
Web viewers will load when first viewed, so when changing tabs you will have each web viewer loading itself, rather than loading once for all tabs.
and so on....

The Solution

The solution to this issue lies in the rules surrounding when a layout object is considered "in" a tab control object, and when it is not. Basically, a layout object is considered outside of a tab if it's top coordinate lies outside of the tab.

Note that a tab actually encompasses part of it's tab label area as well as the inner tab section (see photo).

So, the goal is to somehow get the top coordinate of the layout object(s) positioned so that it lies outside of the tab control object

The Method

To do this, first start with the layout object you wish to place in each tab control, positioned outside of the tab object iself. In this example, I will be using a green circle object.

Next, create another layout object and place this directly above the other object, place it so that it lies above the tab control object.

For the sake of this example I have made the second object a green square. Note that this second object should be a very simple INVISIBLE object - a text label which is just a space, or a transparent no-line rectange, or even a 0pt line would all be acceptable.

Next, you want to select both objects and group them using the group command - Arrange -> Group.

The reason why this is all done outside of the tab control object is that FileMaker will not allow you to group objects that are both inside and outside of a tab control object, it's either all in or all out.

However, once grouped, you can place half the grouped object in the tab control, and half out, and this is what we will be doing.

With the grouped object placed in the correct position, it now appears as if the circle is in the first tab. Changing tabs will show the circle apparently in every tab. In actuality, the layout object - which is now the grouped object - is outside of all tab control objects. The rule in FileMaker is that if a layout object is both in and out of a tab control object, it will appear in front of any other object within the tab. The circle is basically in front of the tab control object in terms of layout ordering, and so appears in front of every tab.

Final Thoughts:
This technique is great, and I use it all the time. You can use the same idea to produce fields/labels that appear beside tab names - rather than have to put the fields into every tab, group them with a single object above the tab control to keep them visible no matter what tab you have selected.

Cheers.

Keeping Merge Fields Tidy on Your Layout

Wed, 15 Dec 2010 10:24:00 +1300

This is a quick and simple tip, and one of my favorites for keeping layouts tidy.

Have you ever added a merge field to a layout, only to find it takes over half the layout, covering other layout objects?

If you try to reduce the width of the merge field, you only end up making it taller in height, and now it may overlap things beneath it.

Things only get worse if that merge field is used in combination with other merge fields, or other text, you will end up with a big chunk of ugly looking text on your layout - while in browse mode it may only be a few words.

The quirky thing about merge fields however, is that the entire contents of the merge field will render in the font size of the first character of the merge field place holder. So in the example:

So long as the very first character -

You can always spot a merge field on the layout when using this technique because it has a very characteristic look about it. Once a merge field is set you can generally forget about it.

If, however you do need to check what the merge field is, the easiest way to now do so is to copy/paste it elsewhere on the layout, and increase the font size of the copy version by 1pt, in doing so, the entire merge field place holder will increase in font size so you can read it again.

When you want to reformat the existing merge field, just select the first "

You can still use this technique with merge fields that exist alongside regular text, for example:

You don't have to set the rest of the merge field font size to 1-2pt if you don't want to. Normally if the font size you want is 18pt or over, you can get away with making the rest of it a readable font size like 10pt, that way you can still easily determine what the merge field is :)

Showing a Sub-Summary Part In-Line With Your Records

Wed, 15 Dec 2010 10:21:00 +1300

A sub-summary report, is a special kind of report where records are grouped together by a specified field known as the "break" field (because it acts as a break between groups of similar records).

As an example for this article, consider a very basic table containing 3 fields:

Country
City
Population

Each record comprises a country, a city within that country, and that cities population. There may be multiple records for a given country, as that country may have many large cities. Others however may only have one or two cities.

A sub-summary report could be run on this table, with a break field of "Country". The output would display countries, and their cities & populations beneath, such as the following:

This is a very typical sub summary report. The sub summary part is in blue, and the body part is in green to illustrate the respective parts (this is just test data, the populations are well off).

This is fine, but what happens if you have many countries with only one city? As you can see in the example picture, England, Japan, and Fiji all have one City listed. Each country thus requires 2 lines on the page - 1 for the country, and 1 for the city.

Wouldn't it be nice if you could somehow show the country and the city on the same line in these situations? Well you can with a little jiggery pokery.

Here is the layout mode view of the report above, blown up to 300%. The key concept in this technique, is that as long as the top edge of the sub-summary field is in the sub-summary part, then it will render on screen when in preview mode.

The technique thus involves reducing the size of the sub-summary part to 1-2 pixels in height, and placing just the top edge of the sub-summary field inside the sub-summary part, as shown below.

This is a modified version of the original report, at 300% a couple of things have changed:

The Sub-Summary part has been reduced to 1 pixel in height.
The "Country" sub summary break field has been positioned so it's top edge is still within the sub-summary part.
City and Population fields have been moved up so their top coordinate is 1 pixel below that of country, and so they still lie within the body part.
Fill colours on the sub-summary and body part have been removed (important!)

As you can see, it appears as though the body-part records begin directly to the right of the sub-summary field. For those countries with 1 city, only one line is used. In actuality, the country is offset by 1 pixel higher than the city and population, but this is barely perceivable to the human eye.

This is a great paper saver for long reports, and not to mention it looks tidier for sub-summary parts with only one record in them.

A Couple of Things to Note¦

As mentioned earlier, fill colours were removed from the sub summary part, and the body part. This is important because otherwise the technique does not work. The reason the technique works in the first place is due to the way preview mode renders the report. When it renders, it renders from the top down. Anything it renders is placed in the top of the ordering on the page.

It just so happens that the sub-summary field renders over-top of the body part just fine, and this gives the illusion that the sub summary part, and body part are in-line with each other (albeit 1-2 pixels out). However when the body part then renders, it's contents are placed at the top of the order on the page. Thus anything in the body part will draw over anything already drawn. Most importantly this means any fill colours used in the body part will appear over top of the sub-summary field, hiding it from view (as an alternative, you can use things such as line separators for between records).

Also note that while the sub-summary field, and body fields appear to be in-line, they can never truly be vertically aligned. The closest you can get is a 1 pixel difference in height, however when viewing a printed report, this difference is negligible.

This technique does not work in Browse mode in FileMaker 10 or 11, and is only useful if you are viewing in preview mode or printing/saving the report. If you try to view in browse mode you will see something like the following:

Example File:

Please find attached an example file. This file was used for all the screenshots in this article, and is fully commented to help you fully understand what is going on in the file.

Download Example File

A Lightning Fast Alternative to the Count() Function

Wed, 15 Dec 2010 10:19:00 +1300

Today, a colleague of mine here at Digital Fusion pointed me to a particular thread on the FileMaker TechTalk Forum in which the poster - Morgan Jones of One Part Harmony posed the following (abridged):

Dear Folks,
I have for many years just used the "Count" function to determine how many related (child) records exist for a given parent record. I just point this function to the unique key in the child records to determine a related-record count.

In cases where the number of related records for a given parent is large (a couple of thousand, for example), FileMaker pops up a progress bar saying "Summarizing field: xxx" when my app accesses a different parent record with many related child records. "Summarizing" can take 5 seconds for a couple of thousand child records when connected via a LAN, and much, much longer if connecting over the WAN.

I'm just wondering if there is a more efficient method for obtaining the count of related records, preferably one that can be done in a single calculation such that FileMaker doesn't have to traverse the list of values of the field referenced in the Count function call.

This is a classic problem with the summary functions that FileMaker provides. I'm sure any developer has been frustrated with the slowness of the Count function across a large number of records.

A brilliant solution was given by Tom Elliot:

In child: unstored calc field = Get ( RecordNumber )
in parent: unstored field = Last ( )
this is based on the *assumption* that neither Last() nor Get
( RecordNumber ) need to traverse records to get a result. Also, I believe that Count() returns the number of values that are non-
empty and valid (rather than unique) - at least that's what the
documentation says

Simple, elegant, and it works unbelievably well. To understand why this method of counting related records works so well, it pays to first understand why Count performs the way it does.

The Count Function

The Count() function, according to the FileMaker help, returns the number of values that are non-empty and valid. The key word here is "valid". This means for example, that if you run the Count function on a relationship of 500,000 records, then every single one of those 500,000 records must be scanned and validated before the total can be known.

So what does this mean? Well, if the database is hosted on FileMaker server it means all 500,000 records must be downloaded from the server to the client machine, the validation check actually occurs on the client machine itself. The slowdown occurs with the downloading of records - slow on LAN, even slower on WAN. Indeed this is what is happening when you see the "summarising record x" dialog.

That is all fine and good, but it is pointless when all we want to do is find the total number of records, without worrying about the validity of the field contents we are counting.

Tom's solution is to skip the Count function and instead use a combination of Get(RecordNumber) and Last() functions.

First, the Get(RecordNumber) function. Typically this function is used to display a records number within a found set of records. if a found count on a layout has 100 records, then the last record will have a record number of 100. that is not to say the record number will always be 100 for that specific record - the record number changes based on the contents of the found set.

Tom has shown that the Get(RecordNumber) function can also be used through a relationship, in addition to a found set.

In the example above, if there are 1,000 related child records, then if we find the contents of the Last records Get(RecordNumber) calculation, then this tells us how many records are in the related records.

There is no need for the Last() function to evaluate any of the other records other than the very last single record. All it needs to do is evaluate Get(RecordNumber) for the last record, it's brilliant !

So in a set of 500,000 related records, the count() function needs to validate 500,000 records , whereas Last() needs to reference one!

Speed tests on 500,000 records in a local database, show that the Count() function takes about 90 seconds, whereas Last() takes less than one second!

This is definitely one of the coolest techniques I have ever seen for FileMaker, and I can't wait to implement it in my solutions! If this technique is old news and been around for years then I apologise (it's new to me!)

FOLLOWUP: An Even BETTER method!

I have subsequently implemented this technique in a customers solution with great results. In the end I did not use the Last() implementation, rather I used the Get(FoundCount) method. This involves creating an unstored calculation on the table you want to count records from, and set it's calculation to "Get ( FoundCount )".

Subsequently, you can count records from any portal by placing on the layout this calculation field, obtained via the portal relationship you want to count. This method works brilliantly, and can be used on both unsorted and sorted portals (the last method requires the relationship to be unsorted.

The solution I changed ended up having about 150 calls to the Count function that I had to change. this involved running a DDR on the solution, and searching for all instances of the "Count" function. It was incredibly fast to make the change, as it required removing the count function, and replacing the field that was being counted, with the new unstored calculation added to the table. Everything worked seamlessly after this change.

The great thing about the using the Get(FoundCount) implementation, is that no additional calculation field is required. The foundcount calculation can be placed direct on the layout from the related table (via the relationship you want to count). Whereas using the Last() implementation, a secondary calculation is required to obtain the record number of the last record.

This is why I now recommend the Get(FoundCount) method over the Last() method!

Keeping Things Organised by Using Separators

Wed, 15 Dec 2010 10:17:00 +1300

There are four main areas of your database where you can use special separator lines to help keep information organised, these are:

Scripts
Layouts
Value Lists
Custom Menus

A separator line is exactly what it sounds like - a line that separates one thing from another.

Scripts

To insert a separator line between scripts, this is done by creating a blank script - the title of which is a single hyphen line "-". You can create these by using the drop-down arrow beside the "New" icon in the Manage Scripts dialog, and selecting "Separator". Alternatively you can create a blank script yourself and assign it the "-" title.

Separator lines can be seen when using the scripts menu. Any separator script that has been checked "include in menu" from the scripts menu, will appear as a single solid line.

Layouts

This separator line is a little less obvious because it is not documented whereas the other ones are. The implementation however is the same as for scripts. You start by creating a blank layout and giving it the layout name of a single hyphen "-". These special layouts can then be positioned in your layout list wherever a separator line is required. The line is then visible from the layout selector while in layout mode, and browse mode providing "include in layout menus" has been checked.

Value Lists

Any entry in a value list which is a single hyphen line will be treated as a separator. These can be added when using a value list that uses custom values. It should be noted however that these separators will not function correctly if the value list is being generated from a field, or list of records. This is because value lists are automatically sorted in these scenarios. If a hyphen has been used in a record, or field value for use in the value list, it will sort incorrectly, and the separator will appear at the top of the value list.

Custom Menus

When creating a custom menu, separators can be from the Custom Menus -> Edit Custom Menu Dialog, by using the "Add Separator" button provided. These separators will appear the same as those for layouts and scripts - a single solid line.

Other Separators
There are other separators that you can create. While they aren't "true" separators, they nonetheless can assist in keeping your database organised:

A blank custom function can help keep your custom functions organised
Grouping on the relationship graph can be achieved using comment boxes strategically placed.
Fields can be grouped by using special separator fields which can have hyphen or blank space names.

Note that for custom function and field separators, you will need to sort them in a custom order respectively.

Let me Tell You 'Bout Let

Wed, 15 Dec 2010 10:15:00 +1300

The Let function is one of the most brilliant and underrated functions in FileMaker, and I think it should be used whenever and wherever possible. This article will give an introduction to the function, some possible scenarios when it should be used, and give an example as to it's use.

Since the dawn of time, man has sought ways in which to simplify his life. That's just a fact. Whether it is accurate or not is a question better left to the scholars. However someone at FileMaker was obviously adhering to this philosophy when they created the Let function.

To put it simply, the Let function can be used to simplify a calculation? How you ask? Well it does this by splitting out parts of a calculation into simpler, more easily readable parts. Think of it like an instruction manual for building a desk: The first thing you need to know is what all the parts are you require, before jumping in and putting those parts together (or something like that... close enough!)

FileMaker defines the format of the let function as follows:

Let({[}var1=expression1{;var2=expression2...]};calculation)

So let's break it down:

1) The function always begins with the word "Let" followed by open bracket. Everything within the function is contained within the opening and closing brackets, i.e:

Let ( )

2) The function has two parameters, the first being variables, the second being the calculation itself, ie

Let ( Parameters ; Calculation )

3) The calculation part is simply a calculation that will be returned as the result. In fact, you could use a Let statement with no parameters. Doing this, would be pointless, but it illustrates what the calculation parameter does, ie:

Let ( "" ; 3 + 4 ) = 7
Let ( "" ; "Blah" ) = "Blah"

4) You may have noticed, had you tried the above two functions, that they don't actually work. The reason being that using a Let statement is pointless without having utilized the first parameter. Indeed it is the first parameter that is where the power of the Let statement lies.

A Good Time to Introduce Variables

The first parameter is Variables. Any programmer should be familiar with what variables are, and indeed any FileMaker developer should know or learn what they are also. In most simplest terms, a variable is something that stores the result of a calculation or function. Ponder the following:

myVariable = 3 + 4

Here, I have created a variable called "myVariable" and set it to 3 + 4. If I were to later check the contents of the variable, I would find it contains the number "7" as this is the result of 3 + 4.

myVariable = "String"

If I checked this variable, I would find exactly what it was set to, that being the word "String". Variables can be set to literal text, numbers, calculations, functions you name it. Basically anything that can be specified within a calculation.

It should be noted at this time that variables occur in three forms within FileMaker:

Local variables (ie $Variable) , used in scripts to store results, numbers, text and so on...
Global Variables (ie $$Variable), also used in scripts, these retain their value for the duration of a users session once set.
Let statement variables. These only exist within the scope of the calculation in which they are used.

Back to the Function

Variables are defined within the Let function in one of two formats, depending upon whether you are defining one, or more variables.

First, we will start with defining more than one variable, the format is as follows:

Let (
[
var1 = 1 + 2 ;
var2 = 2 + 3 ;
var3 = 3 + 4 
]
;
var1 + var2 + var3
)

You can see I have split things out onto separate lines to make it more visible the format. When defining multiple variables, they must always be enclosed in square brackets. Within those brackets, each variable defined is separated from the next by a semicolon. Note also that the last variable does not require a semicolon, as there are no more variables after it.

Here, I have created three variables, and set them to various basic calculations. The first parameter of the function is everything contained within the square brackets. The second parameter you can see is the result I wish to return. I wish to return the three variables contents, added together.

In this basic case, the contents of the three variables are 3, 5, and 7 respectively. With the result defined to be var1 + var2 + var3, the end result will be 3 + 5 + 7, giving an overall result to the function of 15.

Another example:

Let ([
var1 = 4 ;
var2 = var1 * var1 ;
var3 = var2 / var1 ] ;
var3
)

This example, though completely pointless, illustrates the fact that once a variable has been defined, it can be used in subsequent variables that are defined. [B]You cannot use a variable in a definition unless previously defined[/B]. Here, I have referenced var1 in the definition of var2, and referenced both var1 and var2, in the definition of var3. The result is to be var3.

And Finally

Here is an example of a let statement in which only one parameter is defined:

Let (
param = Get ( ScriptParameter ) ;
Case (
param = 1 ; "One" ;
param = 2 ; "Two" ;
param = 3 ; "Three" ; "I Don't Know"
)
)

This example illustrates perhaps one of the most important reasons as to why you would want to use a Let function. Here, the Let function is only defining one parameter, called param. It has been set to the function Get ( ScriptParameter ) so this let statement is most likely being used in a script, where this function is used. The value of param is then checked for one of three values by using a Case statement, and the corresponding result is returned.

First thing you should note is that with one parameter, square brackets are not required. There exists only one semicolon here, and that separates the single variable definition, from the second parameter (that being the case statement).

Second thing you should ask yourself, is why bother using a Let statement here? The same calculation could just as easily have been done in the following manner:

Case (
Get ( ScriptParameter ) = 1 ; "One" ;
Get ( ScriptParameter ) = 2 ; "Two" ;
Get ( ScriptParameter ) = 3 ; "Three" ; "I Don't Know"
)

Both will return the exact same result. The reason why the Let function is better here, is for readability, and speed purposes. First, you will most likely see that the Let function is far more pleasing on the eye than the second function, as you don't see the large Get ( ScriptParameter ) function on every line - it appears only once.

This leads into the second and most important reason - speed. In the Let function, we only reference the Get ( ScriptParameter ) function once, by setting it into a variable. From then on, it is the variable we are referencing, not the function. In the second calculation, we reference the Get ( ScriptParameter ) function three times.

What if we were referencing a far more complex calculation, or custom function, which took half a second to give the result? Well, the first Let function would take half a second. The second one would take 1.5 seconds, because everytime we are calling it, it has to be evaluated.

The key concepts here are:

Ã¢ÂÂ¢ If part of a calculation is going to be repeated many times, then it should be defined as a variable within a Let function

Ã¢ÂÂ¢ If a calculation is starting to look too complex or hard to understand, try splitting it into simpler components as variables using a Let function

Creating a Graphics table for your User Interface

Wed, 15 Dec 2010 10:13:00 +1300

Building layouts in FileMaker can involve adding a number of various elements such as fields, buttons, portals, tab controls, and graphics such as jpg and png images. It is the use of images on layouts that this article is all about.

You may want to use image files on your layouts for a number of reasons, such as:

A background fill, i.e. gradient image
To be used as buttons, or links
Images for design purposes, ie rounded edges, shapes, icons etc.

The simplest way to use images is to insert or paste them directly onto the layout. This can be done by pasting from the clipboard, or using the Insert -> Picture command from the FileMaker menu. When you use these options, the image is inserted directly onto the specific layout. If you then duplicate the image to be used on the layout, then 2,3,4.. and so on images will exist individually on the layout.

What happens if you then have 10 layouts, and you want to use the same image on each layout as a button? You could insert it onto the 10 layouts. In doing so, the image now exists in 10 different locations within the file.

FileMaker itself is smart enough to recognize that the same image has been used multiple times within the file, and so internally, it only retains one copy of the file. This means that a database file with 1 copy of an image in it, will be the same size as a duplicate version of the file, but with 50 copies of the image in it.

This might all seem fine, but what if you then wished to alter any of the images used in your system? Worse still, what if it is a particularly large system, with the same images used on many layouts for purposes such as navigation, or buttons?

If you were to follow the method above, it would require you to manually replace the image in question on every layout, a tedious and time consuming task. FileMaker does not give you any way to change the internally stored image within the file, when it has been inserted or pasted onto a layout.

The Alternative Approach - Using a Table:

There is, however, a way in which you can change images, and have them update everywhere in your system. This is achieved through using a special table called a Graphics table. In fact, any table will work fine, but it is good practice to keep your images that are used for User Interface purposes in their own separate table.

This special Graphics table will contain fields that are of the Container type. Containers fields are special fields that allow you to store things such as images and video, as well as files such as PDF documents or excel spreadsheets.

Let's consider a solution in which you have 10 icons you wish to use as buttons throughout the database. These icons will appear on many layouts. The first thing to do is create 10 container fields in the Graphics table, and name each field appropriately.

You will also want to set the storage of the fields to be "Global". Having the image fields as global, means that they will be able to be referenced from any layout within the file, without the need for a relationship between the layouts Table Occurrence, and the Graphics Table Occurrence.

Once the table is created and setup, the next step is to insert the icon images into the relevant container fields. This process should be done when the file is offline (ie not being hosted on FileMaker Server). By setting the container fields offline, the icons will remain in the fields when that file is later hosted on Server.

The icons are now all set and ready to be used. Rather than inserting images directly onto layouts, now you will be adding the relevant container field to the layout instead. It is the container field that will be displaying the icon now.

The beauty of the whole setup is that to later change an icon, all you need to do is change the icon in the container field, and it will change on all layouts where that container field is displayed.

Using this technique, you can take it further to achieve other kinds of functionality, such as:

Multiple records in your graphics table. If your database has various levels of users, you can create a graphics record for each type of user. Each record contains slightly different graphics, and colours, so that the users have a different user experience, it can also be used as a way of distinguishing users in the system. The graphics record a user is assigned, and thus displayed, is managed internally in the system via relationships and other techniques.
Very fast to alter a user interface experience. If you are developing a system for a user, this can be a great way to quickly change the look and feel of your solution, without completely redesigning the layouts. If you use container fields for background colours, fills, navigation, buttons and so on, then you can completely change the look of your layouts in a couple of minutes.

Using an Offscreen Window to do a Scripts Work

Wed, 15 Dec 2010 10:06:00 +1300

This is a simple technique that I use all the time and find works very reliably. It involves having a script create a new window into which the script executes it's necessary steps, before closing it when done.

Sometimes during a scripts execution it may be required to switch the current layout to another, perform some operations on that other layout, before returning back to the main layout. When this happens, the user should expect to see nothing out of the ordinary occur - to them, the layout didn't change at all.

There are however a number of things that will change/happen when a layout loads:

Tab controls will revert to their default tab
Portals will reset to the top of the list
OnLayoutLoad and OnRecordLoad script triggers will execute if set.

Sometimes these are undesirable and you don't want them to happen when a script is run. To remedy this, you can use the offscreen window technique.

As an example, consider a simple 2 table database, containing a Customer table, and an Invoice table. A one to many relationship exists between the two, that is to say, one Customer may have many Invoices.

The customer "Joe Bloggs" has about 100 invoices, which are displayed in a portal on the layout. In addition to this, there is a tab control object with 4 tabs to separate information such as "Personal Details" , "Banking" , "Relationships" and "Invoices".

One of the databases features is a "Duplicate Invoice" button that is located inside the Invoices portal. When a user clicks the duplicate invoice button, the selected invoice needs to be duplicated.

A typical script to duplicate the chosen invoice might look like this:

Set Variable [ $InvoiceNumber ; Get ( ScriptParameter ) ]
Go to Layout [ "Invoices" (Invoices) ]
Enter Find Mode []
Set Field [ Invoices::Invoice Number ; $InvoiceNumber ]
Perform Find []
Duplicate Record/Request
Go to Layout [ Original Layout ]

Here, the chosen Invoice number from the portal is passed as a script parameter. The script goes to the Invoices layout, finds the invoice in question, and duplicates it before returning back to the original layout.

The trouble here lies with what happens when the script returns to the original layout:

The visible tab will no longer be "Invoices", instead, it will revert back to the default tab, most likely "Personal Details". For the user, all they will see is a tab change, with no other feedback, it is a very disorientating and unwanted result.
The invoices portal will have jumped back to the top. If the Invoice the user clicked was halfway down the portal, it will no longer be visible.
If the layout has any OnLayoutLoad, or OnRecordLoad triggers, they will run. This can be particularly annoying especially if these scripts do unintended user interface things (such as changing tabs, or record).

And the Alternative Approach:

The alternative approach here is to first create a temporary offscreen window, have the script operate in that window, and close it when done. The main benefit of this approach is that the original window remains untouched, this means active tabs will be preserved, script triggers will not run, and no portal positions will be affected.

The modified script is shown below, with new steps in bold:

Set Variable [ $InvoiceNumber ; Get ( ScriptParameter ) ]
New Window [Name: "Temp"; Height: 0; Width: 0; Top; 0 ; Left: -5000]
Go to Layout [ "Invoices" (Invoices) ]
Enter Find Mode []
Set Field [ Invoices::Invoice Number ; $InvoiceNumber ]
Perform Find []
Duplicate Record/Request
Close Window [ Current Window ]

Here, you can see a new window is created as the second step. It's left coordinate is set at a low negative number, ie -5000. The script executes in this window, before closing when done.

It may be that -5000 may not work for you, it all depends on your screen size, or whether you operate dual monitors. Whatever the case, a negative number should be found that works for you. To abstract this, you could set this value into a global variable $$OffScreenLeft upon startup. This means you will only need to set it in one place in your solution.

You should also note that given the fact an offscreen window is created, we don't want to end up in the situation where the script bombs out, leaving the user in this small offscreen window. Even worse, you don't want to leave this window open ever or it may create confusion later on. You will need to be smart in your scripting to ensure that no situation will arise where this window can be left open.

In the case of the script above, I felt it safe enough not to include error checking on the find, however if you feel the script may be used elsewhere, or for another purpose, it may be useful to include error checking, such as the following (in bold):

Set Variable [ $InvoiceNumber ; Get ( ScriptParameter ) ]
New Window [Name: "Temp"; Height: 0; Width: 0; Top; 0 ; Left: -5000]
Go to Layout [ "Invoices" (Invoices) ]
Enter Find Mode []
Set Field [ Invoices::Invoice Number ; $InvoiceNumber ]
Set Error Capture [ On ]
Perform Find []
Set Variable [ $Error ; Get ( LastError ) ]
Set Error Capture [ Off ]
If [ Get ( LastError ) = 0 and Get ( FoundCount ) = 1 ]
  Duplicate Record/Request
End If
Close Window [ Current Window ]

Here, error checking has been added to the find to ensure that a) the find is successful, and b) that we are only going to duplicate 1 invoice only. Whether or not the script worked or not, a window was created, and thus must be closed as the final step.

Final Thoughts..

Remember, you are ultimately building databases for users, and so usability and the users experience should be one of your top priorities when developing a solution, more often than not it is the little things that matter!

Conditional Value Lists Pt 1 - What Are They & How to Build Them

Wed, 15 Dec 2010 00:00:00 +1300

Conditional Value lists may be the most asked about piece of functionality on the FileMaker Cafe. To try and provide a thorough and easy to follow explanation of what they are and how they work, I decided to write an article on the subject and build a small example file to help illustrate the technique.

What is a conditional value list?

A conditional value list is any value list whose contents can dynamically change. The most common method to change a value lists values is to change the contents of another field. In this case, the values that are displayed in the value list are dependent upon the value in the field. Indeed, the terms conditional and dependent can be interchangeable.

Why are they used?

Conditional value lists are a great way to narrow down the size of large value lists by breaking them down into smaller manageable lists. They also help when you need to select values for 2 or more fields. The easiest way to show this is to jump straight in with a straightforward example.

Sport Equipment Example

I have a database that is used for recording a large variety of sporting equipment. I have a sport table that contains the following fields:

Sport Category
Sport Name
Sport Equipment

Each item of equipment can be categorised into a specific sport, and that sport falls into a specific sporting category. Examples of sporting categories might be Ball sports, stick sports, contact sports. A sport name might be Hockey, and for that sport the equipment could be a stick, a puck, a net, or gloves.

Lets imagine now, that the database also acts as a way to hire out sporting equipment. When a piece of equipment is hired out to someone, a record is created in the database, and that item of equipment is captured on the record.

One field, one value list?

The piece of sporting equipment could be recorded into a single field. One of the problems with this is if there are many thousand items of sporting equipment, the value list is very large and may be tedious to select the item.

Consider also, that many sports contain the same type of item. for example Netball, Basketball, and Ice Hockey all have nets, so if you chose "net" as the item of equipment, how would you know what type of net it is ?

Three fields, three value lists

A more clear solution is to define the item of equipment as a category, name, and the item itself - basically use the fields already in the sport equipment table.

The first step is to select a category - there are far fewer sporting categories than there are items of equipment, so selecting a category should be very easy.

With a category chosen, the next step is to choose a sport. There is no value in showing EVERY sport, instead, what you would expect to see is just the sports that are of the category you have chosen. Again this will keep the list of sports much smaller and more manageable.

Lastly, to select an item of equipment, you would expect to only see items of equipment that belong to the sport you have chosen, which itself belongs to the category you have chosen.

Constructing the Value Lists

The category value list is easy. It's just a straight up value list of all sport categories from the table. The "All Values" option is used in the value list.

The sport Name value list is the first of the "conditional" lists. Conditional value lists are built using the "Include only related values starting from" option in the value list setup. Because of this, conditional value lists also require you to create a relationship for the purpose.

In the image above, I have created a relationship between my main table (which contains the fields I am entering values into), and the Sport Equipment table. The condition on the relationship is Sport Category = Sport Category. This means the relationship is setup to only find sport Equipment whose category is the same as the category I have chosen. That is the condition. By building a value list based on this relationship - the value list will also only show sport names which belong to the category I have chosen. Note that relationships & value lists are basically the same thing - the value list is showing records through the relationship you define.

Here, you can see the value list built that is based on the relationship created above. The field the value list is displaying is Sport Name through the relationship. The most important part of the setup is the "Include only related values starting from" option - in this case it is set to "Home" which is the table occurrence on the left hand / source side of the relationship.

The end result is a list of sport names for the chosen category.

Taking this principle to the next step, the Sport Equipment field can have a value list built which shows just equipment for the chosen category AND name. In this case, the condition is that my chosen sport category AND name, matches all Sport equipment records with the same category and equipment.

Here is the relationship created for the second value list construction. The two conditions are specified.

The value list is built in the exact same way as the one for Sport Names, however this time the new relationship is chosen, and sport equipment will be the field in the value list.

(the results of all 3 value lists are shown in the earlier pictures).

Final Thoughts:

That's it, it's just that simple. Conditional value lists are built using relationships. the condition part refers to the fact that the values are dependent upon a value you choose in another field - that field is then used in the relationship to narrow down the records through the relationship - and thus the records in the value list.

Example File

Please find attached an example file. This file was used for all the screenshots in this article, and is fully commented to help you fully understand what is going on in the file.

Download Example File

Weetbicks Gone Wild (and portals...)

Wed, 15 Dec 2010 00:00:00 +1300

Introduction

You may have noticed a lack of article postings over the last couple of months, and fewer articles overall this year. Please don't panic for it has not been through laziness or lack of content.

What have I been up to

Next year I am taking 5 months off work at Digital Fusion and heading to Africa where I am riding in the 2013 Tour d'Afrique. This is a 12,000km cycle adventure that sees myself and around 50 other riders wind our way from Cairo to Cape Town. I have been saving for this trip since 2009, registered in 2010 and this year have finally paid for it and began preparing.

Cycling is in my blood and this is definitely my biggest cycling adventure to date. A few years ago I cycled across the USA solo but that pales in comparison to the challenge ahead - but its challenge that is the primary motivator for me and I can't wait!

Cycling for a Cause

As part of my trip I have chosen to fundraise for a great charity in both New Zealand and Australia called The Heart Foundation.

The Heart Foundation is a charity that relies on donations and funding to help sponsor their research into the prevention of heart disease, as well as promoting healthy eating and healthy lifestyles in general.

Please consider making a donation in support of my ride for the heart foundation. Any amount will be greatly appreciated by myself and the foundation and you can be assured your money is going toward helping people to lead better and healthier lives.

You can make a donation through the Weetbicks Gone Wild site here.

How you can follow along

With the help of my colleague Captain 404 (aka Phil Taylor) we have created a website for my trip which you can visit to check out all the info, donate, and keep up to date of preparations, and posts from the road.

I will be taking a small amount of technology with me in the hope that I can post regular updates during the ride along with photos - as internet speed permits! You can check out the site here.

Now, this IS a FileMaker site after all?

You didn't think I would write a whole article and not make any mention of FileMaker did you? Okay here's a quick tip for something that has always bothered me in FileMaker but is now fixable in 12.

Ever create a portal and want to suppress the grey (black on windows) highlight that appears when you click inside a portal row? Normally this is avoidable if your entire portal row is a button, perhaps for selection purposes, but in the case of a regular portal this highlight can be really annoying and detracts from the visual appeal of your portal.

I tried various methods to resolve this and found the following method all but eliminates the default portal row highlight:

1. Place a text object in your portal and resize to to fill the portal row
2. Assign it the 'Exit Script[]' step essentially making it a button
3. Change to the 'Pressed' state, and set the fill to 'none'
4. Set the button at the back of the portal and lock

By removing the pressed visual cue on the button, the end result is from the users standpoint they are not clicking a button at all, rather just a blank space. The button suppresses the portal row highlight from appearing!

Even Cooler InLine Labels

Wed, 15 Dec 2010 00:00:00 +1300

Introduction

One of the cool things that conditional formatting has allowed us to do ever since its introduction in FileMaker 9 is to build inline field labels that become hidden when the field contains text. With the introduction of field state formatting in FileMaker 12, we can take these inline labels even further and make them even more awesome.

The Conventional Label

Below is an example of a typical setup of an inline label.

Here the label is 'Category'. The label is simply placed underneath a transparent field, and conditional formatting is applied to the field itself:

The conditional formatting is very simple, and tells the field to fill itself with a solid colour if its contents is not empty.

This method works great and can be very useful particular for data entry fields. One issue it has however is that as soon as the user clicks into the field, the label disappears. This is because the field has its own in-focus fill set which could not be modified prior to FileMaker 12.

Keeping the Label Visible

So how can we keep the label visible even if the user clicks in the field? The solution lies in a couple of technologies being used together to achieve the desired result.

First of all, we are going to keep the same field and and same label in the same spot, but we will remove the conditional formatting on the field, this will not be required. We will also keep the field with a transparent fill for its normal fill colour.

Next, we are going to change the fill colour for when the field is in its 'in focus' state. When in this state, it basically means the mouse cursor is clicked in the field. For us, we essentially want the field to have no fill at all, thus revealing the inline label.

Now, there are a couple of oddities here around selecting the fill colour. First, this technique won't work if you select "no fill" as the fill, nor will it work if you select a fill with 0% opacity (in other words transparent). I'm not sure why, but as soon as you select either of these as the fields in focus fill colour, it will treat the field as having a solid fill when clicked in. What I mean here is that the underlying/overlaying label will be hidden.

The workaround for this is to set the fill colour to a 1% opacity, so not quite transparent, but pretty damn close!

Now, when you click into the field you should see something like the below:

This is the type of effect we are trying to achieve - having the label remain visible even if the cursor is placed in the field. The in-focus formatting is applied, which is a 1% opacity fill, thus revealing contents behind or in front of the field.

Now, what happens if we type?

Well, the result is not very pretty!

As we type, there is no conditional formatting happening to make the label disappear. Also, we are unable to apply conditional formatting to a field state, so we cannot tell the field to fill itself if it is not empty while in the in focus state.

So how do we make the label disappear upon typing? The answer here is to use a combination of conditional formatting on the label and a very simple 1 line script that will trigger the conditional formatting with minimal interruption to the user.

First comes the conditional formatting. This is applied to the label directly. The formula will apply conditional formatting when the associated field is not empty.

The formatting itself is a change in the labels font size, we will increase its font size to 500pt, this should be sufficiently large enough that the font will not render within the bounds of the text label object, basically hiding it.

So, if the field is not empty, the label disappears. In order to make this happen we run an onObjectModify triggered script on the field

The script simply does a Set field step and sets whatever the active field is to its own contents. This simple action is enough to trigger conditional formatting on the layout without the need for a refresh window step (which is slower).

So in Summary...

Set field to 1% opacity in focus fill
Set label to font size 500pt if field not empty
Set onObjectModify script trigger on field to conditionally format

Example File

Please find attached an example file. This file is provided to help you fully understand what is going on in this article, and to let you experiment with your own labels.

Download Example File

And Finally...

This will be my last article for the next 6 months. In January I am starting a cycling journey in Africa from Cairo Egypt all the way south to Cape Town South Africa. Suffice to say, internet connection will be sketchy and I won't have a copy of FileMaker with me :)

Thanks to all the readers of this site for your support this year. I apologise for not having written more than I did the previous year, but this trip has really taken over my life and occupied my every waking minute, but I didn't want to leave you without one final article for the year so I hope you enjoy it.

Please also remember that I am fundraising for the Heart Foundation as part of my adventure next year. These guys do amazing work in NZ and Australia for all ages and I would love it if you were able to make a small contribution toward the cause if you can.

You can make a donation via the website I have created for the trip by clicking the logo below. Thank you again.

Cheers,
Daniel

A Portal Grey Area

Wed, 15 Dec 2010 00:00:00 +1300

Introduction

Ever wondered why when you place your mouse cursor in a portal row, the background fill of that row goes grey (or for our Windows friends it used to go a ghastly black colour)? Me too, in fact I have spent many restless nights pondering this baffling design quirk of portals. It may be useful if you temporarily forget which portal row your eyes are looking at and need to quickly re-align your vision but does that ever really happen? The fill is not a highlight either. The active portal row really has no significance in the selection of a record, nor is it of any benefit if running a script from the portal row - the script knows what the active row is without you first putting your cursor in it.

So why does this occur? I cannot answer that question, but what I can answer is how we can now get rid of it once and for all!

How we used to get rid of the fill

Back in 2012, I posted this article which gave a technique of how you can eliminate this fill colour. It involved adding a white filled object into the portal row with an "Exit Script" step attached and no hand cursor. The result was when a user clicked in a portal row they were in fact clicking a button unbeknownst to them, and never able to click the portal row to make it active.

With FileMaker 13 this active portal row fill is now a customisable setting and we can completely eliminate it.

How can we do this

The first thing you need to do is to go into the portal setup and tick the "Use active row state" option. This may seem counter-intuitive - surely you would want to disable the active row state in order to prevent any fill. In actuality, keeping it disabled gives the default grey fill behaviour.

Next, select the portal and in the inspector go to the Appearance tab. Choose "Portal: Row" from the object drop-down (it defaults to Portal) and then choose the "Active" state underneath.

There is your grey fill! You can now chose no fill colour to get rid of it (or if you are sadistic any other colour of your choosing).

Finally, you'll notice the borders are on by default for the active row. The border defaults to the same colour as the grey fill which is why you never notice a border. Now that we have removed the fill you will also need to disable borders otherwise clicking in the active row puts a visible border around that row and looks a bit weird.

Conclusion

Active portal row fills can have their uses in some situations, but in our experience they are just a nuisance. Typical highlights serve a purpose such as selecting a portal row record and are achieved using other methods such as conditional formatting. Knowing which portal row is the active row does not have many purposes aside from giving you a visual cue which portal row you last clicked on. If you have ever found this active row fill annoying then you can now get rid of it forever :)

Example File

Please find attached an example file. This file is provided to help you fully understand what is going on in this article. Note that FileMaker 13 is required to view this example file.

Download Example File

iPad is Go

Tue, 30 Nov 2010 07:50:00 +1300

We've just built our first solution for the iPad, a "Farm Diary" which allows a farmer to work from a map of the farm, tap on a paddock and see a history of what's happened - what fertiliser has been applied, how many stock are (supposed to be) in there, when it was cultivated, and so on. Another tap adds an action and captures details.

The diary will replace years of tatty old notebooks that the farmer has kept - while the notebooks are a vital tool on the farm, they're not able to be shared between staff (3 in this case), can't be searched or summarised (how many acres of maize have we got this year?), and are at risk of getting lost or soaked - one of the guys told us how he was repairing a flood pump when the gate opened and dowsed him in water flowing at something like a "44 gallon drum every few seconds" - of course that wouldn't be much good for an iPhone either but the difference is that the iPhone would be backed up and is easily reinstated.

It's early days yet - we've sent v1 out for field trials (so to speak!) One thing that's pretty obvious already is that details of workflow, such as minimising typing, having a back button, and having just enough information but not too much are vital in a mobile application.

We've designed each screen to be very big and clear without too much information so it's quick and easy at a glance to read. Likewise buttons and fields are oversized compared to a desktop database making it easy to tap with a finger.

The farm diary is built using FileMaker Go, a version of FileMaker for the iOS devices as they're collectively known (i.e. the iPhone, iPod Touch and iPad). What's most amazing about FileMaker Go from a technical perspective is that it is very close to a full replica of FileMaker on the desktop - in other words, it's a very powerful database that can be highly customised.

At the moment the database is designed for the iPad screen size, but since FileMaker Go works on iPhone too and iPhones are a lot easier to carry around in your pocket I can see that we'll need to create screens for the iPhone too very soon - that's easy enough to do with FileMaker Go; likewise for landscape and portrait views, but you end up with 4 versions of each screen. The catch then is that any change you make has to be made across all 4 versions of each screen, so for now we're just focussed on getting it right in one screensize and orientation (iPad / Portrait).

We'll keep you posted on how it Goes...

FileMaker 11 Released

Thu, 27 May 2010 15:00:00 +1200

Continuing the onward and upward march was the recent release of FileMaker 11, featuring some very nice charting capabilities, and a raft of developer and user improvements. Here's a quick recap on the highlights:

Charting
Graphs can now easily be produced from data, in an Excel-like manner. You have a choice of Bar, Horizontal bar, Line, Area and Pie graphs.

QuickFind
There's a new version of Find available, which searches multiple fields on a screen for data that you enter. Up until now, a find has targeted just one field at a time.

Quick Reports
If you use Filemaker to create your own reports, you'll find the new spreadsheet functionality of Quick reports a boon. You can group and summarise data on the fly and easily modify reports by adding, sorting or hiding fields and records.

Reduced Screen-flicker on Windows
The annoying screen flicker that was present in some Windows operations has been much reduced.

FileMaker 11 Server
In a testament to the superb project management at FMI, they updated Server at the same time: FileMaker Server Advanced now has no limit on the number of users apart from the limitations of your network and server hardware of course. This reflects FMI's confidence in the performance and reliability of their database engine: improvements made in the previous version are now well proven.

FM Server includes an array of features and enhancements as well, including Backup to Clone, better security, better admin console stability, and more statistics.

All-in-all FileMaker 11 is a solid and easy update that we recommend everyone take up. Let us know if you need a hand with licensing or installation.

FAQs
Can we have some of our users upgrade to FM11 and others remain on FM10?
Yes, although it would pay to discuss it your developer, because if your system is being changed to take advantage of new FM11 features, we'll need to bear in mind that not all users will be able to use the features. It won't break anything for FM10 users if they encounter FM11 features, but they won't be able to use the new features.

Do we need to upgrade FM10 Server if we upgrade some or all of our clients?
No, FM11 will connect to a FM10 Server.

What are the systems requirements?
Mac users: Mac OS X 10.5.7 or later; Windows: Windows Vista or 7

Is a conversion process necessary to migrate the data?
No, FM11 will open a FM10 database without any conversion.