For what it's worth I tried this on the iPad, a hosted file, ~76000 records but 5882 in the found set. Not sorted, the slider and arrows work fine, and then sorted, also fine.
Then I flipped the found set so 70482 records were found. Slider & arrows still OK. Then sorted ... well, I got a "You are running out of disk space, please delete some of your photos and videos" box part way through, then it sorted for a while longer, then crashed. So I wasn't able to test the slider.
I deleted 2 iTunesU videos and tried again. The giant sort took forever, but it worked and so did the slider. I'm sorry I can't reproduce your problem.
I tried leaving the app by briefly switching to Pages to see a doc I already had open, then immediately back to FileMaker Go. It came up with the usual files starting point as you said, but I got a box that asked if I wanted to go back to what I was working on when I left. "Yes." Then I got a gray "Loading" page with the slider at the bottom, the text over it stating "Record 33376 of 70681/76386 (sorted) though the slider knob was all the way to the right. It stayed in the "Loading" state for perhaps 10 minutes. Then the proper record displays, and the slider knob is correct. I have a feeling that it must refind, or at least re-sort. Yes, this is enough to make me not want to leave the app.
I unsorted the found set, and tried the experiment again. I still saw the Files page and had to answer "Yes" but the found set and correct record came right up. It seems clear that the sort must be redone and is what makes it slow. Perhaps the mask for the found set is saved when the app is exited.
For a contrast, I tried this on a Mac, same records, current record, and sort. This sort also took a long time. Then I saved it as a Snapshot Link, quit FileMaker and relaunched from the link. The found set seems to have come right up, but then again a lengthy sort had to happen before the record would display. It seems there may not be a way to compactly save a sort result, which certainly would be a requirement for leaving the app on the iPad.
It does seem, however, unnecessary to have to see the Files page and answer "Yes" when you've only been away from the app for one second. I would think this would only need to be asked if the connection to FileMaker Server had timed out.
Rick, is your database a file on the iPad, or is it hosted?
I'm wrong about having to say "Yes" to Reopen Databases.
On the iPhone (which is what I normally use because it's been 4.1 for a while, able to shift between apps) I don't have to do that, so I wondered what the difference was. On the iPhone I have the setting "Auto-Restore Login" set to "ON" but I had neglected to do that on the iPad. With that setting "ON" now the iPad does restore the database to where I was when I leave the app for a moment. I do see the Files page first briefly while it says "Opening Databases" (same on the iPhone, and I'd prefer not to see that there either) but I don't have to answer a question before it starts.
If the found set was not sorted, it returns to where I was fairly quickly. BUT with a sort, that has to be done again, taking a long time, so this is a problem when leaving briefly and returning. It would be nice if FMI could find a way to cope with that.
Excellent replies Troy, many thanks.
I do not have an iPhone so iOS4 so the iPad is my first experience of multitasking on these devices. I was unaware of the "Auto-Restore Login" function, but following your reply this now works as I would have expected and you describe - i.e. returns straight to the last record viewed when switching back from another app - great!
Unfortunately the slider bar is another problem and less easy to describe - and overcome. My database files are not hosted, but worked fine under iOS3 and still work OK on my MacBook Pro. I've narrowed the problem down to sliding to first and last records only - i.e. the slider moves fully left or right but the record displayed does not follow.
The number of records is irrelevant - it fails to work on databases with 6587 records or 15 records. The slider updates correctly when moved to any position apart from the first and last record. The only way I can select these records is to move as close as possible and then tap the relevant arrow - e.g. with 6587 records, when attempting to move to record 6587 I have to slide to something like 6580 then tap the right arrow until I arrive at the 6587th.
Having said that, occasionally, when the slider is close(ish) to either end, moving the slider to the end works, but this is inconsistent. As you will appreciate, small files are no real problem, but large files are a pain. It will not move from one end to the other - i.e. if record 1 is the current record, when sliding to 6587 the slider moves fully right but the record displayed is still record 1.
Hope this makes sense
I gave this a try, near the ends. I can reproduce this, but only in List View mode (many records visible in a list), not in Form View mode (one record visible at a time). In List View, I can be in the middle of a set of records, and then slide the slider to the end, and, as you said, the record number above the slider indicates that it's the last record, but the current record in the list actually doesn't change at all! In form mode (which is how I was testing earlier) there does not seem to be this problem.
After more testing, I take that back about the Form mode. I can reproduce it there too, and I'm pretty sure I know what is causing it. If you slide the slider to the end, and your finger moves a little too far, the slider control seems to think that your finger is still on it, and is waiting for you to release the control for the current record to update. You'll notice that as you slide in the middle, the expected record number above the control is displayed, but the actual record isn't shown until you lift your finger.
On the other hand, if you purposefully slide the slider from the center to the end and keep your finger down so that it slide totally off the control, you can reproduce the problem every time. The control isn't interpreting the exiting of the finger from the control by sliding as a 'finger-up'. From what I know of iOS this should be easy for FMI to fix by catching that event too, and interpreting it correctly, either by having the control snap back to the center position (indicating you lost control) or by treating it as tantamount to a finger-up.
Brilliant piece of detective work. I concur with your findings - yes - it is as you describe. I've been 'flamboyantly' siding from one end to the other, overshooting in the process. When I take greater care to stop, before my finger goes over or beyond the arrow, the record is updated correctly.
Thanks for your help and feedback - best
Thank you for your posts.
Thank you for your "detective work". I am also able to replicate the problem. Moving the record slider beyond the slider boundaries will not update the record position. Using the backwards or forward arrows confirm this jumps to the previous or next record based on the previous active record.
I have forwarded your posts along with my findings to our Development and Software Quality Assurance (Testing) departments for further review and confirmation.