ISO FileMaker Magazine

If there's one thing you shouldn't ignore from the start of any FileMaker solution, it's the way security is going to factor into your creation. You need to know who the users and groups are and what their access rights are. These access rights are called privilege sets within FileMaker.

All too often, security may be an afterthought because most of the fun typically lies in creating solutions to the problems. The real trick is to create the solution to the problem while simultaneously considering how security wraps around that problem.

Unfortunately, with FileMaker being such a flexible platform, testing those access rights is not obviously easy. We have one simple way of testing one privilege set versus another: logging out of the system and then logging back in as another user. This process, while critical, can seem like a hassle, so it's often deferred. With the information in the associated video and technique file, you'll enjoy learning about a very easy-to-use system that allows for testing things quite easily. The solution simply takes advantage of part of how FileMaker works after the authentication process. Need to up your security game within FileMaker? You're sure to find some answers within this solution.

Over one's development career, you'll come across a number of people who "think" they know how something really works. You then proceed to show them some of the cool things they can really do, like a "context jump" within FileMaker. You then smile at their surprise, because what they thought was possible isn't even the start of it.

If you don't even know about, or truly understand, FileMaker's ability to jump from one context to another, then you're missing a critical piece to the FileMaker puzzle. It's one of the ways you break down a complex solution into a more digestible division of smaller parts. This not only makes the Relationship Graph potentially more understandable, but may make your solution more performant.

There are, however, a few big issues you must address as your FileMaker solution becomes more and more complex. One of these is protecting your code against itself. Certain script steps like Delete Record, Delete All Records and Replace Field Contents can have severe consequences. Especially, if performed without confirmation. And even then, accidental clicks is certainly a thing! In order feel really comfortable about using these types of actions you can always "protect" your code from doing the wrong thing in the wrong place. This where you implement either Layout or Context specific checking. This can easily be done when you know how to use FileMaker's internal ID values.

Spreadsheets really suck!... Long live spreadsheets, they're super useful! This simple contradiction, however, is likely a part of our technological lives for the rest of time. Unless AI removes the need for people to directly interact with data, spreadsheets are likely here to stay. And, for good reason. They're actually super useful!

As a software/database developer you need to realize that not everyone intuitively understands the solution you've created. In fact, the learning curve, may just be too painful - at least relative to what they may already know. Most users will tend to default to what they feel comfortable with. In the not so distant past, managing data was actually just words on paper. In fact, there's a word you're probably familiar with, it's 'list' - a very common development term. Yep, we still use lists.

Did you notice that? I referenced the fact that you're developing software and you can't really create software WITHOUT using lists. So, why not simply accommodate users' needs to simply default to using a spreadsheet. You just need a simple way to get the data in and out of your solution. Fortunately, this has all been solved by the tab and comma characters. If your users are using a lot of spreadsheets, then enjoy this video article and the associated technique file as we work with the MBS plug-in's super powerful Matrix.* suite of functions for some super functionality. Let's just Copy/Paste that spreadsheet data into a virtual spreadsheet and manipulate the data to fit our needs.

Providing users with some type of indication about where they are within the current layout is always a nice thing. People don't typically like that feeling of being lost and there are multiple ways to indicate where the user is. A simple header or label is always one of the easiest ways, but, what if you're using disconnected objects. In that case, the navigation itself can often act as the indicator.

The combination of either multiple buttons or a Button Bar, with a tab panel or slider is a very common thing within a more complex FileMaker layout. In this video, I walk through the process of adding some navigational indicators to an existing solution which is provided for free by Soliant Consulting. There's a lot to learn with regards to object management, some object naming and related trickery and making that disconnected situation between buttons and panels a connected one which will facilitate navigation that clearly indicates where you are within the layout.