MightyData

FileMaker and WordPress Consultants

  • Company
    • About
    • Contact
    • Team
    • Artists
  • Services
    • Consulting
    • Development
    • Our Process
    • Coaching
    • Training
  • Results
    • Customers
    • Success Stories
    • Testimonials
  • Blog

How To Write a FileMaker Module

April 24, 2014 by Darren Burgess Leave a Comment

Hopefully by now you have found your way to ModularFileMaker.org and have checked out the many FM modules available to bolt onto your database solutions. mFM has endeavored to create standards and best practices for writing portable code modules that allow developers to incorporate new functionality into their database applications. The focus is entirely on portability.

While you are visiting mFM, take a look at the modules I have authored:

  • Propa-gator is a simple module for record creation. It allows you create a record in any context and set any number of fields in that new records. I wrote about this module in the MightyData blog as well.
  • My second contribution to the library is Accounts. This module offers wide range of functionality related to the management of user accounts in a single or multi-file FileMaker solution. It is currently at version 1.3 and has benefitted hugely from community input.

Have you considered writing your own module and submitting it? If so, I say go for it. Even if your idea is already implemented, the library of modules will benefit from a variety of solutions to the same problem.

Before you begin your project, I thought I would share some tips for helping you get started and moving on developing a module:

  1. Read the guidelines. Believe it or not, there is not much to them, and they are just that – guidelines. The guidelines are there to help you structure your solution and begin to grok the mFM way of thinking.
    Script organization and name spacing in fmModule
  2. Float your idea to the community and ask for help. There is a Google group devoted to mFM. Check out the various convo threads or perhaps start your own.
  3. Download a few published modules to get an idea of how to structure your scripts.
  4. Check out some of Todd’s videos on the subject of modular coding in FileMaker here and here.
  5. Start. Maybe that seems obvious, but it is worth mentioning that once you start the project, if you are passionate about it, it will take on a life of its own. I probably put 40+ hours into Accounts. It was well worth it, as now I have feature rich and robust Account management module available to any customer solution with just an hour or so of integration work.
  6. Ship. Don’t let your project get to 95% and then stop. Get it out to the community. I got great feedback on the modules I released that made them vastly better. You can pretty much guarantee that you won’t think of everything.
  7. Ship version releases. Your 1.0 does not have to be customer production ready. (BTW, check out the readme in the Accounts module. I use the readme to track feature requests, bugs and a proposed development roadmap).
  8. Eat your own dog food. Once it is ready, integrate your module in a customer solution, following your own integration documentation. I was shocked at how awful my initial documentation was. And I discovered bugs and new features by putting the solution out in the wild. (Just make sure you can easily roll back the solution, in case your module really isn’t truly ready for production.)
  9. Keeping eating that dog food! Integrate into more customer solutions – each time will reveal new possibilities.

Well, I hope that has inspired you to contribute to the mFM cause. The FileMaker community needs your ideas and your development skills will benefit from the discipline it takes to plan, develop, ship and improve a FileMaker module. I would love to hear about your ideas or feedback on published modules – ping me here in the comments or on twitter (@darrenburgess).

Filed Under: Rapid Development Tagged With: Development standards, FileMaker 13, FileMaker module

Propa-Gator: Modular Record Creation

May 21, 2013 by Darren Burgess 4 Comments

Creating records from global fields

A few weeks back I posted my first contribution to Todd Geist’s new collaborative effort to create a library of shared FileMaker modules. This script was originally inspired by the need to create reusable code for my customer projects at MightyData. My goal with the Propa-Gator module was to increase my coding efficiency by creating a portable script that would allow the creation of records and setting of any number of fields in the new record with any desired value.

In addition, I wanted the script to be able to use global field inputs as the field values in the new record and to nullify those globals on completion. Finally, I wanted to ensure that the script was completely context free and immune to field renaming.

