Introducing FileMaker Kanban. This tool organizes data such as tasks in a visual way into lanes and cards. It is familiar for users and flexible for developers. The tool provides a full suite of data-management functionality. A FileMaker user can organize the tasks into different lanes, reorder the lanes, edit the data, and add new cards to the board and to FileMaker.

Familiar for the User

Kanban provides a rich and familiar interface for all FileMaker users.

They can clearly see the organization of the tasks as cards on lanes. Further, any user can move the cards or lanes, repositioning them on the board and saving the position back in FileMaker. Cards can be added to the board, data can be edited. There’s a lot of functionality possible.

Flexible for Developers

FileMaker Kanban is just that. It consists of a layout, a web viewer, and some scripts. That’s it.

These scripts allow the developer to make many changes including:

  • Change the color of the board background
  • Remove dragging functionality
  • Remove editing functionality
  • Use data to change the color of a card background

And much more. Find out all the possible customizations.

The scripts that run from the FileMaker Kanban board can be easily disabled or adapted for any custom app.

And the data that generates the board is a JSON object, which can be constructed in any number of ways using just FileMaker. The example uses tables and fields and records, but that’s only one way.

Give FileMaker Kanban a try

Read more about Kanban and download the demo and see how Kanban is easy to use, to implement, and to customize. The demo is fully-featured, though it does limit the data to three lanes, and shows an additional lane with relevant Geist Interactive blog posts.

 

We love Kanban, and we are excited to use it in our daily work. See if it works for you.

 

Lance Brandenberg, Solutions Architect here at Geist Interactive, will present a session title “Testable FileMaker Custom Apps”, focusing on FileMaker testing.

He is a first time speaker at DevCon, and we’re excited that he is another voice in the ‘testing-in-FileMaker’ conversation. He hopes to jumpstart the topic again and get folks talking about it because, as he will argue in his session, FileMaker developers have more of a need to rely on testing.

His session is Wednesday, August 8, from 1:00 p.m. to 2:00 p.m. Here are the details:


Session Description

With the release of FileMaker 16 and native JSON functions, it’s easier than ever to create testable FileMaker apps. We will walk through a simple example of what testing is, and how it can improve your solutions. Most developers have had situations where they need to alter some existing logic, and are concerned that they might alter something with unforeseen consequences. Wouldn’t it be nice if you could ensure that your changes didn’t break existing code? Welcome to FileMaker Testing.

Recommended Background

How to write modular scripts, trapping for errors, and some experience with using JSON objects.

Session Objectives
  • What is Testing?
  • How to write testable scripts
  • Benefits of testing
  • Custom functions needed for testing

To get a better understanding of this topic, I sat down with him over RingCentral and asked some questions. Catch the video here of our interview. You can also read it here.

Here’s our conversation in written form:

Q: Who are you? What experience do you have in FileMaker?

A: Lance is a Solutions Architect at Geist Interactive. He’s been working in FileMaker since 2006. He stumbled into the platform while running a screen-printing business. Like many of us, he decided to get out of that game, selling the business in 2011 to become a full-time FileMaker developer. He’s in San Diego, and really enjoys working at Geist Interactive so that he gets access to the cool tools that Todd and the company have developed.

Q: Describe your session.

A: Lance’s session “Testable FileMaker Custom Apps”, on FileMaker testing. Building FileMaker solutions so their testable is interesting. There doesn’t seem to be a lot out there in the FileMaker space, so he’s excited to start that conversation. There’s a lot of ground to cover: modular scripting, custom function libraries. For attendees, you’ll see the benefits of testing and some live coding to see how to build these tests. (Lance will be brave and live-code!).

Q: Why is FileMaker testing important?

A: Remember the game “Wack-a-Mole”? It’s extremely close to how we develop in FileMaker in complex apps. We develop a new feature, and that has the potential to break something already working. Lots of feature requests means we need to test more, and we then need to develop a robust testing methodology. It’s possible we don’t test enough since we do have the rapid-application-development platform, but we really need to.

Testing allows you to build more durable solutions. If you write a test a year ago, and you add a feature today, you should be able to run the test causing nothing to break. We don’t have to worry when we deploy that something’s going to break. If we rely on tests and new tools that we have such as the Data Migration Tool.

It is not simple to test, but it is highly worthwhile. Testing is specifications in code. Scripts that run tests are run by anyone.

Q: What is a tip or trick that you’re going to demonstrate in your session?

A: Lance hopes to have a FileMaker Testing Generator file built. It is similar to our Generator file. A FileMaker developer can create a test using script comments written in a standardized JavaScript form. Test-writing seems boring and challenging, tedious. Lance’s Testing Generator file will help write tests a lot quicker with no mind-numbing work to do.

Lance welcomes anyone to continue the testing generation idea.

In all of software development, testing is complex. We have to be aware of what testing can achieve, and we also should test everything we can anticipate.

