We’re a FileMaker User Group serving the Pennsylvania, New Jersey and Delaware Region
While it may seem that in life there are very few black and white choices, in the database development world, the either/or option (on/off, yes/no, active/inactive, open/closed) is pretty common. We know these choices as Boolean options. Continue reading ‘Advancing Technique: Using Booleans to streamline data’
It doesn’t matter what route you take if you don’t have a destination
-or-
Trigger happy
One thing that I really like about the direction that FileMaker has been going in since version 9 has been how the programming environment now encourages of the use of native UI features in FileMaker in highly customized solutions. Those of us who have been developing prior to FileMaker 9 – or those of us who have inherited solutions built before 9 – know all too well what it means to lock down the Status Area and then build core UI elements from scratch to replace the lost functionality. Many developer-hours have been spent to ‘reinvent’ features that were already in FileMaker, but in prior versions couldn’t be modified well enough to work in certain situations.
A clear, obvious example of this is the Toolbar. Almost every single ‘professional’ system I have worked with by default hides the Toolbar, and then the developer is forced to reinvent the forward and back buttons, the book/rolodex widget, and every other element of the Toolbar using buttons and scripts on the layout itself. What a waste of time!
In this blog post I’m going to look at one small segment of the Toolbar – the “View As” widget – as an example of how the Toolbar can be leveraged using Script Triggers. Continue reading ‘Easy Navigation between Form / List / Table views in FIlemaker 11 using ‘View as:’’
The Problem: Creating Master-Detail interface elements in Filemaker 10 and earlier was not straight forward.
You’d have to create a field to store the id of the currently selected record, then create a relationship matching just that id. If you’re in a multi-user setting you’d have to make sure the id storage field was global, so that selection was per user, not per record, otherwise you’d have the problem when one user changed the selection the selection would change for everyone.
The Solution: Now in Filemaker Pro 11 that all goes away with Filtered Portals.
Setting the global variable can use the same mechanism (onObjectEnter) on the portal. Remember though, in Filemaker Pro 11 you’ll need to add a refresh to update the portal.
Now all you have to do is set a script that sets a global variable, drop a relationship on the layout (potentially the same relationship you make the selection from) and filter it by the selected id.
Set the Calculation of the Filtered portal to match the selected ID with the record ID
Now you’ve got a simple interface that is easier to maintain and modify.
Mailing Lists:
Discussion List Subscribe Page
RSS Post Feed for this blog:
here. And while you're at it, follow IT Solutions here!
Recent Comments