I see what you mean. That's a bug of sorts it would seem. I'll look into
that. The good news is that there turns out to be a simple work around.
After you've used the search feature to find your cache in the list,
simple select the cache detail (which you probably do already.) Now this
set's it as the "target" cache as can be verified if you check the GPS
tab. Now clear the search field and it will indeed resort INCORRECTLY as
you have found. However, it still retains your choice for the target.
Simply tap the name sort button and then tap the cache sort and your
selected cache will now be at the top as you wish. You've found a subtle
bug but until the next release come out this will serve as a workaround.
I think the problem is that I've just implemented a "cache" sort on exit
from the search using the cancel button rather than the "current sort."
You can get the same "update" correction if you just tap the GPS tab and
then return to the list. iGeoCacher "knows" what you selected, it's just
the exit from the cancel button that is hosed.

Now as for the second thing. I'm not quite sure what you are describing.
If you are in cache mode and scroll around and select some cache down
the list to view detail, the nature of the beast is to put THAT cache at
the top and resort by distance from it. That facilitates looking at all
the caches in the neighborhood of a given cache. Now when you "pop" back
the list scrolling position hasn't been updated. Hmmm...I think that's
what you were trying to describe. I can see how it would be nice to
start at the top of the list when the cache sort was in view. I can't
recall if the API let's me set the scroll position that way but I
suppose I could just reload the view (though that is expensive in terms
of CPU.) Let me check into that. It is an excellen usability tweak.

Usually, when I'm doing CACHE mode I'm in an area already and near the
top of the list and I'm just selecting nearby caches so they sort of
appear naturally but I can see how if you pick one in the middle of the
list that it could be disorienting. Good catch! Your email has just been
deposited in the folder where I keep feature requests. These shouldn't
be hard so I think you'll see them soon.

THANKS FOR THE GREAT FEEDBACK!!

-dB
http://www.ayefon.com



dwreigel@... wrote:
>
>
> Don
> I have either an operator error problem or request for a little logic
> change. My problem results when going to the "cache" sort AFTER
> finding a cache using the "search" option.
>
> Since we use an iPod, the POS sort of caches doesn't work in the field
> for us but the CACHE sort works very nicely -- once we get it "keyed".
> We now exclusively use that an the SEARCH option to find the next
> cache info. Our problem is the "start" of this sequence or an "Oops".
>
> Starting problem: When we first start, the CACHE sort list starts with
> whatever was last looked at, so when ready to look for the first cache
> in an area, we usually find the cache info using the SEARCH choice.
> That works fine. However, to get back to the CACHE sort (or any full
> list), it is first necessary to delete the SEARCH info, which we
> typically do by touching the "X" to delete the info and then "cancel".
> The problem is that the logic seems to "forget" the last cache info
> looked at, so the CACHE sort does not start with the one we just
> looked at. Unless we are doing something wrong, is it possible to
> tweak the logic so that the last cache looked at, whether accessed
> from one of the lists or using the SEARCH, is retained and used for
> the CACHE sort after canceling the search?
>
> Oops problem: Our second problem is more of a clumsy finger issue.
> After cache info for a cache is viewed (from any one of the lists
> other than "search) and the button on the detailed cache info page
> touched to return to the CACHE sort, that cache pops to the top, but
> the list itself locks on some other basis (i.e., frequently in the
> middle somewhere of the updated list). This would be no big deal
> except that while scrolling to the top of the list, if one
> inadvertently pauses too long and "selects" an intermediate cache,
> that one now becomes the top one. If it can be done, a simple solution
> for us clutzs would be to have the CACHE list automatically return to
> the top when the "return to list" button is touched from the detailed
> cache info.
>
> Regards,
> Dave
>
>