The result was a script that I found to be a very useful in a variety of contexts:

  1. Related records can be created such as log records, phone numbers and attributes.
  2. Flat records can be normalized.  For example, if you have a table with two fields representing phone number 1 and phone number 2, you can loop through the found set of records and call the CreateRecord script twice, creating related phone number records in a phoneNumber table. I found this to be extremely useful when importing excel spreadsheets supplied by customers.
  3. Create record from global fields. Below is a screen shot from the examples provided with the Propa-Gator file.  In this example, the user can enter values in two global fields. The second field uses an OnObjectExit trigger to launch the CreateRecord script with the globals used as data inputs. The script has the smarts to identify that the inputs were from global fields and will nullify those globals.

Creating records from global fields

Scripted Find Requests

A common FileMaker technique is to build find requests using something like the following sequence of script steps:

Enter Find Mode []
Set Field [someTable::DateField1 ; ">=01/01/2010"]
New Records/Request
Set Field [someTable::StatusField1 ; "Complete"]

The CreateRecord script can be used in this case to create the find requests, as in example 3 that is included with Propa-Gator.

Enter Find Mode []
# Creates and sets values for first find request
Perform Script [CreateRecord] 
# Creates and set values for second find request
Perform Script [CreateRecord] 
# Delete the first request (it is blank)
Go to Record/Request/Page [First]
Delete Record/Request [No dialog]

Implementing CreateRecord Script

Implementing the CreateRecord script in your solutions is as easy as copying four scripts, three of which are for script trigger suppression and are not required. After you copy the scripts, take a look at the examples to explore ways of implementing the CreateRecord script in your solution. The most difficult part of this process will be properly implementing the script parameter that is passed. While the parameter syntax is clearly documented in the comments of the CreateRecord script, here is the example parameter with a bit of explanation. The parameter, when parsed in the script, creates three local variables: $CR_LayoutName, $CR_TargetFields, and $CR_Data.

"$CR_LayoutName = " & Quote ("DEV_Child")  & ";¶" & 
"$CR_TargetFields= " & 
Quote (
  List ( 
    GetFieldName ( Child::id_Parent ) ;
    GetFieldName ( Child::ChildData1 ) ;
    GetFieldName ( Child::ChildData2 )
  )
) & ";¶" & 

"$CR_Data =  " & 
Quote (
  List ( 
    Parent::id ;
    "SomeData" ;
    Get (CurrentDate) 
  )
)

The first line of the parameter establishes the layout name. When the script parses the script parameter, it will create a local variable $CR_LayoutName and set it to the value specified. The script will navigate to this layout and create the new record in the context of that layout.

"$CR_LayoutName = " & Quote("DEV_Child")  & ";¶" &

The next variable in the parameter, $CR_TargetFields, is a list of the fields in the new record that will be set by the script. Note that the list is wrapped in quotes by the Quote() function and each field name is wrapped by the GetFieldName () function. Use of GetFieldName () is critical to ensuring that changes to field names do not break the script parameter. In this example, the script will create the record and set the three fields in $CR_TargetFields list to the values specified in $CR_Data.

"$CR_TargetFields= " & 
Quote ( 
  List ( 
    GetFieldName ( Child::id_Parent ) ;
    GetFieldName ( Child::ChildData1 ) ;
    GetFieldName ( Child::ChildData2 )
  )
)

The final variable in the parameter, $CR_Data, is a list of data values. In this case, the three fields will each be set to the data value that occupies the same place in the list. Child::id_Parent will be set to the value of Parent::id, Child::ChildDate1 will be set to “SomeData” and Child::ChildData2 will be set to today’s date:

"$CR_Data =  " & 
Quote ( 
  List ( 
    Parent::id ;
    "SomeData" ;
    Get (CurrentDate)
  )
)

There are a few tricks to keep in mind regarding the $CR_Data variable. First, the data values can be any field accessible from the original context of the script (in this case the Parent record), or any literal or calculated value. If the source of the data value is a global input field as in the screen shot above, then the global field name should be wrapped with GetFieldName (). Doing so tells the script that source data came from a global field, and that the global field should be nullified as the script executes. Here is what that should look like in the parameter:

