It’s time for DevCon. Yay! Come by the booth and say “hi”, if your here. If you’re not here, don’t worry, we got you covered. You can still get 20% off all our products with the discount code below.
We are very excited to announce that effective July 1st, 2016, Dave Graham, will be joining Geist Interactive as vice president of professional services. Dave brings an extensive set of skills and experiences as an executive, a consultant, and an outstanding FileMaker developer. He is a true triple threat, and we are thrilled to have him.
Dave is coming to us after a three-year stint as the VP and CIO of the nonprofit San Diego Workforce Partnership, where he was responsible for all aspects of the information systems, including managing the development and maintenance of all FileMaker systems. Before joining the San Diego Workforce Partnership, Dave founded and led the FileMaker development firm, Bit Tailor, LLC. He also served as the director of database services at Productive Computing and as the director of IT at Partnerships With Industry. All told, he has over 21 years of FileMaker and IT experience.
As the VP of professional services at Geist Interactive, Dave will be responsible for leading our custom software development team.
If this were a corporate press release, Dave would have said: “For some time I have wanted to return to consulting, which is where my passion lies. Todd is the creator and distributor of top-notch products and is recognized the world over as a leader and innovator in the FileMaker space. Geist Interactive was ‘hands down’ my first choice when I thought of the place I’d love to work. I’m thrilled to be working with Todd to position Geist Interactive as a leader in custom development.”
But this isn’t a corporate press release, so he just said this instead: “We believe that custom software is a right, and we are going make sure anyone who wants it can get it. Let’s kick it up a notch!“
We’ll be adding to our team so If you think you’d like to be a Geist Interactive developer, please contact Dave at firstname.lastname@example.org. Also, If you are going to be at DevCon in a couple of weeks, come by our booth and say “Hi”.
We rolled out a new version of Barcode Creator over the weekend. We added support for another symbology bringing the total to 19, and we added one improvement to the QR Code generation. This upgrade is free for all owners of Barcode Creator. You can download it from your account at Geist Interactive
Added the “GS1 DataBar Expanded” symbology. This is the same as DataBar Expanded, but with strict GS1 validation. (DataBar Expanded behaves the same: it will still encode data as GS1 if the input follows GS1 formatting rules, but will also tolerate non-GS1 data, as before.)
Improved QR Code compatibility with scanners that do not use the default configuration from the QR Code 2005 specification (including FileMaker Go).
It is always best to start over. Delete the old Barcode Creator module folder and copy and paste or import the new one into your file. Then reconnect your scripts.
June 13, 2016, Newbury Park, California, USA – Geist Interactive announces the availability of FMPerception 1.0 for FileMaker versions 12 through 15.
FMPerception – Analysis at the Speed Of Perception
FMPerception is a new extremely fast analysis tool. There is no lengthy import and processing step. Just open a Database Analysis Report and immediately start exploring your FileMaker system. Look for broken references, find usages of fields, and scripts and layouts or search for any text string. The structure of your entire multifile solution is there for you to examine.
FMPerception is so fast that you don’t have to break out of your development workflow to use it and you never have to worry about your analysis being out of date.
Here are just a few of the things you can use FMPerception for:
- Find everywhere a $$Variable is used
- Find broken references
- Use the free-form text search to find anything
- Find differences between versions of a solution
- Analyze multi-file systems
- Export results as CSV for processing or reporting
- Find where a field is used
- Find all serialized fields and what are their values
- Find all references to plugin functions
- Find all uses of a standard calculation function
- Find layout fields that are unstored calcs
- Find layout objects that respond to script triggers
- Find layout objects with local CSS
- Find accounts with a blank password
- Find which privilege sets can export
- Find every relationship with [sort/auto-create/cascade delete]
- Find out how many relational steps away are layout fields
- Copyable styled details (suitable for emailing)
- Find which privilege sets have restricted menus
- Find layouts, layout objects, scripts, and script steps that reference specific functions (user-definable)
“FMPerception reduces the friction normally associated with database analysis tools. Not only does it quickly provide you with the answers you need, but it lets you build tools on top of it so you can come up with your own tests and reports. We think this is a game changer.” says Todd Geist, founder of Geist Interactive.
FMPerception is available today, starting at $499. Free 14 day fully functional trials are available.
Mac only. Windows Support Coming Soon.
email : email@example.com
FMPerception was created by James David Ramsey of Hierarch LLC. and is published exclusively by Geist Interactive.
Unreferenced vs. Unused
Any FileMaker system that has been around for a while tends to generate a bunch of cruft, old stuff that isn’t being used anymore. It sure would be nice to get rid of it. But can we be sure that something isn’t used in any FileMaker system? Can FileMaker find unused scripts, fields, layouts etc? Well no, not exactly, but you can use some 3rd party tools, like our own FMPerception to look for things that are unreferenced. But before you do it is really helpful to understand the difference between “unreferenced and “unused”
What’s the Difference Between “Unreferenced” and “Unused”?
Simply put, when a FileMaker element is said to be “unreferenced”, it means that no other FileMaker elements reference it directly. However, it does not mean that the element is unused. There are lots of ways that something can be unreferenced but still actually be used by the system.
We can use programs like FMPerception to examine the DDR and determine without a doubt that something is “unreferenced”. However, it is much more difficult, and in some cases impossible to tell if something is “unused”.
There are coding practices you can follow to limit your exposure to this problem. The good news is that using these practices is usually a good idea anyway. See below for more information on these practices.
What’s a Reference?
A reference is a direct link between two elements in a FileMaker system. For example, fields that are placed on a layout are “referenced” by the layout. The layout actually has a list of field IDs that are displayed on it.
This is important. The layout refers to those fields by their IDs, not their names. This is why you can change a field name without the layout getting confused about what fields to use. This is a “reference”.
Here are some other examples. A Set Field step “refers” to the field it is setting by its ID, not its name. A relationship refers to its predicate fields by ID, not by name. A custom function references other functions in its calculation by those Functions IDs, not their name. A Go To Layout script step may reference a layout by its ID. ( Note the “may”. See the next section for more info. )
The key is that a “reference” is a link between two elements that is defined during development and does not change during the normal operation of the program.
How Can Something Be Used If It Isn’t Referenced?
Under some circumstances, FileMaker can dynamically figure out, at runtime, what element it should use as the source or target of an operation. When this happens, the target element is not “referenced” by the other element. The state of the program at the moment of use determines what element is used.
The Go To Layout step is a good example. When you specify the Go To Layout script step, you have the option of directly referencing a Layout, or using a calculation to return either the name or the number of the layout. If you use the name or number option, you are not referencing the target layout directly. You are basically saying, “When this script runs, take the result of this calculation and figure out what Layout to go to based on that”. You are telling FileMaker to figure it out at runtime.
This means the link between the script step and layout is dynamic. It can change during the course of the normal operation of the program. A layout that is targeted in this way is not “referenced”.
Is It Bad Practice to Write Code That Doesn’t Use References?
Not necessarily. It is a very useful and powerful technique. It can allow us to build abstracted and more portable code. However, there are consequences. You need to be aware of them and take steps to deal with them. If you don’t, then your code will be fragile and prone to bugs. It would be considered bad practice if you write code that doesn’t take this into consideration.
How Do I Know If I Am Using Reference-less Code?
The following functions and script steps are an example of code that does not require you to use references to other elements. If you are using any of these you may be writing code that doesn’t use references. I say “may”, because in almost every case you can change your code so it uses references again.
- Set Field By Name
- Go To Layout ( By Calculation )
- Open URL ( when used to trigger scripts)
- Go To Next/Previous Field
There are others. Script Steps like Go To Next/Previous Field don’t use references to find the target field. There are also Get Functions like Get(ActiveFieldContents) and Get(ActiveFieldName) that just use the current state of the system, in this case, which layout object has focus, to determine what field to use.
Here is another way to think about it. If you pick the element in a selection list, like with Go To Layout, or Set Field Script Steps, you are using a reference. In all calculation dialogs, when you enter a field name or choose the field name from the list, you are also using a reference. In all other cases, where you are targeting an element, you are not using a reference.
How Can I Add References Back to My Code?
It varies from situation to situation, and in some cases, it’s really hard to do. Here is the basic idea. Always grab the name, (or number in the case of a layout by number) with a referenced link before you use it.
As an example, if you want to use the Set Field By Name Script step, use the GetFieldName(MyTable::MyField) function first to get the current name of the field and store it in a $variable. Then use the $variable in the Set Field By Name Script Step.
You can do the same with ExecuteSQL(). This is so important to do that most experienced developers wouldn’t consider using ExecuteSQL without GetFieldName() to calculate the names of the fields they are using in the SQL statement. Not only does it help you determine if the field is used or not, it also means changing your field names won’t break your SQL.
Here is a FileMaker calculation using ExecuteSQL that doesn’t use references.
Let( [ // create the sql statement as a single string sql = "SELECT FirstName FROM Customer WHERE Status=?" ]; ExecuteSQL ( sql ; "" ; "" ; "active" ) )
This calculation will produce exactly the same as the one above. But it references “Customer::FirstName” and “Customer::Status” directly. It has another advantage over the above calculation. It will continue to work if you change the field names.
Let( [ // get field names using GetFieldName firstNameFieldName = "\"" & Substitute( GetFieldName(Customer::FirstName) ; "::" ; Quote(".") ) & "\"" ; whereFieldName = "\"" & Substitute( GetFieldName(Customer::Status) ; "::" ; Quote(".") ) & "\"" ; // get Table names also with GetFieldName customerTableName = GetValue( Substitute ( GetFieldName(Customer::FirstName) ; "::" ; "¶" ) ; 1 ); // create the SQL Statement sql = "SELECT " & firstNameFieldName & " FROM " & customerTableName & " WHERE " & whereFieldName & "=?" ]; ExecuteSQL ( sql ; "" ; "" ; "active" ) )
You could use similar techniques with Evaluate() as well.
It is more difficult to do with Go To Layout (By Name or Number), but you can still do it. You can use a script to Go To Layout (By Reference), and then store its name or number in variables for use later.
These are just some examples. If you understand what a reference is you’ll be able to figure out when you are using it and when you aren’t. It’ll also become clear if there is anything you can do to get the robustness of references and the flexibility of unreferenced abstracted code.
Can I Make It Easier for Reporting Tools to Find Things That Are Unused?
There are times when there is nothing you can do, or when you can make the code far too brittle to use and too hard to maintain. It would be nice if you could at least let a tool like FMPerception know that you care about an element even though it isn’t referenced.
It’s pretty easy actually. You can just make references to those elements.
Here is an example for dealing with scripts that are not hooked to buttons or otherwise referenced, but still used manually from the Script Workspace. You can create a script called “Referenced Scripts”, and reference every script that is otherwise unreferenced by using a Perform Script step.
It’s probably a good idea to place an Exit Script step at the top so all those scripts won’t ever be run accidentally as a batch. You could also just comment out the Perform Script steps. FMPerception will see that as a reference even if they are commented out.
You could even attach that one script to a button on a layout so that it shows up as referenced itself.
You could do this with just about everything else, custom functions, fields, layouts, etc. Think of it as a way to document your solution while helping FileMaker find unused elements.
Can the Tools Get Better Helping FileMaker Find Unused Stuff?
Yes and No.
The tools can get better at finding some of the text-based links between elements. We are looking into ways that FMPerception might be able to do this. But all that will do is reduce the false positives. It would designate fewer elements as unused. However, you will still need to consider each case carefully, since some of the reference-less links out there can not be statically analyzed. The only thing a tool can tell you for sure is if an item is referenced. The opposite of referenced is not unreferenced, but rather “Undetermined”
We are very excited to release Barcode Creator version 1.4. In this version, Barcode Creator gets support for DataBar and DataBar Expanded symbologies, some speed improvements, and a couple of other refinements. With this release Barcode Creator can generate every symbology that FileMaker Go can scan, and it still does it without fonts, servers, or plugins. Its all just pure Filemaker scripts.
Today we are releasing Barcode Creator 1.3.0 with support for generating EPS barcodes on Mac Desktops. The EPS file format is vector based and therefor scales up or down with no pixelating; like you get with bitmap formats (PNG). A bug in FileMaker prevents the correctly produced EPS file from rendering in container fields on anything other than macs. But the feature is so important for some use cases, we decide to make it available Read more
Today FileMaker Inc. announced the FileMaker iOS Application SDK, a toolkit for building fully native iOS Apps. This is awesome. Finally we can build applications for iPads and iPhones that look and behave just like native applications. How does it all work, though? Read on to find out more.
Does the Apple Pencil work with FileMaker Go? The answer is yes! You can use an Apple Pencil along with FileMaker Go’s native signature capture feature. Here at Geist Interactive we have two addons for FileMaker Go, GoDraw and GoSign and both Apple Pencil compatible. So now you can say “FileMaker Go Apple Pencil” as if they belonged together. 🙂