Q: Does the person who develops the code also test?

A: The best way to produce tests is the developer who makes changes or creates new features. She knows the system inside and out and knows how the app should work.

Q: Is Testing different than QA work?

A: Yes. A QA person is operating like a user, doing some user testing. What Lance will talk about is more analogous to functional testing. Lance will demonstrate with a purchase order system where a developer is adding new features and how to add tests to accommodate those new features.

Q: What materials will be available?

A: Lance has three libraries on GitHub libraries: JSON Validations, a custom-function library, and an error tracking library. These are all FileMaker custom functions. Lance will also include the starter file upon which he will do the demo. Finally, he’ll have references to documentation on such things as JavaScript standards and his Testing Generator library.

Q: What are modular scripts?

A: There are a few sessions at DevCon this year. Todd will speak of Modular FileMaker, and John Renfrew will speak about Modular Programming. These modular scripts should be a must-attend session. Modular scripts are, in essence, scripts that perform one function well. For example, you can build a script that returns the end date of an event if the script is given the start date and the event length as a parameter. Inside this script is the logic that will return the correct end date.

Q: How much JSON do you, Lance, use in your daily work?

A: Every project Lance work on uses JSON primarily to pass data around. JSON makes modular code easier. Each script has to receive data and return data. The chunks of code (in the form of JSON) make it very easy to work. Lance will always use JSON.

Q: What is something we could know about you that has nothing to do with FileMaker:

A: Lance will be a dad in December.


Lance’s session, “Testable FileMaker Custom Apps” is Wednesday, August 8, from 1:00 to 2:00. Check it out. It will be a good one.

 

 

To celebrate DevCon 2018, the newest release of the FileMaker platform, and all things JavaScript, Geist Interactive is pleased to begin a contest called GoCreate, where you get to go wild and show off your most unique use of GoDraw3.
Use all of the power of GoDraw3 to create a unique user experience to solve a particular use case. Read all about GoDraw3, but here are some things you might want to consider:
  • Any of the tools and functionality can be removed or customized.
  • The app is simply FileMaker. Use all of your knowledge and skills of FileMaker.
  • Tagged objects can be used in some awesome way.

Who can get involved:

This contest is open to anyone attending DevCon 2018 of any skill level. Since GoDraw3 is simply FileMaker, anyone can participate; no knowledge of JavaScript is needed.

Here are the details:

  • Use the fully-functional trial version and use that for your implementation.
    • Note: the trial version includes a watermark image. Ignore it.
  • Contest Date range: Now through August 9 at 8:00 a.m.
    • Feel free to work on it now!!! Get Started.
    • Or wait until DevCon.
  • Where: DevCon 2018. You must be a DevCon attendee to win.
  • Winner announcement at 3:30 p.m. on August 9.

Here’s what to do:

  • Download the trial version of GoDraw3 and create a unique implementation of it. Be creative. Create something that would work for any of your current work, or go wild and dream beyond your day job.
  • Email a link to your project to support@geistinteractive.com.

Rules:

  • You must use GoDraw3 in your implementation.
  • You can use any part of the FileMaker platform including FileMaker 16 or 17 to create your design.
  • You can design it for FileMaker Go or FileMaker Pro Advanced. You’ll let us know which device it is meant to be on.
  • Your work must not contain any real customer data.
  • You are limited to one entry per person.
  • Your work will only be considered if you’ve emailed a link to your project to support@geistinteractive.com.

Judging

A team of independent FileMaker developers at DevCon will judge each entry, scoring your submission as they reflect on:

  • How clever of an implementation is presented.
  • How does the submission ‘feel’?

Granted, these are rather subjective, but we’ll do our best to make it fair.

Support

You can get support and questions answered in the following ways:

We will be available to answer specific questions about GoDraw3, not about how you can implement it. We want to see what you can do! 🙂

 

GoCreate! Using FileMaker GoDraw for something awesome

We’re excited to see what you create with GoDraw3.

Terms and Conditions
  • You only officially enter the competition when you have emailed a link to your project to support@geistinteractive.com.
  • All submissions become property of Geist Interactive and will be used in promotional materials. We will credit the author.
  • Submissions have to follow the rules as set out above.
  • All entries must be submitted by August 9 at 8:00 a.m.
  • Geist Interactive have the right to remove any entry at their sole discretion.
  • Objectionable or offensive content will be disqualified.
  • The competition will be judged by an independent panel of FileMaker Developers from the community. The top three will be selected based on creativity, unique implementation of GoDraw3.
  • The winners will be announced at DevCon at 3:30 p.m. at the Geist Interactive booth and by email.
  • The winners have 7 days to respond and claim the prize; if no response has been received after 7 days, you forfeit your prize.
  • Geist Interactive reserves the right to exchange any prize for a prize of similar value.
  • The judges will be selected from folks outside Geist Interactive. 