"$CR_Data =  " & 
Quote ( 
  List ( 
    Parent::id ;
    GetFieldName ( Globals::GlobalInput1 ) ;
    GetFieldName ( Globals::GlobalInput2 )
  )
)

The script can also handle data field values that have paragraph returns. For example, you may want to create a record and insert a list of values in a field. In this case, you need to substitute the sequence of characters “~CR~” to represent the paragraph return. The script then substitutes a real paragraph return when it encounters the string in a data value. In this example the third field will be set to a return-delimited list containing the values “FirstLine” and “SecondLine”:

"$CR_Data =  " & 
Quote ( 
  List ( 
    Parent::id ;
    "SomeData in single line" ;
    "FirstLine" & "~CR~" & "SecondLine"  )
  )
)

I should also mention that the script traps for a few errors. While most potential errors can be addressed by correctly passing the parameter of the script, I thought it would be prudent to trap for certain errors and return the error in the Exit Script[] step. In case of any trapped error, the script will exit and the new record will not be created. Errors from the following script steps are trapped:

  • Go to Layout[]: Generally caused by passing an invalid layout name, or perhaps security privileges that don’t allow access to the specified layout. (This is the only part of the CreateRecord script that is not immune to renaming).
  • New Record step:  An error may occur here when security privileges prevent new record creation.
  • Set Field By Name: Again, an error here could be caused by security privileges or perhaps a field name that does not exist in the context of the created record.

I hope you enjoy using the CreateRecord script in your solutions.  Since the work over at www.modularfilemaker.org is open source by nature, I invite you to pick apart and make suggestions in the comments below for improving the script. Or submit a revised file to darren_burgess@mightydata.com.

The latest version of Propa-Gator.fmp12 is available at: www.modularfilemaker.org

Filed Under: Rapid Development Tagged With: Demo file, Development standards, FileMaker module

Getting Faster: Installing Multiple Instances of FileMaker

August 15, 2012 by Darren Burgess 16 Comments

Multiple FileMaker installs on Mac OS

As you may have guessed by now, I love working in an optimized environment, designed for getting the crud out of the way so that I can focus on development. Just like a carpenter needs to not be thinking about the hammer, or the painter about the mechanics of the canvas, my computer and its operating system need to fade into the background, almost as if they were not really there at all.

Have you ever, in the course of working with a database, needed to do a long import, export or other time-intensive task?  For example, I have worked on a very large solution recently that required 4 hours to import the DDR into BaseElements. Not wanting to lose an entire 1/2 day to the task, I needed a solution where I could both perform the import and continue working on other projects.

More Than One Install

The best solution to this conundrum is to simply have more tools available. In this case, since I have two legal licenses of FileMaker 11 available to me, I have installed the application twice on my development machine.

Multiple FileMaker installs on Mac OS

Here are the steps to do so on Mac OS X:

  1. Rename the current installed version folder of FileMaker Advanced (or FileMaker). I used FMA11-A.
  2. Rename the installed FileMaker Pro Advanced application. Again I used FMA11-A.app.
  3. Install FileMaker/FileMaker Advanced again, using the second license key.
  4. Rename the folder and install application for this new installation. (FMA11-B in my case.)

That’s it! Now both versions can be run simultaneously. Note that when performing an update of the FileMaker software, the updater will ask you which installation you want to update. Select an installation, complete the first update, then run the updater again and it will update the other installation.

Two Tasks At Once

I can run that ginormous DDR import on one instance and be happily developing a solution on the other. It also means you can have two Manage Database windows, two data viewers or two script debuggers open at the same time. Or even two separate logins (Admin and User for example) into the same solution.

Here is a peek at what this all looks like in Finder.  Just for fun, I created new icons (download) for each of the installations. In OSX, use the finder info pane to change the assigned icon for an application:

Well, the icons are more than just for fun, as they provide a visual cue in the OSX dock and application switcher.  I hope you enjoyed this quick tip for setting up a more efficient FileMaker development environment.  I’d love to hear about your super-secret tips and tricks in the comments.

