4 of 4 people found this helpful
all happening in the same file ?
If yes, create a script to be called onLayoutEnter, attach it in layout mode to all layouts, which does
Set Variable [$$LayoutList; List ($$LayoutList; Get(LayoutName)]
then your back button will go to layout by calculation GetValue($$LayoutList; ValueCount($$GetLayoutList) - 1)
but this stuff brings some flexibility with it allowing you to set a $$layoutIndex you decrement with back and increment with forward buttons, and you use that $$layoutIndex to travel by picking GetValue($$LayoutList; $$layoutIndex) as dest layout.
And do trap for errors.
Thanks very much, Siplus.
Yes, it's all in one file. Looks great! I'll try this tomorrow as it's now already past midnight in my country
I am happy if you got the idea; the implementation is something you can twist until it reaches the flex you need.
This method has been used successfully for years; however, I use a variant that uses Get(Nth Record), so instead of saving the navigation history in a global where that data is lost at the end of each session- I use a line items table, so as I sit down with a client, I can prove which layouts are getting the most use.
I can also determine which users are using which parts of the solution. It's really easy data to save and the reporting capabilities make it worth the effort. As 'data' guys, I've never understood why developers don't store navigation history.
So you mention a new concept: "a session".
Maybe you should define it, but the fish I just catched, when interrogated, answered: "what happens between open and close of the solution".
(Sorry, I'm in Scooter mood this month)
Well, another keyword is "store". Combine with "hygiene".
You don't store data just because you can. It must have a purpose. Because when you have 30 doctors with 10 years of appointments resulting in a 5 mil app table, you wonder if there's a real value in doing what you do.
And believe me, on day d no doctor I know of wants to travel to layout set X he visited on day d-1.
YMMV, but don't suppose what your clients want.
and do Exclude things, like in "you don't want to know tomorrow your today's travel line, don't you" --> no
Yeah, do avoid featuritis.
In my mind 'session' is not a new term. FileMaker has it's own session controls and several attributes in FileMaker are 'session' based. An example is global variable. If you set a value, it will only be available during the current 'session'. if you quit FileMaker and attempt to query that global variable your old value will no longer to there.
Global fields have a very similar behavior; both are unique to the current user's session and do not effect other users; thus if you set a global field is a value of 1121 and another user set that same field to 4434; each of you will 'see' the values that you set- for the length of your session. If you close FileMaker, then the global values will return to their default state (normally blank, but there are exceptions).
In terms of my advice above. If users have two layouts to enter data on, a session based back button would do nothing to answer the question 'which one is the most popular?'. If that same data was save in a traditional field/ table, then we might discover that all your users except one use 'layout A' for data entry as opposed to 'layout B'.
Another scenario, is that you have a bunch feature requests, you can prioritize based off of which layouts are used by the most people. if 'Bob' has entered 10 tickets about the 'TPS Cover Sheet' layout, and there are two requests for a faulty drop-down menu, now you have access to information to see that fixing the 'drop-down' will affect 36 users, and fixing the cover sheet will only address a single user.
In Agile/ Scrum development, there are 'grooming' meetings where issues (stories) are prioritized. Sometimes 'use data' is important, but sometimes feedback from the own, project manager, or other developers will 'trump' everything else. It is a common question when planning changes to ask 'how many people will this affect?'- with a back button which saves it's data, I can answer those questions objectively.
I won't dirty your wide-reaching answer by hitting specific nails, but I would like to underscore that we know what a global var is; we do know how they behave and we do know how to handle them. It's a matter of reputation that obligates me to screenshot this FMPerception summary dealing with our main solution and the global var chapter. Probably having more GV's than all the fields in your biggest solution ?
If you enjoy simplicity:
You have a series of layouts with button that goes to the next layout
Button: Go to Layout B
So on layout B you create a button
Button: Go To layout A
No fuss, no muss and probably to simple to appeal to a lot of people.
I will try out the "BACK" button script later in the aternoon
Can you please help me understand the definition of the global variable $$GetLayoutList... i do not see where / how it is defined. Thank you!
Single user FileMaker Pro will retain the value in a global field, at least it has in the past. Multi-user will not.
Corporations developing software will spend $10,000 in overhead for a meeting to determine if a developer should spend one hour of time fixing a problem. Management loves to support itself rather than deal with fixing a problem. Avoiding a fix is often simpler than fixing it.
One well established Windows software companies uses a 20 year old Foxbase style application created by an amateur. It makes millions on support calls. My FileMaker file ran rings around it.
I was working mightily under my own guidance repair and updating a solution when the doctor decided to hire a ceo who brought in his best friend as IT director. I had been pushing for an inhouse server and the IT director just happened to have his own business and sent over a new hire to install FileMaker. He used a retired machine found under a desk for the server and just installed FMS without asking any questions about the machine or wiping the drive, etc. Seems the drive was a bit flakey and it had a virus which is why it was under the desk.
We went to war about his personally written software to monitor the server. I said there should be none. He insisted. After 12 crashes and lost data, for which I was blamed, I quit.
That IT director now works for Comcast...
Doesn't work. Anyway, they're 2 related tables in one file.