You know me. I enjoy working with JavaScript. I learned it from my context of a FileMaker developer, and I think everyone can and should consider using it in some aspect of their work. We all can adopt a FileMaker integration. This year I’m lucky to teach a training session at DevCon, where I’ll guide people through the basics and how to apply it to their work. While not every answer I give on the forums is about some JavaScript integration, I do promote it where applicable.

The time barrier

But I do realize that there are barriers to the language for us FileMaker people. I asked a question about this a couple of weeks ago. Most people responded with ‘time’. They simply don’t have time to learn the language. I think that is more of a perception than reality, but I acknowledge that idea. My training session will work to break down that barrier, by the way.

Because of this perceived barrier, I want to give folks a way to use JavaScript integrations without actually knowing JavaScript. How you ask? Well, this goal is accomplished by a cleverly-created FileMaker file: The DataTables config file. Let’s take at this barrier-smashing setup.

Introducing DataTables Config

The goal of this file was to give anyone the ability to implement the DataTables integration into their custom app. And the DataTables JavaScript library provides a heck of a lot of functionality for list views or lists of related records with no additional coding. You can set up a web viewer that shows related records with column sorting, go-to-related-records, column or row colors, filtering, etc.

DataTablesConfig.fmp12 is a  FileMaker file that simply generates the JavaScript needed for the integration after the developer adds or removes functionality. Here’s what it looks like.

I’ll say it again. This config file lets you set up the DataTables integration without messing with the JavaScript. After only ten minutes of setting it up, the above configuration produces this:

Gettin’ you hooked

This config file is meant to be a gateway drug into using JavaScript. Once you try it out and see how much functionality it adds to your custom app and how easy it is to set up, you’ll be interested in diving into the JS code. I guarantee that. You’ll want to look at the JS code (it really is just text) that makes this all happen. You’ll find it is easy to read (JavaScript is easy to read) and you’ll be inspired to mess around with it, to change something to see what happens. And in this case, no one gets killed by the curiosity. Mess it up, you can use the config file to revert back.

You’ll be hooked on JavaScript, and then you can continue to learn more about the language. We at Geist Interactive will guide you along.

Features of the DataTables config file

There’s too much to explain in detail here in a blog post, so be sure and check out the video that walks you through the app. But here are some highlights of its features.

  1. DataTables comes with a lot of default features and options. If you don’t want to customize your implementation, you can generate the default code quickly.
  2. You can add or remove features and options using the FileMaker data fields and UX provided here.
  3. There are detailed examples of how to format the text you wish to put in. For example, if you choose to have your default table sorted by column 3, you can choose the ‘order’ option and then pass to that option the following text: [2, “asc”] (this is a 0-based index). That’s easy enough to type, don’t you think?
  4. You can add additional extensions to your implementation, functionality that makes the integration more complex. Such as something that looks like a sub-summary report (grouped records) in little time.
  5. There’s plenty of help and descriptions of the features.
  6. You can (and should) map your fields to this config, and you can describe how each column should behave.
  7. You can add a callback function (Run a FileMaker script when you click on a row) and even assign a column to use in the search.
  8. You can set this file up to be a module, a separate file next to your custom apps and link to it. This action allows you to use the code stored here to display the data.
  9. Give some basic custom styling to the table.

There’s so much more that can be done, and we’ll explore Extensions, custom CSS, and calling FileMaker scripts in later posts and videos.

FileMaker Integration: Give it a try

I strongly encourage you to give it a try. Play with it, mess it up, do all sorts of stuff to it and figure it out. I promise it will not take hours and hours (maybe one or two). It won’t be a huge drain on your life.

Download the free tool. Watch the video. There are some fine points in this, and it is best shown in the demonstration.

Feel free to reach out at jeremy@geistinteractive.com with questions if you wish. I can answer some questions, or we can set up an implementation package to do some custom development with this configuration in your custom app.

Let me know how it goes.

 

 

 

 

The FileMaker platform keeps getting better. The yearly release schedule gives us plenty to look forward to in new features, and the timeline gives us plenty of time to get to know what has been included. One of the new features is called “Default Fields”. We can now set up default fields to be created with each table in each file. There are plenty of articles out there already, and the knowledge-base article is out now. But I’ve seen some questions in the forums, sometimes the same ones. I did some research and put together the answers here. Let’s dive into FileMaker Default Fields.

Where are the Default Fields?

FileMaker 17 includes the default defaultFields.xml file in this location:

  • Mac: Applications/FileMaker Pro 17 Advanced/FileMaker ProAdvanced.app/Contents/Resources/en.lproj/DefaultFields.xml
  • Win: <drive>:\Program Files\FileMaker\FileMaker Pro 17 Advanced\Extensions\English