Filed Under: Rapid Development Tagged With: Demo file, FileMaker 11, Productivity, Software tools

Getting Faster: Multiple Monitor Setup

August 3, 2012 by Darren Burgess 11 Comments

Multiple monitors for productivity

As a FileMaker developer with a focus on delivery of high-value solutions as quickly as possible, I always look for ways to enhance my development environment to optimize speed and efficiency. As you can imagine, there are multiple tools that I need immediate and reliable access to throughout my development day.

Multiple monitors for productivity

Here are just a few of the resources (i.e. application windows) I need at my disposal:

  1. The FileMaker solution I am working on (potentially 1-6 windows at once)
  2. DataViewer and Script Debugger
  3. Manage layouts and manage scripts
  4. A text editor (usually TextMate)
  5. My development reference library
  6. Mail.app
  7. Safari
  8. BusyCal
  9. iChat
  10. OmniFocus
  11. Word/Excel

…and any number of other applications as needs dictate. Managing workflow with this many applications active requires a consistent environment. I need to be know where things are and be able to access them with as little friction as possible.

My Monitor Setup: 5 Screens

This is where a multiple monitor setup helps increase efficiency and allows me to focus my attention while simultaneously monitoring communication tools so that I can respond to immediate needs.

I current have 5 screens:

  1. 27″ Apple Thunderbolt Monitor
  2. 15″ Mac Book Pro
  3. 22″ LCD Monitor
  4. 24″ LCD Monitor
  5. iPad

In order to connect the LCD monitors, I use two Diamond BVU Display Adapters. These devices allow you to connect additional monitors to a system via USB. It requires one adapter for each additional monitor plus a software driver. The Windows driver is in the box, and Mac Drivers are available for download. They work well, although occasionally there can be screen flicker, graphic artifacts, or blackouts, and video performance is a bit laggy on the USB connected monitors. You will most definitely need a powered USB Hub in order to get all the USB cables hooked up.

With a multiple monitor setup, I can now position all of my application windows in a manner that allows quick access to resources. As a Mac user I make use of Spaces to organize my application windows.  For example, FileMaker and all of its required windows gets its own space spread out across all four monitors. iChat is present in every space on a secondary LCD. While I do move windows around, I try to maintain a set place for different windows so I know where they are. And, if my windows become disordered, I use the free application Display Maid to restore window positions and sizes in every space with a single keystroke.

My goal is to reduce and remove all friction in the environment so that I can focus on delivering high-value applications to our customers in the fastest manner possible.

Filed Under: Rapid Development Tagged With: Productivity, Software tools

More Reference Tools

June 29, 2012 by Anders Monsen 2 Comments

Reference guide in FileMaker Pro

The recent post from my fellow MightyData developer, Darren Burgess, caused me to reflect on my own developer reference tool. This is a tool I built using FileMaker, since there were times I needed the function reference offline, or without a floating help window. I built this tool a few years ago starting just with calculation functions, then adding more reference sections to keep everything in one place.

The tool went through some minor revisions the past few years. I added all script steps, a list of script triggers, a layout where the script triggers are spoken so I can get a sense of the flow or order in which they are fired, a list of all FileMaker errors, the fmsadmin commands, all the various system limits, ports for server, modifier keys, script trigger code numbers, and some keyboard shortcuts. As I came across something in FileMaker that I used and could be organized, I added it to my reference.

My Custom Library

As developers we tend to build our own code libraries and reference tools. In the past, I’ve stored my various libraries and notes in different places, from text documents to web pages, to MySQL databases and ftp folders. When I built my FileMaker reference it started small: I wanted to keep track of a few commonly used functions and examples so I could quickly re-use them. Once I started to add in the native functions, I found I couldn’t stop, and soon I had all the functions. Since these are available in the FileMaker help file, one might ask, “Why bother?” I preferred a simpler interface, and one I could manage myself.

This tool is comprised of individual tables for the sections, such as functions and scripts. Rather than store everything in one table, and make adjustments as I add types, I decided to keep all my types or categories separate. There is a simple dashboard interface that lets me jump to the various areas to quickly look up information.

