Dear, Fuddy-Duddy, You work too hard. While there are times that you may need to create a "singleton" table for preferences and other universally accessible data, global variables DO work and they save you a lot of extra effort.
j. On Sep 18, 2013, at 3:10 PM, "Richard S. Russell" <[email protected]> wrote: > > On 2013 Sep 18, at 11:35, Nick Adams <[email protected]> wrote: > >> Hi, >> >> I would like to use a button to return to the previous layout. >> >> My scripts are (on each layout): >> Layout Trigger: on layout enter, set variable $$layout name:value: get >> (layout name) >> Layout Trigger: on layout exit, set variable: $$prevLayout: $$layoutName; >> value $$layoutName >> >> My Button Script: >> Go to Layout (name by calculation) [$$prevLayout] >> Adjust window [resize to fit] >> exit script >> >> My Startup script sets both of these variables to "" >> >> I have inserted a merge field for both variables and the variable are being >> set correctly but the script does not work, it stays in the same layout. >> The Script Debugger does not return any errors. >> >> Would someone please tell me what I am doing wrong? > > Call me a fuddy-duddy, but I've never learned to trust those $$ script > variables to still be there when I really need them. I always create actual > fields for the storage of information that I want to preserve from one moment > to the next. I keep them in a table called siimply "F" (for "file"), which > contains exactly 1 record and is cartesian-product ("x") joined to every > record in every other table, so absolutely the entire database knows the > value of every field within "F". > > I also have 2 standard scripts that I include in every file, "Remember > Location" (which is invariably called from within other scripts, typically > "Go to" scripts) and "Refind Current Record" (which is sometimes called from > within other scripts but sometimes button-activated all by itself). I expect > that you can draw upon their principles to generate script-triggered > equivalents. Here are the particulars of each: > > > So every place in the entire file knows what "F::Layout Saver" is. And here's > how they get back there (and, more particularly, how they get back to the > exact record within that layout): > > > > Each of those "XXX Saved" table occurrences is based on a link from "F::Seq > Saver" to the unique sequence number of the desired table. -- Jonathan Fletcher FileMaker 9/10/11/12 Certified Developer Fletcher Data Consulting [email protected] http://www.fletcherdata.com 502-509-7137 Personal miscellany online at http://jfletch.posthaven.com Kentuckiana's FileMaker Developers Group Next meeting: Tuesday, September 24th, noon to 3:30-ish http://www.kyfmp.com