This is just the place to get the defaultFields.xml file. You shouldn’t move it. Just copy it and paste it to the proper location:

  • Mac: /Users/Shared/FileMaker/Shared/
  • Win: <drive>:\ProgramData\FileMaker\Shared\

Once there, you can open this file in a text editor (I use Visual Studio Code) and edit away.

How do we change the FileMaker default fields?

The defaultFields.xml file provided (and found in the location and placed in the location described above) allows us to make changes to the default fields. Here are some thoughts about it:

  • Start by making only a few changes to a field or two. Edit, save and see what happens when you create a new table. Get a feel for how the XML is written.
  • There’s a tag in the xml, near the bottom in the <tagList> tag, that identifies one of the fields as the primary key. Make sure that stays there if you plan on using addons in FileMaker 17 or any later version.

  • There’s a tag in the xml that identifies each of these fields as utility fields. It is found in the <TagList> tag: “#_FMI_0”. The 0 identifies it as utility. Remove it if you wish, but understand the (small) consequence of doing so (see below).
  • As you go to adjust a field’s xml, you can get immediate feedback by creating a new table in a .fmp12 file. If there’s any issue with the xml of a field, such as a missing ” or misspelled tag, that field will not be created. So give it a test.
  • If you’d rather not use FileMaker default fields, simply add a blank defaultfields.xml file to that shared location. This action prevents FileMaker default fields from being created.

How will default fields effect my development?

Using the FileMaker default fields can enhance our development in a small, but crucial way: You’ll create a table and immediately begin adding data fields to your system since these utility fields were automatically generated. Additionally, the following points illustrate more benefits:

  • We can add other utility fields by adjusting the defaultFields.xml file.
  • We can set this defaultFields.xml file up once and be done.
  • Every table will have common utility fields which record the basic necessities: primary keys, creation & modification user & timestamp.
  • We’ll never have to copy/paste the utility fields from one table to another. One less thing to worry about. I’m sure folks have forgotten to add these at one time or another.
  • Since these are utility fields, they do not get added to the layout automatically (as do fields that are created by you during the creation of the table) .
  • Utility field-creation is consistent across an entire team.
  • A field is identified as the primary key field which is useful for add-ons.

How do I add a certain type of field?

Many folks have asked in the forums how to create a certain kind of field. An amazing tool, by Salvatore Colangelo at Goya, allows you to create the fields you want for each table by constructing the defaultFields.xml file. The FileMaker file actually writes the xml of the fields after we make choices (name, type, primary key, calculation, etc).

Of course you can simply duplicate the xml for a field in the document and adjust it as necessary. By hand. That’s useful too.

But consider a very key point:

Every field in the defaultFields.xml file will be created in every table of every file you work with in FileMaker 17. So if we add a “FirstName” field to our defaultFields.xml file, that field will get created even in the Invoices or Dashboard or Inventory table we create.

Only a few

It seems to me there’s only a few fields that could always be a part of the XML file. We here at Geist Interactive want some fields in every table. Some other developers have more, some less. Here’s ours.

  • primaryKey // the primary key of the table. UUIDNumber
  • ModificationUser //autoEnter field
  • ModificationTimeStamp // autoEnter field
  • CreationUser //autoEnter field
  • CreationTimeStamp //autoEnter field
  • z_One_c  // a calculation field that returns a 1. Useful for relationships.
  • ModCount // a calculation field that counts the number of times each record has been modified

Remember, these are utility fields, so they server a utility and are not data fields as it pertains to the custom app.

New Feature, New Thinking

The FileMaker Default Fields feature is new to FileMaker 17 and it provides some possible glimpse into the future. We, as developers, can create FileMaker fields using XML, either by hand or using a tool. That’s an interesting thought.

You’re already using them if you’re developing in FileMaker Pro 17 Advanced, so embrace them and make them your own and be happy. They are here to stay.

 

 

 

FileMaker DevCon 2018, held in Dallas, TX, is fast approaching, and as always, I’m excited for the conference. It certainly is a highlight of my year, where I get to go and see old friends, make new connections and friendships, and revel in all things FileMaker. The conference is held in a fancy hotel, but they could host it in a Hotel 6 for all I care. Sure a huge pool is wonderful to sit at, but the more time you’re at a resort feature, the more you’re missing FileMaker stuff.

An amazing pool and view doesn’t make DevCon great, does it? (DevCon 2016, Las Vegas)

For those that are attending FileMaker DevCon 2018 for the first time, it will be a FileMaker-life-changing experience. You’ll meet folks, learn a lot, and simply be inspired by the excitement about the platform. Even if the community sometimes can be intimidating for few folks and a bit of a drag with complaints or laments of ‘missing features’, the experience of being surrounded by FileMaker stuff in person is exciting.

This guide is meant to help you if you’re new to DevCon. My first one was only seven years ago. Each year I remember what made it so great and try to continue those practices and attitudes. Let’s review how to make this first time an inspiring and fruitful one.