Reference guide in FileMaker Pro

Developing this tool in FileMaker lets me experiment with several things, but as it’s a spare time effort, it remains continually under construction. Some of the information is basic – port numbers or error codes. Script steps are organized by type, with a goal of some day showing all the parameters so there no longer is a need to create a new script just to see these parameters. Rather than bringing up the Terminal and looking through the help, I can see all my notes at once.

Reference guide for FMS command line

Calculation Functions

Calculations often require trial and error. I set up the functions reference area so that I could test most functions without opening the Data Viewer, by evaluating the Code field (see below). This simplified method lets me quickly test some basic functions, and add notes as I come across certain behaviors or short-cuts. Though crude and limited compared to the Data Viewer, I’m able to extend this where the Data Viewer doesn’t work, such as FileMaker Go.

Reference reference for calculation functions

While not yet fully Go compatible, I ported over a version to FileMaker Go the moment this became available, giving me a reference-on-the-go. The smaller interface requires adjusting some features. The dashboard becomes more to the point. The space for notes no longer available, I considered using Show Custom Dialog. This does show more text while on the same record, but doesn’t allow editing. Still, having a quick reference in my pocket can be useful.

Wrapping Up

Reference guide on the iPhone

Although I’ve not added any FileMaker SQL references like Darren did with his Notational Velocity example, that seems like the next logical step. The key for any reference is to be comprehensive and useful, and as such my small tool cries out for a SQL section with examples.

As with every tool, there are pros and cons to building this reference tool in FileMaker. If I’m in the middle of something in another FileMaker solution, I cannot always get out of a modal window to check my reference. On the other side, I can experiment with design and interface using FileMaker, and as it’s my personal tool I can leave the mess unattended or shove it under a rug for another time. I think quite a few FileMaker developers have built their own reference tools. We have books, use the Internet for searches, but oftentimes we want to turn to something we use daily and assimilate the external knowledge into the familiar.

Filed Under: Rapid Development Tagged With: Development standards, Software tools

Getting Faster: Create a Development Reference

June 21, 2012 by Darren Burgess 1 Comment

Calculation functions in Notation Velocity

As a developer looking to deliver projects to my customers with the highest value, I am constantly looking for ways to increase my development speed. To that end I have created a developers’ reference library using a handy (and free) little application called Notational Velocity.  NV is an OS X application that allows for rapid creation and search of notes. While I have not tested such, apparently ResophNotes is an equivalent Windows application.  Both applications sync with SimpleNote, so you can get your notes on the web and on an iOS device.

Notation Velocity Library

NV uses a search-while-you-type field to allow you to search your database of notes. If the application does not find a match, you can simply hit enter and it creates a new note with the title you typed in the search field. Notes are stored as text files in a directory of your choosing and the app provides the necessary keyboard shortcuts for the power user.

SQL reserved words in Notation Velocity

My NV library currently has about 300 entries that include:

  • All of the FileMaker error codes
  • About half of the calculation functions
  • Various tested SQL statements
  • SQL reserved words
  • Commonly used calculations

Naming Conventions

Using naming conventions helps to organize the library. For example,  the FileMaker calculation function notes are named “fmfk” + FunctionType + Function Name, so that I simply can type “fmfkdes val” if I want to find the note regarding the ValueListIDs function:

Calculation functions in Notation Velocity

Hint: NV stores notes in a database in the application support folder on OSX. In preferences, you can change the location and choose to store the notes as plain text files.

My Development Library

So, who wants to collaborate on building a more comprehensive reference library?  I would be happy to share what I have created so far.  We could expand the library to include:

  • FileMaker Server error codes
  • The balance of the calculation functions
  • Windows and Mac keyboard shortcuts
  • Port numbers
  • Script steps
  • And more

You can download the current version of the library below.  If you have a suggestion to add to the library, please post a comment below.

20120626 Developers Reference

Filed Under: Rapid Development Tagged With: Demo file, Development standards, Notational Velocity, Productivity, Software tools

