Note: A special thanks to Jason DeLooze for sharing this technique, which neatly remedies a small, but vexing, annoyance.
Demo file: Show-Hide-Formatting-Bar.zip
Have you ever wanted to have a script toggle the Formatting Bar on/off in browse mode? If so, you will discover that FileMaker does not provide a “Show/Hide Formatting Bar” script step.
In July and August we explored several esoteric value list techniques. This time around, and over the next few postings, we’re going to step back from the cutting edge, identify some common value list challenges, and propose some solutions to those challenges. A few thoughts before we begin:
Now on to our first demo (Thinking About Value Lists, part 1 demo 1), which contains a table of employees with office sizes. Here it is in layout mode…
The other day someone asked a question on the FMP Experts list about plotting a driving route in Google Maps using FileMaker data.
Mark Rubenstein posted a simple solution, and my reactions were, in this order: “No way, it can’t possibly be this easy; I should build a demo (google-route-mapping) to find out; wow, it really works… hey, I wonder if he’d be okay with me posting this on FileMaker Hacks?” Continue reading “Google Route Mapping, part 1”
Note: FileMaker 12, released a few months after this article was written, introduced a “Find Matching Records” step, effectively eliminating the need for the techniques explored below.
Sometimes a seemingly-simple FileMaker challenge turns out to be more nuanced and educational than first impressions might indicate. This happened recently when I was asked to help make a scripted search behave properly. Most of the time, the existing routine worked correctly, but on certain records it would fail.
The challenge: Click a button to find all records with the same Note text as the current record.
No problem — how hard could that be? Any competent FileMaker developer can do this in his or her sleep, right? Well sometimes properly defining the problem turns out to be half the battle. Later, after the smoke had cleared, I built a demo to explore various approaches one might take…
…and we’ll get to that in a minute, but right now let’s look at the original script and the problem, or rather, series of problems, as they initially unfolded. Continue reading “Locating Matching Records, part 1”
Update 25 June 2012: this article and demo file have been revised to work with both FM 12 and earlier versions. Please see A Simple Backup Script, revisited
Recently I developed a system where the client wanted each user to only be able to see his or her own entries, and thanks to Custom Menus, some judicious scripting, and a bit of trial and error, this was accomplished.
I was feeling rather pleased with myself when the client asked, “What about the Keychain?” Well, what indeed? The Macintosh OS has a feature called the Keychain that “helpfully” offers to remember login credentials so that users don’t have to repeatedly type them in.
So imagine a situation where User A has instructed the Keychain to remember login credentials. What happens if User B gains access to User A’s computer, and opens the database? That’s what the client was wondering… actually, he knew what would happen (User B would gain access to User A’s entries). The question he was really asking was, “What are you going to do about it?”
I mentioned this technique in passing a few months ago (Portal Sorting, part 2), but today I would like to examine it in greater detail. Have you ever had a text object or a field that you wanted to selectively change based on some logical condition? For example, say you have a check box, and want the label next to the check box to change depending on whether the box is checked or not, like so:
In the old (pre-FileMaker 9) days, you could have used auto-enter or calculated field trickery, but now, thanks to the modern miracle of Conditional Formatting, you can make this happen at the layout level, rather than having to pollute your table schema.
Here’s a tip I picked up from Steven Blackwell the other night on Friday Night FileMaker Chat. FileMaker 11 doesn’t provide an obvious way to prevent a user from interacting with a chart in browse mode (e.g., copying, clicking on, dragging, or mousing over to view tooltips).
A while back I posted a technique to identify and count unique records. I recently discovered that while the technique is 100% reliable in terms of identifying unique records, under certain circumstances it will fail to count them correctly, due to what I believe is a bug in the way summary fields work. You can easily reproduce the bug by following the instructions in this demo file: broken summary field
Fortunately there are various ways to skin this particular cat, and today we’re going to look at one of them (demo file: broken summary field workaround).
The method for indentifying unique records hasn’t changed. Continue reading “Unique Records Revisited, part 1”
The other day I wrote: “I never want a dialog to draw attention to itself: a simple title, clear wording, no jokes, no strange button names.” Today I’d like to share a few other opinions on the topic of FileMaker custom dialogs, and as usual, I consider these to be general guidelines, not holy writ.
1. Life is too short to waste time thinking up fancy titles for your dialogs. I use the word “Message” 99.99% of the time.
2. As a general rule, the “non-active” choice should be button #1. If your dialog asks, “This may take several minutes. Would you like to continue?” then button #1 should be No, and #2 should be Yes.
However, if it’s an input dialog, then the active choice will need to be button #1, because currently FileMaker only accepts input via that button. And bear in mind that on the PC (but not on the Mac) hitting the Esc key always chooses button #1. (I know, that doesn’t seem quite right, does it?)
3. Set Get(LastMessageChoice) into a $variable, that way a) you can comment it, b) you can save some wear and tear on the calc engine, and c) very occasionally you will have multi-dialog scenarios and want to know which button was clicked on a dialog prior to the most recent one (in that case, of course, you’d want to use different named $variables for each dialog).
In case it’s not clear, the comment following Get(LastMessageChoice) tells the developer what action is associated with each button. Normally you can’t see that information when working with a script, unless you open up the custom dialog settings.
In the above example, I used an “If/Else If” construction to test the $button variable because I was planning to add more steps to each branch. If I didn’t need to add any further steps, then I could do away with the “If/Else If” steps and replace them with a single Set Variable step:
Set Variable [ $layout id ; Choose ( $button - 1 ; 383 ; 217 ; 288 ) ]
(If you’re not familiar with the Choose function, you can read about it here.)
