ISO FileMaker Magazine

FileMaker's script triggers can be problematic if you don't properly test and debug the user interaction flow. Some developers, perhaps even yourself, avoid script triggers for this reason.

However, script triggers can be incredibly useful. Unlike JavaScript in the Web Viewer or other environments (anyone remember HyperCard or Adobe Flash?), which have numerous possible events, FileMaker offers a limited set of events called Script Triggers.

One of the best aspects of Script Triggers is that they are linked to specific objects, areas, or actions. This differs from writing scripts that must handle various conditions and situations. With Script Triggers, you can make a particular area of FileMaker function autonomously, handling its own tasks. The first step to feeling comfortable with Script Triggers is learning how to manage them when you don't want them to execute.

In this video, I revisit a database created in 2010, which remains valuable for learning what Script Triggers can do. Let's walk through a concrete example of how you can rethink your use of Script Triggers.

Learning everything you can do with Claris/FileMaker scripts is such a wonderful journey. When you first start using the available script triggers, it often becomes a bit of an issue if you aren't fully aware of all the impacts. This video is an update to older videos which didn't have the insights presented in this video.

If you've been using Script Triggers within Claris/FileMaker for some time, then you might want to give this video a watch to see if you're missing any of the latest and greatest know-how dealing with Script Triggers.

Causing a user to make an explicit choice within your software really only happens from some sort of "locked-in" process. This process most typically happens within the form of a dialog box. It's the one roadblock you can stick in front of a user and expect input. Your software then uses that input to determine the output or direction.

While FileMaker Pro does have its own native dialog box, there are some limitations to the native Show Custom Dialog script step. The number one limitation is the lack of control with regards to size and positioning. Aside from that, the dialog box is pretty fixed in terms of how it looks and what it does.

Actually, the limitations on a dialog box are a good thing. It creates a sense of consistency across the whole notion of software itself. Users have seen dialog boxes and interacted with them. They know what they do and how to react to them. So, in order to gain a bit more control and flexibility, we use our own layouts to provide our own variation of a dialog box.

By using a FileMaker layout, we get to control how it looks and reacts to certain situations. This video and technique file revisits an early version which was released when Card Windows had just come out. If you enjoy using powerful and efficient methods of enforcing that "locked-in" process, then make sure to check this one out!

Occasionally, you hit certain issues within FileMaker development where you're just stumped as to why you can't do something. Let's take a super simple example like being able to show and hide a button based on having selected a given portal row. How do you know when the user is within the portal? How do you know when they've left?

Think it's easy? Try to solve this issue without watching this video first. You'll quickly find out, that because of how FileMaker's "event model" works, known as script triggers, that some times things happen when you want and other times they don't. And, ultimately, you don't have control. FileMaker picks the Pre vs. Post.

Unless, that is, you get creative with how you solve this particular problem. In the case of Pre vs. Post script triggers, it is possible to extend how FileMaker behaves. In this video, I showcase how to solve the simple problem of showing and hiding a given button when a portal row is selected. It's a bit of a trick, but it can certainly be done.

Additionally, if you don't yet know the value of knowing when a user has a given portal row selected then you'll learn that lesson as well by watching this video!

One of the challenges I love the most within FileMaker is creating something which requires less time and effort than the "older way" of doing the same thing.

Such is the case with a tabbed list view. I recently came upon a sample file showcasing how to do something in multiple list views. It was using an older method of "simulated" tabs by simply placing clickable buttons in a horizontal row and making one of the buttons look different on each respective layout.

So I thought to myself, "Why isn't he just using a normal tab panel?". You can certainly do it. You just need a few key pieces of info in order to create a very powerful navigational tool for a tabbed based list view. And, that's what this video is all about Tabbed List Views.

Learning how to efficiently create scripts within FileMaker is a never ending process. It's a balance of leveraging what you know and mixing in newly added features along with new ways of doing things. Optimization and cleanup will always be part of the ever growing software solution.

In this video, I present the topic of using utility scripts in order to save precious development time. You know, those reusable scripts which prevent you from writing unique and dedicated scripts for every possible scenario in which the user will interact with your solution.

They're the scripts which end up saving you a ton of time and get used over and over again. They can be used stand-alone or they can be called by other scripts. But, no matter how they are used, it's certain they are valuable pieces of reusable code.

If saving time and reducing the number of scripts you write is of any interest, then this video will have the information you need.

FileMaker's Script Triggers can be seen as either a big help or a big hindrance. It really depends on what your experience is with them and how you've created your solutions.

If you've never really worked with Script Triggers, then you're missing a big key to the automation puzzle. If you've used them, but found they get in the way more than help, then you need this video. If you've found that sweet spot of using them and not being discouraged by their idiosyncrasies, then take advantage of the help file shown in this video.

The video and associated file cover how Script Triggers integrate into FileMaker and how to take advantage of them. Prior to FileMaker version 10, the only option for user executed scripts was through your standard button definition. With the addition of Script Triggers, interaction was extended to the general environment within FileMaker.

Moving to a layout, loading a record, hitting a key on the keyboard and many other possibilities entered the picture. Make sure you know how Script Triggers work and you'll be well on your way to making the most of any FileMaker solution you create.

One of the fun aspects of working with FileMaker, or any other programming environment, is coming up with creative solutions to using the provided tools.

In this case, it's FileMaker 13's new sliders which provide some really cool functionality. When paired with Get ( TriggerTargetPanel ) you can simply use the Slider control for the purpose of capturing a swipe on a mobile device.

When you combine this knowledge with desired features, such as showing a (theoretically) endless number of pictures, you arrive at a solution which can be used in more places than just the one you've figured out.

If your solution is going to end up with mobile features and you want to use the Slider control for capturing swipes this video will have the information you need.

If you simply want a compact way to present multiple pictures we've got that covered too!