Don’t Mess With the Conference

Every year, FileMaker, Inc. puts on a fantastic conference, filled with people, cool FileMaker tips & techniques, products, free advice, great food, and a great location. Last year around 1600 people attended, so the conference is huge. I know people look forward to it.

DevCon 2016, Las Vegas

Tim Cimbura of LuminFire has a great write up about some of the facts about the conference.

Take advantage of every part of the conference. Get your money’s worth. Here’s some of how you can do this very thing.

Organization tips

  • Get there early to meet folks before the conference starts. I usually hang out in the registration area where I know FileMaker folks will be.
  • Check in soon after you get there. Each year we get some cool FileMaker swag. I’ve got four FileMaker bags and one FileMaker towel from my conference experience. We’ll also get a license key for the current FileMaker Pro Advanced version and some other items, including a vital accessory from Geist Interactive, a diamond sponsor of FileMaker DevCon 2018.
  • Make a plan of the sessions you wish to attend. More info on this below.
  • Scope out the session rooms. Practice the route to the rooms so you don’t get lost or have to consult your phone every time you want to go to a session.
  • Attend the Keynote. FileMaker DevCon kicks off at the keynote officially, and here we get to see FileMaker, Inc. and the folks there on stage talking about the platform they’ve chosen to spend their career improving for us. FileMaker, Inc. product managers and engineers emerge from their cubicles to show us what they’re currently working on back at the wedge.

Socialization Tips

  • Find a friend or two. If you’re coming by yourself, it’s quite intimidating to be in a sea of 1600 devs and not know anyone. So say hi. Make a friend early. My first time at FileMaker DevCon, I actually met someone through the community. We shared a room to save costs and I followed him around. He introduced me to folks and gave me advice. It was the start of a great friendship.
  • Visit the vendors. The main exhibit hall will be filled with booths of different FileMaker shops out there. We’ll have a booth, and we have cool things planned for that space. Also in that space is the Visionary bar and the FileMaker Tech Support Central. The visionary bar is filled with folks in the community holding office hours. You can come to them with any specific FileMaker problem (there is no couch) and get some advice from the experts. The Tech Support Center contains FileMaker, Inc. Engineers and designers that can talk to you about specific issues you might have with your app or with FileMaker.
  • Come join others at the New Attendee Meetup This is a session devoted to any first-timers. FileMaker, Inc. staff will be there to talk about the week and get you started. The Women of FileMaker is hosting a DevCon buddy program. Take advantage of this time to get to know other new folks and buddies that have been there many years.

Don’t miss any part of the conference.

Don’t Mess with the Sessions

There’s too many sessions for you to attend all of them, so be deliberate about which ones you want to attend. Take some time now to study the schedule and jot down topics you want to be a part of in person. Though each session is recorded and eventually posted to FileMaker’s YouTube channel, decide which sessions you’d like to be in the room during the time. TheDevCon2Go Scheduler custom app will be released soon, and you can use that on your devices to mark your favorite sessions and to review the schedule in advance.

Attentive listening in a session.

If you’re a FileMaker beginner, attend some beginner sessions, but also attend some more-advanced ones. You might not fully understand everything presented, but the stretch in content will further inspire you. Also attend sessions on stuff you’ve never used or heard of: cURL, JSON, integrations, IoT, all the things that you might not see yourself using. These innovation sessions are the future of the platform, so be sure and get in on the ground floor.

If you are able, attend a training-day session. They are held on the Monday of the conference and are an additional cost, but these sessions (3.5 hours in length) are more hands-on and more exploratory than the hour-long sessions of the regular conference. There are always beginner, intermediate, advanced sessions. The topics range from basic FileMaker to reporting and user experience design. I’m teaching a session on JavaScript for FileMaker developers.

Don’t Mess with your Health

The conference is a week, but a lot happens in that week. Protect yourself and keep yourself healthy. Here’s some ways you can do that:

  • Bring sunscreen. It’s Texas.
  • Bring a water bottle. It’s Texas.
  • Bring warm clothes. It’s Texas, and we’re indoors. The AC will be blasting and cold. Of course when you step outside into the sunshine, you’ll bake in all the layers, but at least you’ll not freeze in the sessions.
  • Exercise. You’re doing a lot of sitting in the sessions, and we know that sitting is the new cancer. Get outside and walk (at like 5 am) or late at night (2 am). Hit the hotel gym or pool. Listen to your Apple Watch (we all have one, right?).
  • Rest / Get away. Above I’ve encouraged you to attend all you can, but you have to rest. So if you’re exhausted on Wednesday, take a moment to yourself. The hotel is huge, so find a quiet spot to just zone out (preferably not in a session) and recharge.

Don’t Mess with the Opportunities

