Global Naming Most FileMaker developers begin the name their global fields with a "g" (i.e. gMyField). This differentiates global fields, at a glance, from regular fields. In addition, it groups global fields together, so they can then be more easily located in Manage Database and in other field listing dialogs. Unfortunately, this grouping places the global fields in the middle of an alphabetical listing. A better naming convention is to begin global field names with an "x", "z" or "zz" (my preference is "x"). This will group your global fields at the end of an alphabetical listing and differentiate them better from regular fields in a long list of fields (i.e. xMyField).
Level: Intermediate Version: FileMaker 16 Category: General Tuesday, September 12, 2017
The old saying that time is money is more than just a saying. The faster you can develop a project, the more money you can make as a commercial developer or, the more time you can devote to other projects as an in-house developer. Being as efficient as possible is the key to success. That's the primary difference between amateurs and experts. Balancing speed with quality is challenging though but, can be done. As you gain experience, quality and speed will both increase naturally, especially if you strive to improve in the primary areas listed below.
Templates Speeding up the development process can be accomplished by creating a template from which to start all new projects. As a commercial developer, it's the only way to make money but should not be overlooked by in-house developers. Templates essentially save you from recreating the same code over and over again. Templates also evolve over time. As you learn new techniques, add them to your template so new projects will benefit and you will grow as a developer.
I usually base all new projects on a contact manager solution. Almost every solution contains a people component. People might be customers, employees or consultants. A Contact Manager can quickly be morphed into a company manager to track vendors, clients or manufacturers. It’s far easier to remove features than to add them but I find clients welcome the additional features. Who doesn’t want a reminder system, contact linking or a correspondence tool with history. Providing the solution to your client for free or at a low cost is also a selling point so you can underbid other developers.
If you don’t have a contact manager solution, you should at least develop a general template, especially if you ever plan to create more than one solution. A template contains interface for form and list layouts, common custom functions, housekeeping fields, standard scripts and many other elements you would use in just about every project. Below is an example of standardized scripts from a template.
It’s unlikely you will develop the perfect template on your first try. It will evolve through time as you gain experience. After your first project, take notes on what pieces you can use on your second project and create your first template. After the next project, update your template to include new techniques and more efficient programming. It’s well worth the effort and a never ending project.
Don’t try to use a starter template from a third party developer. If you don’t know the code it will just slow you down. This is the very same reason I begin all my classes with a brand new FileMaker file, otherwise students get lost in the existing programming. It’s fine to borrow concepts from third party templates and implement them in your own template. But, there really is no shortcut to learning FileMaker. You just have to read a lot of books, scour internet blogs, download example files and build solutions till your fingers bleed. Most starter templates also fail in their attempt to solve every solution need out there. It’s best to have a fairly generic template or a template specifically designed for the solution at hand, like a contact manager.
I also recommend avoiding the starter solutions that come with FileMaker. They are designed for beginners so they don't necessarily follow relational rules or good programming methodology. With that said, I have learned many concepts from the starter solutions. It's where I first learned to hide buttons in find mode using the Get(WindowMode) function. I just don't trust starter files as a whole.
FileMaker Pro Advanced While you can develop great solutions in regular FileMaker Pro, FileMaker Pro Advanced makes development more efficient. With features like importing and copy/paste of tables, fields, value lists and scripts, you don’t always need a template. While regular FileMaker Pro can copy layouts elements, only FileMaker Advanced can copy or import schema from one file to another or within the same file. If you don’t have a copy of FileMaker Pro Advanced, it’s really the only way to develop.
Other features also help in efficient development. The Script Debugger makes it faster to troubleshoot problematic scripts. The Data Viewer can assist the Script Debugger by showing you field and variable contents but it also allows straightforward development and testing of new or existing calculation formulas. The Database Design Report (DDR) can help you determine more quickly what layouts, relationships and scripts contain a specific field or other element. Custom functions enable you to reuse or centralize calculation code, making it easier to update formulas. Efficiency is found all over FileMaker Pro Advanced as you will experience throughout this blog.
WARNING: It was announced in FileMaker 14 that the Runtime Maker in FileMaker Advanced would be deprecated. While it's still around today, it may be removed in a future version.
Everyone is unique and approaches a project differently. There are common approaches but two developers are likely to approach the same problem in different ways. It’s all based on some kind of combination of experience, disposition and brain chemistry. No one way is necessarily the right way. The important part is to develop a process that works well for you as an individual. The process will develop over time so be open to new ideas that work well for you. Don’t adopt an idea just because someone else told you it was good. Decide what works best for you.
For example, some people like to plan to the nth degree so all they have to do is start typing in their tables, fields, scripts and other schema. It’s like they create an outline of their drawing during the planning process and all they have to do is fill in the colors during the development process. Other people like to plan to a certain degree and then grow the rest of the project organically. I prefer the later approach but everyone needs to flow with the approach that works best for them. If you just follow the rules, you will never succeed.
You may never determine your ideal process but a perfect process is probably unattainable. It is important to have a method for approaching a project but that process will evolve over time, coming closer and closer to perfection. Explaining what that process should be is the hard part. You have to figure it out yourself in order to be as efficient as possible with your own unique talents. The process also changes with each project and each client. Be open to some level of organic development!
Themes Interface design can take up a large portion of the total development time for a project, sometimes as much as half. I highly recommend using themes to speed up the process of development. Whether you use one of the FileMaker, Inc. designed themes or develop your own, themes are far more efficient than custom interfaces. If you are a longtime developer like me, switching from custom interfaces to themes was like pulling teeth. But, I have finally come around for the following reasons.
With themes, you can build a template and literally switch between different themes without much effort, suiting the tastes of the client. Sure, you sometimes have to make some minor adjustments to object sizes and locations but the upside is tremendous. Making your client happy with a color scheme they selected is one of the best ways to have them buy into the process. In the old days, I often told my clients I would have to double the cost of a project if they didn’t used my canned interface. All that has changed with themes.
SIDE TIP: When switching themes, there are two level of undo. The first level of undo keeps the new theme but applies any changes made from the previous theme. The second undo actually reinstates your original theme.
Themes from FileMaker, Inc. have also been tested cross-platform for font and graphic compatibility. There is no need to test a theme if you have never used it before. FileMaker, Inc. software quality assurance engineers have already done the work for you. It’s practically plug and play, saving you tons of time.
Themes also work better with layout tools like Dynamic Guides. Trying to drag a custom graphic to line up with Dynamic Guides just doesn’t work very well. You will end up needing to use the arrow keys to eyeball your alignment. This takes away one of the most efficient features added to layout mode in recent years. Once I started using themes, lining up objects didn’t require alignment tools anymore. Just drag and drop. How cool is that.
SIDE TIP: The number of themes in FileMaker 16 has been drastically reduced, possibly even removing one of your favorites. The number was reduced to focus on developing and testing the the most modern and commonly used themes. But, you can still use your favorite themes from earlier versions by simply creating the file in FileMaker 13, 14 or 15 first. Just apply your favorite theme to a layout and then open the file in FileMaker 16.
If you are really industrious, you can design your own theme or modify an existing theme. It takes a lot of work but will differentiate you from other developers who are just using the standard themes. Since themes can be imported from file to file, your new theme can be used any time you like.
Keyboard Commands There are three types of computer users out there. There's the mouser who never touches the keyboard except to type some text. There's the DOS head who thinks the mouse is a waste of time, learning every possible keyboard command and dreading the moment when the mouse has to be clicked. And then, there's people like me, who are hybrids, using the mouse with one hand and issuing keyboard commands with the other, occasionally releasing the mouse to perform a complicated keystroke combination.
You are who you are so I'm not going to try to change you. Yet, I find extremes so limiting. If you are a mouse person, start learning keyboard commands for tasks you perform a lot like grouping and ungrouping objects. At least learn how to copy and paste, change modes or enter Manage Database with a keyboard equivalent. And, you keyboard Nazis, the mouse is actually more efficient for many tasks, so use it! It's about a balance between the two devices that makes development most efficient.
One of the most important areas to command via the keyboard is the Script Workspace. I also find keyboard shortcuts useful in layout mode but not as essential as the Script Workspace. The Script Worksapce was designed with the keyboard in mind and works very well with minimal mouse interaction. On the other hand, layout mode is inherently a heavily mouse driven area of FileMaker, given it's similarity to a drawing program. Anyhow, I've include a short list of crucial Script Workspace keyboard commands that will transform your scripting life you are still mousing around
Adaptive Programming Dynamic, or even indirection, are common ways to describe programming that adapts, without modification, to different fields, tables, scripts, layouts and files. Even the simplest code can change the speed at which you develop a project. Take, for instance, the code I use for deleting a portal row. I like to have a warning message customized to the portal. Instead of a separate script for every portal with a different Show Custom Dialog step, I use a script parameter and pass a text value representing the contents of the portal. Each time I create a new portal, I just copy and paste the delete button and change the script parameter value. So simple yet so efficient!
Most adaptive programming is seen in the scripting environment. However, it is possible to program dynamically in other areas such as calculations. For example, when I specify a file name in a calculation, I don't hard code it in parenthesis. Instead, I use the Get(FileName) function. Again, this is a simple addition but guards against file name changes. For example, if you hard code the file name in the ValueListItems function, the formula and the file name become dependent on each other. One small change to the file name and the calculation stops working.
While I could go through hundreds of examples of adaptive programming, the point of this article is to convince you of the merits of these methodologies. What I will say at this point is more of a warning. Don't overly program your solution with adaptive techniques. Choose wisely which techniques will benefit or you may end up with a sloth of a solution. One example comes to mind from the FileMaker 6 days. Everyone was releasing dynamic layout templates. These layouts would adapt in terms of tabs and buttons by simply typing in tab and buttons names in a field. It caught on like wildfire until people started to discover how slow it made their solutions. You hardly see these types of dynamic layouts these days.
All the Rest There are likely many other efficiency techniques and methods out there but this is the stuff I think about most of the time. Develop your own efficiency algorithms to increase your profits as a commercial developer or your time for other projects as an in-house developer. Other items discussed elsewhere in the blog such as naming conventions, single file structure, requirements documents and ERDs all lend a hand to efficiency. Learn a process that streamlines your development and you’ll produce solution more quickly with better quality.
Post your efficiency methods and techniques below. Don't be shy! Even if it is one simple keyboard command, hidden feature or process, let us know. You might make someone's day!
This blog is completely free. Please support it by clicking on one of the advertisers at the left side of the window. Thanks so much!
Thanks for another useful article. I have one question (at this time anyway). In your Portal Row Delete example, what sort of info are you passing, the actual contents of one of the fields? The implementation I of mine I am thinking of is a order tracking system where the descriptive information is one of the fields which can be somewhat lengthy as it is copied from their online order from, for example Amazon. On the other hand if I just put "line item" isn't descriptive at all. I could pull just the first few words but sometimes that's on helpful as it could be quantity, i.e. 5 of bla bla bla.
Thanks for your kind words. I really appreciate them. I pass a return separated string. For example, if the portal contained contacts, I would pass “Contact¶Contacts”. The first value is for the message asking if the user really wants to delete the contact. The second message needs to be plural based on how the dialog, telling the user they don’t have privileges to delete records, is worded.