12 Days of FileMaker 12: Container Field Enhancements

April 23, 2012 by Kirk Bowman Leave a Comment

FileMaker Pro 12 brings a new storage method for container fields. This session from the 12 Days of FileMaker 12 introduces developers to the new storage method from a practical usage point of view as well as from a technical point of view.

Container Enhancements in FileMaker Pro

Topics in this video include:

  • Manage Containers option
  • Thumbnail generation
  • Secure container storage
  • Remote data transfer
  • Inspector options
  • Insert File script step
  • Converting older databases

About  Tim Neudecker

Tim Neudecker is a leading software engineer who has over 20 years’ experience as a professional FileMaker developer. He spent over ten years as an in-house developer for companies such as Macy’s/Bloomingdales and AGA. In 2003, he joined KyoLogic as co-founder and CTO.

Tim has presented four times to the FileMaker Developer Conference on topics including security, system performance and developer tools. He has published articles in FileMaker Advisor on system integration and performance tuning. In 2003, he was honored with a FileMaker Excellence Award for his contributions to the developer community.

Filed Under: Rapid Development Tagged With: 12 Days of FileMaker 12, Container fields, FileMaker 12, Performance, Video

The Importance of Consistency

September 13, 2011 by Martha Zink 4 Comments

Fields. Layouts. Calculations. Relationships. All of these are invaluable pieces of FileMaker and we, as developers, implement our own flare, excitement, and style to each of them. And as a lover of the Liberal Arts I believe that we should always thrive to be excited about what we do and how we do it. But do you know what makes it a better experience? Consistency. I’ve learned this lesson the hard way.

  • Flashback to the first database I ever built – I was so busy trying to understand and get things done that I forgot the magic of consistency.
  • Flash forward to 3 years after I built that database – I now had a sticky mess in front of me. Every time I had to change a script or find a relationship, I struggled with what I called that field or how I named that script.
  • Cut to now – While I still falter in consistency from time to time, I have learned the art of sticking to a style.

Here are some places where consistency can really help:

Fields

Choose a strict naming convention and stick to it! This is probably the predominant place for variation.

  • Are you going to use spaces?
  • Are you going to use underscores?
  • How do you name your primary keys?
  • How do you name your foreign keys?

With a recent development project where I needed to use SQL, I learned to avoid using an underscore at the beginning of fields (mainly for primary and foreign keys). Here’s an example of how I’d name fields:

  • NameFirst
  • NameLast
  • AddressStreet
  • AddressCity
  • AddressState
  • AddressZip
  • DateBirth

So what do you notice about the field names above?

  1. All fields that should be “grouped” begin with the same prefix. Most people wouldn’t say “name first” but from an alphabetical perspective, it helps to keep first name and last name together.
  2. Camel case makes the field names easier to read
  3. Above, I chose to avoid spaces but you could use underscores (e.g., “Name_First” and “Address_City” )

Layouts

Using consistency in layout names can eventually make for flexible scripts. For example, pick a suffix for layouts that are form view versus list view:

  • Contact – Main
  • Contact – List
  • Project – Main
  • Project – List

By being consistent, I could write a script that uses the Go To Layout step but instead of hard coding the layout name, I can use a calculation. Imagine that you are on the “Contact – Main” layout and you want to go to the list view. And you wanted a similar button for the “Project – Main” layout that took you to the corresponding list view.  You could write two scripts, or write one flexible script!

Here’s the calculation that would be used for the  Go To Layout script step:

Substitute ( Get( LayoutName ) ; "Main" ; "List" )

A calculation like that would work for either the Contact layouts or the Project layouts. Talk about flexible and easy!

Calculations

