If that record was # 400 out of 3500 for example , the normal FM behaviour is to bring that record to the bottom most visible row when returning to the list view.
Erm, that's not "normal FM behaviour" for me with FMP 11. If the record is in the middle of the list view, that's exactly where the display returns to when changing back from form view. Nothing moves. (I have separate form and list view layouts and the switching is done through custom menus.)
The only time the current record appears at the bottom is if it was below the bottom of the window when changing to form view. Interestingly, the current record appears at the top row if it was above the window when changing to form view.
There may be a behaviour change in FM 12, indeed, but I do not have the problem in FMP 11 that you describe.
I'm running FMP 11.0v4 on Mac OS X 10.7.4.
Interesting to note that behaviour is on mac, i did not know that as i'm windows only. Windows works as described, however the scroll window script step seems to be the offender. I'll make a sample today to see if the problem can be replicated.
I'm on Mac now and cannot be bothered to close everything and boot into Windows, but the behaviour I describe is the same for Windows too.
I've been developing FMP solutions cross-platform for a over decade and have noticed some differences between Mac and Windows, but this is not one of them.
I don't know what you're trying to do, or why you think you need to do anything, because I do NOTHING and everything works perfectly: the user returns to the list view and the current record is displayed right where they left it. There is no need to scroll windows or switch records.
(BTW your switch records script does not account for when the user is on the last record of the found set, in which case the go to next record step will fail and result in the user being returned to the wrong record -- the second last record.)
Vaughan , you are missing the point. The point is that the scroll window script step does not seem to work properly now with FM12.
In FM12 , and FM11 in windows , the record is NOT exactly where the user left it if the active window switches away from list view and then returns. My 2 decades of FileMaker development experience tells me that this is how it works in Windows , and different to how you have described it on a Mac.
Try downloading this example and see if you get the same behaviour as described. Try scrolling to item # 00067 , for example , click on it (Go to Layout [Product Details]) , then click on "Inventory list" (Go to Layout [Inventory])
The issue is people usually work through a list from top to bottom, and when the user leaves the layout and then returns to it , they get frustrated because the record they clicked on is now the last visible record on the screen. This is where those script steps would bring the active record to the top of the list , not the bottom.
I know that this can be avoided if opening the record in a new window then closing the window when done looking at the record , but I want to avoid opening too many windows.
You are right about the last record issue , thanks for reminding me about that. I had that in mind after I had coded it , but had forgotten after the usual 500 distractions for the day. A "If( Get(RecordNumber) = Get(FoundCount)" should fix that.
Kind regards , Lee.
You're right that in Windows the current record reverts to the bottom of the screen when returning to list view. Mac is different.
A lot of changes in FMP 12 have been making the cross-platform experience identical between mac and pc, and in all cases I know of the pc behaviour has changed to match what happens on the Mac. Perhaps this is another instance of a change to make the behaviours consistent.
I don't have FMP 12 to test. Try seeing what happens when returning to list view without the scroll script thingy running. It may no longer be necessary.
That is what happens without the script steps mentioned above. Those script steps listed above in FMP11 will bring the selected / active record to the top of the list in Windows. My issue is that those same script steps do not work in FMP12. It's as if the [Scroll Window] script step no longer works in list view when running as a script. It does work , however , if using the same script steps in the debugging tool. I just wanted to confirm that other peoples experiences are the same before I nag FMI about this.
The Scroll Window has a bug and doesn't work properly in 12. It is not the same as it used to be in Mac or Windows, I've tested both. It does not work as described or as previously behaved. If you use the debugger, it will work properly, but use it live and it will not. I've had to make workarounds for my scripts that used it which including going to record I need to, commiting the record and refreshing the screen.
Here is the work around that worked for me;
To scroll back to home, use this script;
Go to Record/Request/Page [No dialog; 2]
Go to Record/Request/Page [First]
Scroll Window [To Selection]
I tried just going to record 1 without the second step but that didn't work.
At least we have a work around.