Post-Design Caucus Meditations
Albert and the gang at SmallCo host the FM Design Caucus on the first Thursday of the month where a group of developers get together to look at design issues using FMP. Luckily when it was my turn in November they went easy on me.
Object-Influenced Design & FileMaker Pro
If you didn’t get a chance to see Corn Walker’s DevCon presentation this year, you’ve missed out on an important foray into a topic close to my heart, Object Oriented (influenced) design and FileMaker Pro. Corn really gets into the "how". I am simply going to introduce the main concepts below. Hopefully I can persuade him to extend this discussion with a treatise of his own after he has put with his treehouse-building adventures behind.
First, when I talk about object-orientation, I am speaking of a way to think about your database application from a design perspective. This isn’t primarily about how you write scripts or "program" in FileMaker Pro. Rather, object orientation is the starting point of good application design.
Portal row locking “detail” pop-up window
Reprint of a post from May, 2004 before the days of FileMaker 8.x. Might still be a useful reference.
-
I ran into an odd problem while working on my project management
application in FileMaker 7. In one of my views, I have a portal in
which the fields are enterable and editable "inline". You’ll see in my
picture 
that
I have included a button that pops up a small detail window that shows
users more details about that portal row and allows them to edit and
add additional data to that portal row.
The crux of the problem is this. If you are "sitting" in a field in
a portal row and then click the button (the blue plus sign) which does
a "GTRR" (go to related record) of displaying it in a new, smaller
window, you’ll run into a record lock that prevents you from editing
the record in the detail view because the lock from the referring
window hasn’t been released. If, however, we release that lock by
committing the record BEFORE we do our GTRR, we’ll lose the focused
portal row and wind up going to the wrong related record (actually,
always the first related record).
Solution
The idea is to be able to commit our record but still return to our
portal row before doing our GTRR script. This is where script
parameters come to our rescue. 
Pass the Get ( PortalRowNumber ) function as script parameter with that
button. We can now safely commit the record, return to the portal row
by the value of the script parameter and happily do our GTRR.