FileMaker DevCon is the best place for a FileMaker developer to go. For the first timer, it is inspiring and overwhelming and excellent. There’s so much to take in, so many folks to meet. I encourage you to take advantage of every opportunity given at DevCon and be a part of this great community. Meet folks that you’ve talked with in the community forums. Learn a lot. Meet at least four new people. Visit vendors and booths. Learn what’s exciting about the platform.

Say hi to us at Geist Interactive.

We’ll be there at our booth demoing Editor and GoDraw and Quickbooks and other products, or walking around with our company t-shirts. Be sure and strike up a conversation about JSON or Native FileMaker or the FileMaker platform. We have a few things to say about those I’m sure.

Meet FileMaker, Inc. folks. They are some of the most friendly and passionate people about their platform I know. Four years ago now, I met the PM of the FileMaker Pro Advanced product. We’ve become good friends. We chat about FileMaker, about video games, about yard work.

Don’t Mess with FileMaker DevCon

Do everything you can to get the most you can out of FileMaker DevCon. You’ll be grateful that you got your (or your company’s) money worth. You’ll be inspired and energized and ready to push yourself to become better in the platform.

FileMaker 17 introduces a new script step: Perform Script by Name.  FileMaker Devs have been asking for this feature for a long time. It sounds like a useful idea, but we should probably try to understand how it works before we just adopt it willy-nilly, for all our script calling needs.  Let’s explore this idea together.

Perform Script by Name: The basics

Perform Script By Name is a script step that functions as it is named. We now have two options when using the Perform Script step: By Name  & From list.

If “From list” is chosen, then we go about choosing a script in the normal way. However, if “By name” is selected, we get to set the name of the script using the calculation dialog.

At the script’s runtime, this step checks to see if the script is in the list of scripts and runs that one. If it isn’t in the list, then we get the good ol’ message:

We can suppress the message with the Set Error Capture [on] step and capture the error (104 Script is missing) with the Get (LastError) function.

In a multi-file solution, we can use this same step to call a script in another file using the same table/field format: ExternalFileRefName::ScriptName.

Notice this step is using the external file reference name, not the actual file name. We need to use the name we gave to the file reference.

Pretty simple. There doesn’t seem to be much else to this. Set the name of the script or external file reference name and script in some manner, and this step will run that script.

Oh, by the way, this works for Perform Script on Server as well. As we set up a script to run there, we are presented with the same dialog.

Wait, what? Why is this useful?

Here in FileMaker Pro 17 Advanced, we have the option to set a script name and run that script, a step that belongs in the ‘by name’ group of steps: Set Field By Name, Go to Layout by Name, and this one. When I first saw it, it struck me as odd: why would I ever use this step that adds another source of indirection to my file and is fragile. Let’s consider its possible uses and the idea that this step is fragile to see if we can find some workarounds.

It is useful after all

The option to perform script by name is actually useful. It seems to get rid of complex If / Else if / End if logic steps that determine the script to run. Maybe in a custom app, there’s a script called “Edit” and this script is run from a student record and a teacher record. The first part of this Edit script would have to use the If logic to determine which edit script to run, something like

Quite a few script steps.

With this new option, we can reduce the steps:

This does seem useful. It would certainly reduce the number of steps needed to determine the script. In a recent project, I saw one navigation script that ran for the entire system. IT was literally 150 lines long with a bunch of Else If logic steps. It was tough to debug. So there’s that. This option is useful.

Notice in the example above, I’m setting the name of the script into a variable and then passing that variable into the Perform Script step. That seems useful and handy.

Since the name of the script is a calculation dialog, I have a plethora of ways to get the script. I can construct it like shown above. I could get it from some preference table, or I could pass in the script name via a parameter, to name a few.

This new option in Perform Script allows us to write some pretty complex logic in a simpler way. If reducing the number of lines of code is your goal, Perform Script By Name is a must-use.

“Fra-gee-lay. It must be Italian”

Any developer’s first thought about this script step is that it can be easily broken. If my script name today is “ThatScript” and for some reason (legit or not) I decide to change it to “That Script”, then my perform script by name step is broken. That is certainly true.

Another factor to consider is that Perform Script By Name is another source of indirection, one that our Realtime Developer Intelligence tool FMPerception can find and point out, but this is an indirect source. Every time I use Perform Script by Name [“ThatScript”] I reduce the number of times FMPerception or database analysis tools can identify in the DDR where and when that script is used. That’s not bad. It is just something to consider.

But just because something is fragile or introduces indirection, there’s no reason to avoid this script step option. There are possible workarounds to the fragility issue. Let’s take a look at some of those.

Workarounds

Don’t change names

