In Part 1 (“Check Please,”) and Part 2 (“Expert Panel,”) of this series, we had some fun doing things with button bars that showed off some of their unique usefulness within the FileMaker design-layer toolbox. Often as not, your button bars are going to include icon labels, with or without a supporting text label, and you want those icons to look great.
In button bars, you want a consistent visual weight across all the segments, and in both button bars and standalone buttons, you want icons that look crisp on both high-resolution (“Retina”) and standard-resolution displays. This article will help you achieve both of these goals.
Highlighting insight, performance and collaboration
Wow! InspectorPro 6 is finally here. Can’t even believe it. It was such a massive undertaking. Lots of great new things and many improvements. Really proud of this release. In the immortal words of the late Steve Jobs… “This is our best version ever”. The focus has been to deliver something that is truly useful. We hope this version helps you make informed decisions about your solutions.
One of the first lessons I learned with FileMaker is that of context! Layouts, reports, calculations, scripts, and so on all act from the perspective of a single Table Occurrence (TO) — the “context” — pulling in data from related tables as needed. Generally, the record set being acted on is the set of records in that context table occurrence or a found subset thereof. There are a few exceptions to this, however, and today we’re going to explore one of those.
A few years ago, I worked on a FileMaker project where the client told us that every week they need to import about 7,000 rows of data that represent some information that this company uses. And every week there might be some modified records, some records that don’t show up any longer, and some new records that hadn’t already existed. For this example, let’s just call it this data “Products”.
Over the years that weekly information grew to about 12,000 records per week. This PRODUCT table itself had 35 fields of data. So, without a way to manage the duplicates, every week lots of redundant data would need to be imported.
Have you ever had a FileMaker design conundrum for which you wished you could convene an Expert Panel to help guide you? If you’re thinking "panel of experts," I can’t help you, but if you’re looking for a more flexible and visually engaging alternative to FileMaker Tab Panels, this combination of a slide-panel control and a button bar just might be your "Expert Panel."
FileMaker Meetups: Seattle, Portland, Santa Clara & LA
Beezwax’s Vincenzo Menanno is hitting the road this week to visit our FileMaker colleagues across the West Coast, talking about “FileMaker Collaboration, Performance and Insight with InspectorPro”. Vince will be presenting our latest research, development and product offerings to FileMaker Developer Meetups in Seattle, Portland, Santa Clara and Los Angeles. If it weren’t a 4-day work week, who knows what other cities we’d be visiting!
Here’s a schedule of events, dates and times — and a Big Thanks to Meetup organizers for your help in hosting Vince’s presentations.
Ever wonder how you might be able to create a mobile app with data you already have in your FileMaker solution? I have, too! As it turns out, it’s not too outlandish of an idea thanks to the FileMaker Custom Web Publishing with XML API.
You might wonder, why build a native app? Depending on your data, or your use case, your users may benefit from the native functionality built into both iOS and Android which can provide advanced interfaces and features not readily available in FileMaker Go.
In this blog I will demonstrate how you can leverage the XML API to treat your FileMaker as a back-end and RESTful service. This technique allows for bidirectional communication from both a native iOS app in Swift, and a native Android app in Java. As a bonus, I will show you a workaround to upload container data to your database (according to FileMaker Inc. this is a limitation of the CWP XML API)!
Installation of FileMaker Server
FileMaker Intermediate to Advanced skills
FileMaker file with fmxml Extended Privilege set enabled
Permissions on the server to read and write
Ability to update the php.ini post_max_size and upload_max_filesize to allow large enough files
Installations of Xcode and/or Android Studio
Knowledge of Swift and/or Java programming languages, iOS and/or Android SDK’s
That sounds like a lot of prerequisites, doesn’t it? Well, this article doesn’t require you to know both iOS and Android development. You can be familiar with only one or the other, and still be able to follow along.
FileMaker 15 introduces a major enhancement for the Script Workspace that is a real boon for developers: editing Undo and Redo. This functionality continues the efforts at making the Script Workspace more like a “text editor”. It’s a stress-reducing development enhancement that I think will improve our ability as FileMaker Developers to write scripts. Undo/Redo gives developers a lot more freedom to experiment with code, without having to carefully manage the editing to avoid trashing existing code. When a refactoring doesn’t work as expected you can simply undo the change and get back to where you were. This new feature will even help you avoid embarrassing situations.
That said, it is helpful to understand exactly how FileMaker has implemented the script Undo/Redo so that you understand the capabilities and limits of the feature. I suggest you fire up FileMaker 15 and explore each of these points, hands on, as you read. Please also take a look at FileMaker’s documentation regarding this new feature.
SSL certificates are a very common way to secure client/server network connections, and the FileMaker platform has made use of them for many years. With version 15 however, FileMaker has made a number of security changes, in handling SSL and certificates, on both the server and the clients. But where do they come into play, and how might this affect your deployments?
In the transit-planning universe, planners and economists often get excited about 5 minutes shaved off of a 30-minute bus ride. The individual rider might shrug at a mere 50 minutes saved per week, but the planners and economists multiply that 50 minutes by the number of people who ride that route during a typical week and see something much bigger. There’s a compounding effect: it doesn’t take long before these small gains in efficiency add up to a huge economic impact overall.
What’s this have to do with FileMaker, you ask? Well, the new FileMaker 15 is now available, and the inevitable question comes up “should we upgrade?” Sometimes the best discoveries when a new version of FileMaker hits the shelves are the “sleeper” features and under-the-hood improvements. In the most extreme cases, these go entirely undocumented by FileMaker Inc.; such is the case with the improvements in portal performance that accompany the FileMaker 15 release.
Portals being a very important part of the FileMaker user interface, anything affecting their performance, good or bad, is going to have a major impact on the user’s experience. Users of a database application often spend large chunks of their workday in the application, so, like that 5 minutes shaved off the bus ride, small efficiencies add up through the same compounding effect. And, as you’ll see, this one is a “big” small efficiency!
No, I’m not talking here about the new, threaded portal rendering (aka “inline portal progress bar”) that is a key public feature point for FileMaker 15; I’m talking raw performance optimization. So impressive is this optimization, in fact, that I never even saw the new inline progress bar during my testing!