ISO FileMaker Magazine

In many situations, you'd think the easiest solution would be the best. Saving time and getting the job done quickly. This, however, just isn't the case if you're going to allow users to use a simple text field for managing keywords or tags. A tagging system relies on making it easy for the user, but it may not be so easy to implement itself. Here are a few questions you might be faced with.

What happens when one user enters "devloper" on record 1 and another user enters the correctly spelled "developer" on record 2? How do you make it easy to rapidly enter multiple keywords with a high degree of accuracy? What about removing keywords from this simple text field? Does the user just get to remove any portion of a whole word - causing a data nightmare? What about those commas being used to separate the keywords? Do you really trust users to get it right all the time? Can users be trusted to add multi-word keywords and get the commas correct?

The answer to all of those questions comes down to you. As the developer controlling the situation, you get to make sure the data is entered as desired and is still easy for the end user. And, in that case, the system is going to be a bit more complex than using a simple text field to allow users to enter whatever they want.

The video and technique file for this topic showcase a wonderful system of being able to enter and remove keywords used for data segmentation. If you've implemented a tagging system prior, then make sure and take a look at this one because you may find some UI niceness that's just too good to pass up!

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!

Even though your "database" includes the word "data", data isn't the only thing we categorize and track. We often need to track discrete files and FileMaker is perfectly adept at doing this. In fact, FileMaker's container field is ideally suited to store all kinds of different files.

The problem, however, is simply throwing a container field onto your layout is never really a good idea. If you allow users to simply drop anything into a container, then you'll surely end up with a collection of duplicate files and files which may not even need to be in the database.

The best method for properly managing uploaded files is to make sure you control what gets in and how it gets in. This isn't going to be handled with your simple addition of a container field to the same table tracking your contact information. This is best suited with a couple of gateway keepers. Filtering based on extensions and preventing duplicates are two methods you implement into a highly optimized uploading method.

In the associated video and technique file you'll have access to all the instruction and code needed to start you on the path to implementing the proper and ideal way for managing file uploads into a FileMaker database solution.

Ahhh, the panacea of being able to improve my FileMaker database offline, then simply applying all the dev changes to the live production file. This is the great promise of the new FMUpgradeTool. It was released along with FileMaker 19 and it's a bit hard to dig into. Unless, you have the time like I did.

Fortunately, I'm going to save you the many hours of slogging through the documentation and the trial-n-error which comes with learning any new tech.

In this video, I spend an ample amount of time covering the FMUpgradeTool and how it might impact us in the future. I'd gather that, like Add-ons, the "preview" nature of this tool means that Claris hasn't been able to complete out their vision - at least not when it comes to documentation. The good thing, however, is we get to see what's coming and the tool can currently be used for small micro changes and the like. It certainly will need to be put through its paces and we'll have a lot of opportunity to do that when the time comes.

For right now, the process of making a FileMaker patch is pretty manual and will need to be automated by either Claris or a third party. Claris has seen what's been done with their XML in the past, primarily by companies who choose to make analytical tools, so, it makes sense that they'd love to see something which automates the creation of a complete FileMaker patch.

If learning about FileMaker's guts is something you're into, or checking out what the future might be like, then give this video your undivided attention. You'll gain a lot of insight about what these new tools will be doing behind the scenes!