The first ‘workaround’ I can think of is: don’t change your script names. It seems obvious, but also almost unthinkable. FIleMaker is a rapid-application development tool. We can create a custom app quickly and easily, and that includes changing things on the fly. If our fieldName or script or layout’s original name is now unsatisfactory to us, it is easy to change. FileMaker after all actually looks at the ID of fields, layouts, scripts when calling or going to or setting. We’ve had it easy: change names as much as we want. I’d argue that this is a sign of not-fully-thought out planning, but I make no judgements. It happens. But I’d encourage us to change names of things as little as possible.

Documentation

Second, if we do start using a script in the ‘by name’ option of Perform Script, we need to very clearly document that. In the above pictures, my script “ThatScript” is being used in the ‘by name’ option. So I should go over to “ThatScript” and document at the top “###### USED IN PERFORM SCRIPT BY NAME. DO NOT CHANGE THE NAME ######” or something along those lines to inform everyone, including your future self, to tread carefully with this script. Or put these called scripts in a “BY NAME” folder. Something to alert folks to its special case.

Generate script names

Third, we can generate the name of the scripts that will be used in the following parent script. 

At the top of my Edit_Record script, I have a code block that gathers the names of the scripts that could be used in this parent script. I first set a global variable to 1. Then I go into each of the scripts that could be used.

Inside each script, at the top, I immediately exit with the script name.

and then collect that name into a JSON object, in my case, in $scripts.

This works. It adds complexity to your parent script, but it does ensure that I get the correct script name each time.

Other possibilities

There’s more ways to ensure that you have the correct script names every time. There’s a good function I just discovered: ScriptNames(). It returns a list of the scripts in a file. That could be useful somehow. Maybe you could gather all the scripts into a global and then check against this list every time using Filter().

Don’t be afraid

This new option is useful and valuable in the right circumstances. I’d say we shouldn’t be afraid of it or avoid it. Use it where appropriate. But don’t go overboard. Don’t use it like we all started using ExecuteSQL() when it came out (that is, everywhere).

Be deliberate in its use. Document the heck out of scripts that are used in this “by name” manner, and be careful about refactoring script names for no good reason.

I look forward to using this to simplify complex logic. Give it a try, and let us know how you use the new Perform Script by Name step.

 

 

Introducing Editor.

Editor is THE rich-text editing tool for FileMaker, for FileMaker Go, and FileMaker on the desktop (it does not work in FileMaker WebDirect). It is familiar for users and flexible for developers. Editor provides a full-suite of text-formatting tools for writing projects such as notes and blog posts. The formatting is saved, and can be retrieved for further editing. Editor is the best way to provide formatted text for FileMaker.

Familiar for the User

Editor provides many of the formatting options we use every day in online editing tools.

Any user can

  • Change the style of text: h1, h2, h3, normal, and code (among others).
  • Apply bold, italics, strike-thru, underline formatting.
  • Align text in standard ways
  • Add ordered or unordered lists
  • Indent or outdent text
  • Insert text or images
  • Change the font or background color.

Additionally, FileMaker scripts can be used to add pre-defined text and images.

Flexibility for the Developer

Editor is all Native FileMaker

Even though the editor and the text is a JavaScript application running in a web viewer, the developer has complete control of the implementation and customization of the app. Here are some reasons why.

  • The web viewer app is self-contained in a separate file, making it easy to integrate into an existing custom app.
  • The design of the layout and toolbar buttons (outside the web viewer) is all done in FileMaker. You can completely change how it looks just using FileMaker layout mode.
  • The buttons run FileMaker scripts.
  • The editor toolbar and theme can be controlled via scripts. If you want to remove the “h1” formatting option, remove that from the scripting.

See the possible customization options available.

The Best FileMaker Rich-Text Experience

Editor is the best way to format text in FileMaker We’re excited about the potential. We have lots of thoughts about how it can be used, and we will be sharing ideas.

Learn all about Editor

Download it for free to try it out. The demo comes fully functional, though it does have a 1000 character limit. So give it a spin and see how easy it is to format (and save) text in FileMaker.

 

We at Geist Interactive are excited about the newest (yearly) release of the FileMaker platform. It is a great step forward and provides a lot of game-changing features yet again. We get to throw out “hacky” ways of doing such things as master-detail and instead use the new features of native FileMaker.

Wednesday, June 20, we will examine the platform’s latest release. We will examine the features, and review the use and usefulness of each feature. It will be a discussion, so come prepared to talk about your favorite part of the newest release of FileMaker 17.

 

Where: WeWork Aventine (not WeWork B street) || 

When: June 20, 2018 || 3-6pm

Why: There will be refreshments, and we get to talk FileMaker 17.

 

Join us. Let us know through Meetup.com and we’ll make a space for yah!

 

FileMaker Pro Advanced gives us developers to create our custom function, our own calculation that returns a result. These are FileMaker Custom Functions. Using custom functions is a boss-level technique, and we all now get to use them and share them. With great power comes great thinking: you as a developer get to decide when/how to use them. But first, let’s take a look at how to work with custom functions.