For calculations, I’ll focus on naming variables (whether in a script or in a Let function). The main goal for these is to be predictable. It’s never fun to hunt through a script to find what that variable name is. And as we know, since we have to always type in variable names (not select them like for fields), predictability means efficiency. Here are some examples of consistent variables I use:

  • $count – Usually used in a looping script to tell me what iteration I’m on
  • $total – If my looping script is based off of some stopping number, $total defines that number or stopping point
  • $sp – Get( ScriptParameter ) in a script
  • v – In a Let function, if I’m working with a field, I usually name a variable “v” for value so that I don’t have to keep referencing the long name of the field (or some other calculation)
  • theList – Naming a variable “list” is not a good idea as there is a calculation that uses that word. Add a prefix to all “FileMaker words” – the, a, your initials, etc.

I’m by no means preaching the need to use my naming convention. I’m just alluding to the fact that I’ve “memorized” these values, which means that I won’t be surprised when I open a script and see a $count variable, for example. The purpose becomes very obvious to me (or at least obvious enough with some context clues).

Relationships

This, for me, is a place where consistency makes for MUCH faster development. If your naming convention is inconsistent, you spend more time searching for the name from a dropdown list, like in a Go To Related Record script step, than you do actually developing the database. Here’s my naming convention (which is not an uncommon one):

  • Name your tables in either singular or plural form but stay consistent
  • Name your relationships based on the path
  • Use all caps for the Table Occurrence’s table name
  • Use a double underscore in special cases (self joins, for example)

Here are some examples:

  • PROJECT
  • project_PROJECT__sameCustomer (a self join to show projects with the same customer)
  • project_TASK (a relationship from Project to Task)
  • project_INVOICE (a relationship from Project to Invoice)
  • project_invoice_LINEITEM (a relationship from Project to Invoice to Line Item)
  • project_invoice_lineitem_PRODUCT (a relationship from Project to Invoice to Line Item to Product)

The point to take home is not my methods, but the idea of having a method. The real problem comes when you open up a solution you started 6 months, 12 months, 24 months later and nothing “makes sense” because there’s no method to the madness.

What’s your method?

Filed Under: Rapid Development Tagged With: Best practices, Development standards

Inspecting Inspector Pro

April 29, 2011 by Kirk Bowman 5 Comments

Searching for dormant calculations in Inspector

Recently I presented Inspector Pro by Beezwax to our development team during our weekly Innovation Meeting. Most of our team is familiar with BaseElements by Goya and I wanted to expose them to another tool. Personally, I have been using Inspector since it was called Analyzer in the FileMaker 6 days. As a result, I am very comfortable with the user interface of Inspector. (For the record, I use both tools equally although each has different strengths.)

Before I go further, I need to point out two things. First, “Inspector” is also the name of the palette to change element properties in FileMaker Pro 11. This article is not about that. Second, to use Inspector (or BaseElements), you need to have FileMaker Pro Advanced (FMPA) to generate a Database Design Report (DDR). The XML version of the DDR is imported into Inspector to create an analysis of the database.

Key Features

Inspector Pro 3.0v2 was released in March, and as a long time user, I was excited to see what changed in this new version. Of course, Inspector provides standard features like list and details views, a search interface, and reports for the elements in your database. Rather than a comprehensive review, my purpose is to highlight 10 features that caught my attention.

  1. Native FileMaker Finds – Inspector uses a custom interface with Quick Find and portals to display elements in your database. Now they have added “Raw Data” views so you can search the elements using native FileMaker finds.
  2. Find Dormant Calculations – A dormant calculation is one that has been disabled by turning off a field option (like Auto-enter by calculation) or changing the field type from Calculation to something else. On the Calculations screen in Inspector, you can enter “Dormant” in the Quick Find to view all the dormant calculations.
    Searching for dormant calculations in Inspector
  3. Apply Security Perspective – Inspector imports the settings for the Privilege Sets as part of the DDR. On the various screens, you can see what the effect of a specific privilege set is by selecting one from the Security Perspective drop-down.
  4. Display Changes Inline – If you have analyses of two versions of the same database, you can display the changes for a specific element “inline”. My only concern with this feature is it seems to require significant processing as it takes a few seconds to display (although it could be my computer).
  5. Script Step and Function Reports – These reports display an inventory of the script steps and calculation functions including how many times each is used. This is helpful to see, for example, how much the database uses If vs. Case.
    Calculation functions report in Inspector
  6. Index Percentage Report – This unique report shows the percentage of fields that can be indexed and the percentage of fields that are indexed by table. It also includes a bar chart for visual reference if you run Inspector using FileMaker (not the runtime).
  7. Script Trace Report – This report shows the entire code for a parent script, including subscripts with indentation, in one document. This saves having to jump in and out of multiple script windows in FileMaker.
  8. Open with FileMaker Go – If you host the database with FileMaker Server, you can open Inspector using FileMaker Go on the iPad. This is helpful if you need to review an analysis and you do not have enough screen real estate.
  9. Customize FileMaker Go Compatibility – As I write this article, FileMaker Inc. (FMI) has released FileMaker Go 1.2. Not only does Inspector show FileMaker Go compatibility when viewing scripts, it includes preferences so you can update the status of compatibility when FMI release a new version of FileMaker Go.
  10. Customize Detection and Comparison – Inspector also has preferences to customize how issues are included in a Detection Report and which elements are included in a Comparison Report. This is very useful if you only need to review certain elements types.

