ISO FileMaker Magazine

Almost every, and I mean EVERY, developer has their own take on FileMaker development. I guess it's one of those aspects of FileMaker which is so appealing. Every developer can feel like they're controlling their own destiny and exercising their own creative power - even when they come up with their own standards.

Yet, in many, and I mean MANY (read, almost ALL) other programming languages (if you permit me to compare FileMaker to a programming language), there are conventions (or standards - of which I'm semantically using both words interchangeably). Not to say that FileMaker doesn't have these. In fact, over my many years of working with FileMaker, I've heard of hundreds of attempts to establish a standard for coding in FileMaker. Even FileMaker, Inc. released a white paper in 2005 after FileMaker 7 had been out for a while, where they documented a variety of suggestions. Even still, these suggestions came from many developers, of which each had their own styles of creating a solution - so the white paper read like suggestions instead of conventions or standards.

After attending Pause on Error in Portland, and hearing the number of people "claiming" they wanted such standards, I decided to start to do this for myself - knowing that decision by community is a slower process. While working on my upcoming product release called the Theme Studio, I spent a good deal of time focusing on making the code within the solution as readable as possible. The goal was the ability for any developer to be able to open the solution (even though it's a closed solution) and understand. Hence, I'm calling this the "open and understand" initiative.

This meant many iterations where I would head back into scripts and calcs which I had completed months prior. If I couldn't immediately understand my own code then I rewrote it. If something was extraneous, I cut it. Finally, after doing this for about a year, I sat down and created documentation about my own conventions. I then decided to release it to the public.

While not fully complete, what I've started is documentation for others to follow - and contribute to. I have no illusions that what I've documented will become the single standard - that's the dream world where we have "one" OS, "one" web browser and many other "one's" which makes it easy to do seemingly simple things, like create one css style sheet instead of 2 or 3, or be able to pick up a FileMaker solution and easily figure out what the heck is going on.

If collaborating on, and leveraging a set of standards, which frees you from the confusion of a database without order, sounds interesting, then this video should give you and idea of what I've started. My approach is one of openness. While some of what I've documented will stay the same, some of it will change based on input from the wealth of knowledge and experience which extends beyond my own. One final thing I found interesting while researching standards was the opening section of the Java Code Conventions document from 1997.

• 80% of the lifetime cost of a piece of software goes to maintenance.
• Hardly any software is maintained for its whole life by the original author.
• Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.
• If you ship your source code as a product, you need to make sure it is as well packaged and clean as any other product you create.

Enjoy the video and if so compelled, join in. Let's create something useful that benefits those who adopt it!

The world of the web is rapidly becoming the world of the web & cloud. Where much of what we consume, such as data, resources and media is not stored, manipulated or managed on the devices we use. The laptop you used a while ago, with the stored sales data, will soon be replaced by the tablet with 4g or super wi-fi access to immediate data results.

The concept of web services isn't new, it's been around for more than a decade now and it's only now that the reality is actually happening. One of the central issues behind this finally happening is not just technology, but a willingness to trust.

The "convenience factor" is winning out over any lack of trust - look at how much stuff people upload to Facebook! Of course, it's convenience, and a bit of ignorance by the less technically inclined. So what does all this talk about trust, ignorance and convenience have to do with FileMaker. Well, it's all about web services.

Two of those funny-sounding protocols for web services have been available in a very convenient plug-in for FileMaker. Creating a Mashup (a combination of a variety of technologies or technological services) is certainly doable within a FileMaker solution. All you need to know is a little bit of how things work and you're off to the races.

This video will give you the basics of using web services, and if you're left wondering what you might use web services for then how about these suggestions.

Package delivery confirmations from FedEx or UPS
Uploading designated pictures to Flickr
Pulling down invoices from PayPal
Pulling real-time stock quotes (an oldie but a goodie)
Generating barcodes which FileMaker can't do without an additional plug-in
Integration with AdSense and AdWords accounts
Integrating with eBay or Amazon marketplaces for selling things
Weather based operations
or Simply getting a listing of movies

Plus many more possibilities!

When FileMaker 8 was released in 2005 it was a game changer for the world of FileMaker scripting. You could now pass data into scripts from buttons - added to already being able to access data from within the script. It wasn't long after its release that developers wanted to pass information to scripts in a more structured fashion. "Passing multiple parameters" is a common term in FileMaker development and there are many ways to accomplish it.

In 2006 I released a video about the topic of "Function Scripting". It was a very popular article which advanced the idea of using scripts as something similar to functions and treating them more like methods in object oriented languages.

I simply combined two different sets of custom functions from two very smart developers. Over the years, I've used the method almost exclusively for passing information into scripts. Recently, however, I've started to use an evolved method of passing information into scripts.

The method I'm now using, focuses a great deal on code readability and facilitates both strict and relaxed parameter requirements. The function is a multipurpose function which can be used in many areas of your FileMaker solution. In this video, I walk through the evolution, some of the other options you have available and why I've chosen to adopt this new method of passing parameters into scripts.

Sessions and using a Sessions table is one of those advanced concepts, which you really don't add into a solution until you're really comfortable with building a robust database within FileMaker. The concept itself isn't that hard to grasp, more it's the implementation where things get sticky.

You really need to know what's going on with regards to how FileMaker deals with context in relation to what the current layout is tied to, and how that relates to the graph - which represents the structure of your data.

Sessions, within FileMaker, require you to become familiar with creating user interface abstractions. Straight forward, simple FileMaker means the layout your user is on, is tied to the same table the user is interacting with. When a user edits a customer, they're on a layout tied to the customers table - really simple, right?

It's the inevitable growth that all database solutions experience which cause you to either require or desire the use of a session model. Using a session record as your primary interface means you need to create links to the various data sources you're representing.

If this all sounds too complex to understand within a few sentences, then watch this video for a solid understanding of how it might work in your solution.

Providing users of your database with every possible clue, indicating the status or state of things, is something you should seriously consider - every time you start to work in Layout mode.

I must admit, I was personally a slow adopter of Conditional Formatting when it was introduced in FileMaker 9. It's been a few years now, and there are a lot of things you can do with it. Yes, it's lacking, in terms of being feature complete. You can't change the color of lines, it only applies to fields and text (none of the vector objects like rectangles, ovals, etc.) and you can't make things disappear with it. However, what you can do with it, should certainly be used.

When you combine useful logic, understand how to "sort of" hide things, and know a few of the behind-the-scenes tricks, you can really leverage this FileMaker feature. In this video, I present pretty much everything I know about using this feature for the purpose of adjusting what your layout will display. If you have your own tricks for using Conditional Formatting I'd love to hear them! Post a comment below.

Little by little, newer versions of FileMaker have been making it easier to accomplish tasks which typically required "workarounds" to provide certain features.

When it comes to filtering portals, the previous method was to use a dedicated relationship in order to filter out related data - which is still valid in a variety of situations. However, with the release of FileMaker 11, the new filter portal option, presented as a check box on the portal settings dialog, offers a much easier method for filtering portals.

Initially, there were some harsh critics, as the filter was a "display only" feature and did not adjust calculations which used the same relationship. Enter a few pieces of critical know-how and you get the exact feature you were expecting with all the bells and whistles.

This video showcases how to fully leverage the new filtered portal option within FileMaker 11. The example shown is one of the most common, where filtering is done on both a first and last name where either part contains a sequence of characters. If you're seeking that ultimate degree of filtered portal polish, then look no further than this video!

The other day, while recording a podcast with Matt Navarre, I mentioned that if a mobile component is part of my FileMaker solution strategy, that I would simply make a UI file specific to the mobile component.

It occurred to me that this concept, while simple, may not be the first thing you think of when creating your overall FileMaker system.

The truth is, it's much easier to isolate out the different, and distinct, components of your solution. Primary solution data, shared solution data, Mobile UI, Web UI and Desktop UI are all distinct from each other. However, many times, we tend to cram all these things together in one FileMaker file simply because it can be done.

This video introduces the concept of breaking out the different UIs and using the separation model to structure you FileMaker system.

The later part of the video highlights a wide variety of Mobile UI resources and tools. If you're heading down the path of using FileMaker Go for iPhone/iPad as part of your strategy then this video will certainly give you a comprehensive collection of resources to leverage!

It's time again for one of those articles about the "pretty" software. You know, where I talk about how people like to use things because they look good. Really, who wants to drive an ugly car when they can drive a pretty one that other people want to drive as well. Don't envy the pretty software, emulate it and join the in-crowd (no correlation to high school here).

Your database interface is no different than that car, and, while FileMaker doesn't currently have the state-of-the-art in user interface elements, there's no reason to not make your solution look as attractive as possible.

This video provides five different tips about how to approach the design of your user interface. It's one of my most favorite topics to cover, and there's always some little tidbit of knowledge which helps make your solution that much more usable!

No matter what FileMaker solution you're working on, you probably won't be leaving full admin access on the file. You don't want just anyone doing anything they want in the database - especially hacking up your beautifully crafted scripts.

So you'll be going through a process of re-logging into the database while both developing and testing. This can be accomplished using an easy or hard way. The harder way is to do what might come naturally, simply double-click the file after closing it down.

The problem is, any frequency of this activity and you'll quickly wish there was a better way. Fortunately, you can script most anything possible within FileMaker. This means you need a solid way of making this happen without making your solution insecure - which will certainly happen if you include vital credentials within the file itself.

You can always store a username/password combination in the file, while developing, and then remove them when you deploy, but this becomes an issue when you need to log in to make small fixes when the file is live - if you tend to do that type of thing.

The solution is to simply create an efficient method for switching accounts on the fly. That's exactly what this video has to offer!

After working with FileMaker's window script steps, for any length of time, you quickly start to realize there must be an easier way to center windows. Yeah, you can center the current window right within the New Window script step. But, what about making the centering optional based on either the monitor screen or the parent window.

Now, I'm sure there are thousands of different ways to approach this problem. Some of my fellow developers never want to see the window appear anywhere on the screen other than the intended final destination. Myself, I'm ok with a little resize and on-screen moving.

So, my typical approach is to use a few dedicated custom functions and a "one-stop-shop" script for managing all windowing functions.

You can find the functions I show in this video at my github repository here fmpfunctions on GitHub.com.

If you have your own method for managing windows I'd love to hear about it!