FileMaker custom functions

Custom functions are lines of code that we write that returns a simple or complex result. They are found in the “File / Manage Custom Functions” menu.

FIleMaker Custom Function dialog

Here is where you create a custom function

Custom Functions have a few characteristics to them:

  • They require a name.
  • They can accept parameters, but don’t have to.
  • Some sort of calculation is required.
  • They are file specific
  • At this time, the custom function dialog is not type-ahead enabled, as is a regular calc dialog.
  • They can return one result or a recursive result.

Let’s look at each of these.

Require a name

Once a name is given, the custom function is available in both the functions list (under custom functions) or as part of the typeahead. Some folks clearly identify a custom function in its name with some prefix. I tend to use “_” at the beginning: “_CF_BeginningOfWeek”, (a function that returns the date of the first day of a week) but the structure can be anything, even containing spaces between words.

Accept parameters

Parameters are bits of information we pass into the custom function and is used in the calculation. These parameters are in the ( ) that appears after the name.. For example in the “_CF_BeginningOfWeek ( anyDate)” custom function, I am passing in a date. I’ve named it “anyDate” but that’s what it could be. I could work with any of these:

_CF_BeginningOfWeek ( Get ( CurrentDate ) )
_CF_BeginningOfWeek ( Date ( 3 ; 19 ;2018 ) )
_CF_BeginningOfWeek ( “5/8/2018” )

What’s in the parentheses gets passed into the custom function and is used throughout. For example, in this custom function, Date ( 3; 19; 2018) is passed into the calculation, and this value is assigned to the variable “anyDate”, the one I put in the CF set up.

 
Let ([
 _dow = DayOfWeek ( anyDate ); //anyDate = 3/19/2018
 _first = _dow - (_dow - 1);
 _end = ""
];
GetAsDate (_date - _first)
)

A CF can contain any number of parameters, including zero. Many folks create custom functions that turn the numerical returned value from a FileMaker function into something readable. The FileMaker function Get ( Device ) returns 1 if the user is on the mac. Would you remember 1 being the Mac (especially is your device of choice is a machine with the Windows OS)?

So folks will take this function into a custom function and call the custom function instead.

One other note about parameters, you can use any number of parameters, and each one must contain something passed to it. Look at this custom function called _IsOverlap. Its purpose is to determine if two date ranges overlap.


As I built this for a project, I realized that sometimes there is no end date for one of the ranges. I still need this to work, so I have to pass something into the custom function for the end dates. So inside the custom function, I’m checking to see if the EndDate parameters are empty. If so, I put a placeholder date in there.

The calculation

The whole point of a custom function is to do some calculation, so do something in this section. You can use any combination of existing FileMaker custom functions, from-scratch calculations or even other custom functions (provided those exist already).

The calculation can be simple or complex. It all depends on your needs, as we’ll discuss in a bit.

Other characteristics

Custom functions are file specific. Each file has zero custom functions at first creation. But it is a simple matter of copying a set of custom functions from one to another file. Simply select the ones to copy in Manage Custom Functions in File A and paste them in the same dialog in File B.
The custom function calculation dialog does not have the type-ahead feature we’ve not gotten used to in other areas. Some folks complain. I don’t. I deal with it and move on. You can select FileMaker functions from the dialog, but it is simpler to type them out.

And finally, custom functions can be used to be recursive, to call itself until a condition is met, and then return the result. We will address these in a later post.

Well-used custom functions

FileMaker custom functions have their uses, and you can make the decision for yourselves. Here are a few good thoughts on it by others. Beyond that, it’s a simple decision to make when considering a CF based on these ideas.

One calc used many times

There is a calculation that does exist in FileMaker that will need to be used throughout the whole custom app. If many places in your app require the date of the first day of any week, then that seems a likely candidate for a CF. This has an added benefit that if the calculation needs to be changed for some reason, (returning the Sunday date instead of Monday date), there’s one place to update all the results. That’s useful.

Human-readable result

You want a result that makes sense to humans: _CF_GetDevice() will return “Mac” instead of 1. Making it readable means you don’t have to even think. Here’s another example of a set of custom functions using the Get(Device) FileMaker function

Each of these returns 1 or 0, true or false for a given device.

These can be used in a series of logic script steps. For example:

One more thing

In the history of the custom functions, many people have discussed the pros and cons about them. Some of those cons have gone away now that we all have access to the feature, but it is worth noting there still are a few. We’ll look at those in a later post.

Resources for Custom Functions:

There are tons of FileMaker custom functions out there for different purposes. Developers come up with CF’s that fit a specific need and then make it available. Here are just a few resources.

FileMaker Custom functions are a part of the full toolbox we all now have at our fingertips. Knowing how they work and when/why you would use them is important. Explore them and see how they fit into your development work.