Also, Beezwax has setup a Wiki for the documentation including tutorial videos for some of the key features. Both the help text and the videos are useful for learning how to get more out of Inspector.

I continue to use Inspector each time I start to work with a customer who has an existing solution. Having this tool in my toolbox helps me get the best perspective on the database and ultimately, the customer.

Filed Under: Rapid Development Tagged With: Software tools

Standards Matter

April 4, 2011 by Kirk Bowman 1 Comment

Imagine going to a new city, renting a car, and driving to a new location without a GPS or access to Google Maps. You would be lost without a landmark or even a general understanding of the neighborhood. This experience is similar for the FileMaker developer who takes over a solution from another developer. In the typical situation, you have to follow the trail of breadcrumbs from the original developer.

These breadcrumbs, or development standards, organize the code so someone else can follow your work. The better the organization, the easier it is for the developer (yourself or someone else) to come back later and get oriented with the solution. The code is simply the elements in the FileMaker database: tables, fields, relationships, layouts, scripts, etc.

If you ask two FileMaker developers about their standards, you will get three opinions—one from each developer and a combination of the two. While there are strong opinions on the best way to do it, most developers agree the most important thing is to choose a set of standards and be consistent as you create your solution.

To help you get started with your development standards, here are some free resources from the FileMaker community.

  • FileMaker Naming Conventions and Standards – A good introduction to development standards for the intermediate FileMaker developer by DB Services, similar to those we use at MightyData.
  • FileMaker Development Conventions – In November 2005, FileMaker Inc. published a PDF by a group of leading FileMaker developers. It is in-depth and thought-provoking, although it can overwhelm the novice developer.
  • The Importance of Naming Conventions – CoreSolutions has been publishing development standards for over 10 years. They follow a modified version of the FileMaker Development Conventions by FMI.
  • FileMakerStandards.org – This wiki is a grassroots movement started by Matt Petrowsky. On this site, Matt and his colleagues explain their development standards and why they chose them.
  • FileMaker Coding Conventions – A video by Matt for FileMaker Magazine introducing the standards that became FileMakerStandards.org.
  • Anchor/Buoy Design Methodology – An outstanding presentation by Kevin Frank explaining the Anchor-Buoy method of organizing table occurrences (TOs) in the relationship graph.
  • Six Fried Rice Methodology – Two articles from the blog of Six Fried Rice explaining some important development standards: separation model and anchor-buoy.
  • Special Edition Using FileMaker 8 – Although the book was written for an earlier version of FileMaker, Chapter 27 is an excellent introduction to development standards including those used by the authors at Soliant Consulting.

Filed Under: Rapid Development Tagged With: Development standards

Let’s get started on your project.

It will be more fun than you think.

Get in Touch

  • Company
  • Services
  • Results
  • Blog

Copyright © 2023 · Parallax Pro Theme on Genesis Framework · WordPress · Log in