Cachemate 3.2

1.2k · December 13, 2003

CacheMate 3.2 was released today. I know I said that I was going to wait another week, but the only request to come in since then was pretty quick to implement.

The following new filters were added to the nearest cache search:

- Max. distance (distance unit settable in Preferences)

- Max. records

- Show only records where the Found checkbox is checked or not checked

Plugin export buttons were also added to the bookmark and nearest cache lists, and marking the current time for hunt start/end times should be easier now (as a button instead of a pair of menu choices).

As always, please check the documentation and FAQ before asking questions. That's what they're there for :lol:

1.2k · December 13, 2003

A tips & tricks page was also added to the site in the last week, for those that aren't subscribed to the Smittyware updates mailing list or monitor the RSS news feed. If you want to contribute, check that page for details. Thanks!

December 13, 2003

Thanks for the update, could of used it today - I was getting lazy and just marking the 'found' time. This will improve things immensely.

1.4k · December 14, 2003

Looks good!

One thing I noticed that's starting to bother me. It was there from the start, but I never said anything. The default install has a "Found" and "Not Found" category. But you've also got a found "flag". There seems to be no connection between the two. It seems rather redundant. How about making the Found/Not Found categories a filter instead based on the found flag?

Likewise add a filter for "Bookmarked". This would make exporting all bookmarked easier.

1.2k · December 14, 2003

The default install has a "Found" and "Not Found" category. But you've also got a found "flag". There seems to be no connection between the two. It seems rather redundant.

There seems to be no connection between them for a reason... there is none. What if you moved every cache you found to the Found category, but then chose to move some to an "archive" category that you wanted to keep (if they contained answers to a puzzle cache, for example) and delete the rest from the Found category when you were done posting logs on the site. The checkbox, if you used it, would still be checked no matter what category you moved it to. That's just one case (mine)... there's probably more.

You asked for the found/not found checkbox filter just so you could ask this, didn't you? :lol:

Likewise add a filter for "Bookmarked". This would make exporting all bookmarked easier.

Have you noticed, since asking for this, that there's now an Export button on the bookmark list if you have any batch export plugins installed? Going through the nearest cache search and adding "bookmarked" to the filter would be easier than that for exporting all bookmarked?

1.4k · December 14, 2003

There seems to be no connection between them for a reason... there is none.

In that case I'd suggest you not make a default "Found" and "Not Found" category. Then if someone creates it, they have no expectation of a connection.

Have you noticed, since asking for this, that there's now an Export button on the bookmark list if you have any batch export plugins installed? Going through the nearest cache search and adding "bookmarked" to the filter would be easier than that for exporting all bookmarked?

Bookmarked list? I overlooked that. What's needed now is a matching "Found" list. Correct me if I'm wrong, but until the export came along there was nothing that used the found checkbox, right?

1.2k · December 14, 2003

Correct me if I'm wrong, but until the export came along there was nothing that used the found checkbox, right?

It's used for the search filter and MemoPad log export.

How's this for another option... I drop the Found checkbox entirely and just put the category in logs exported to MemoPad. Of course, I could put the category in exported cache info as well, though it would be more involved to try importing that field. Sound like a plan?

1.4k · December 15, 2003

How's this for another option... I drop the Found checkbox entirely and just put the category in logs exported to MemoPad. Of course, I could put the category in exported cache info as well, though it would be more involved to try importing that field. Sound like a plan?

No, I'd rather not do that. Then there's no way you have have a "found" belong to a category.

BTW, there is something much higher on my list - when using the nearest cache feature, I want it to "stick" as my list when I exit from a cache. As it is now when I exit from a cache I have to go back and re-request the nearest cache and wait for it to go though and update the filters. Major pain when I want to work with a list of nearby caches.

December 15, 2003

I really like using this software. The only problem that I have is on the cache info page. You only see so much of the cache owners write up. If the write is long, like on some virtual/locationless you might not get the info on what the owner wants posted. Like, upload pic, upload pic with gps/you in pic, give coords..... This is also a problem with some of the caches where the owner has set it up as a story, and the real info is in the last line. I am using 3.1, will be updating to 3.2.

Thanks, August Code, kevin

Just found this in another post here, Cachemate Question. Hey! I markwelled myself.

Edited December 15, 2003 by August Code

1.2k · December 15, 2003

How's this for another option... I drop the Found checkbox entirely and just put the category in logs exported to MemoPad.

No, I'd rather not do that. Then there's no way you have have a "found" belong to a category.

The only choice I can see, then, is to not do anything about it. The search filter help text could stand to be touched up, sure, but how many are going to read the help text or documentation before asking (the "shortened description" question in this thread being the latest example).

BTW, there is something much higher on my list - when using the nearest cache feature, I want it to "stick" as my list when I exit from a cache. As it is now when I exit from a cache I have to go back and re-request the nearest cache and wait for it to go though and update the filters. Major pain when I want to work with a list of nearby caches.

Deja vu...

1) the nearest cache list can't easily govern the ordering of the main list, because of the database structure (the "nearest caches" list is separate, among other things)

2) there's a "last search" option, that you were partly the inspiration for, that skips any updating of the list before displaying it again (unless, of course, the database changes)

Not to mention the fact that the filters aren't reapplied unless they're changed or something is changed that causes something else to be done before they're applied (database or search location change).

1.4k · December 15, 2003

2) there's a "last search" option, that you were partly the inspiration for, that skips any updating of the list before displaying it again (unless, of course, the database changes)

Not to mention the fact that the filters aren't reapplied unless they're changed or something is changed that causes something else to be done before they're applied (database or search location change).

That's the problem.

1) I'm trying to use the nearest to work on doing some updates. Mostly re-classifying the categories. I can live with not updating the filters/location when going back. Perhaps that can be made a preference? (Do not rebuild list/filters database change only if the "from" location has changed or selected filter changes) The "force rebuild" button is right there for the times to do want to update.

2) Even if I wasn't doing updates, I still have to re-request the nearest cache after exiting from looking at a cache. For example, if I want to see the caches near me, I then look at one for details and then I want to go back to the list to look at another one, but I have to go though several taps just to return to that list. When I do a "goto" I'd like to come back to the list I came from rather then always returning to the main list.

1.2k · December 15, 2003

You're missing my point. Go to the Record menu and look for Last Search. What that does (and has done since version 2.3) is run the last requested nearest cache search, bypassing the location and filters dialog boxes and therefore keeping everything the same. If the database hasn't changed (no records added or deleted, and no coordinates changed in a record), it will take you straight to the list instead of having to rebuild/reapply anything.

The only time this will not happen is if you restore a backup of the PDA or upgrade to a new version of CacheMate. The reason it might not work the same in those cases is because the details of the last successful search (and the current mod count of the main database) are stored in a set of preferences that aren't backed up, the format of which may change as versions change. Other than that, though, it works as expected.

The Last Search option exists in both the list and record views, so you don't have to go to the list view at all to pull up the last nearest cache search again.

1.4k · December 16, 2003

You're missing my point. Go to the Record menu and look for Last Search.

Ah, that makes it less painful, but when I exit a record it's still two taps to get back to the list I was looking at before I "Goto" the cache.

When I tap "Done" in the record I want to go back to whatever list I had going before - be it the main list or the Nearest list. It would also be nice to go back to where I was in the list. The "Last Search" always takes me to the top of the list no matter where I was when I left it. Or am I missing something else?

1.2k · December 16, 2003

You're missing my point. Go to the Record menu and look for Last Search.

Ah, that makes it less painful, but when I exit a record it's still two taps to get back to the list I was looking at before I "Goto" the cache.

That, or you could do a shortcut-A in the Graffiti area

I think we actually had this discussion before as well (about the "Done" button and its functionality), but I decided not to do that for some reason. The "Last Search" option was put in as a compromise.

As for the nearest cache list remembering where it was, not sure about that. It does currently support the up/down buttons for scrolling, though, to make it somewhat easier than before to find where you were.

1.4k · December 16, 2003

I think we actually had this discussion before as well (about the "Done" button and its functionality), but I decided not to do that for some reason.

If it had to guess it was because of existing programming structure made it ugly to do. Maybe too much coding for it to remember where it came from? I know I've run into that before, having to do rather major re-writes because there was no good way to add a reasonable feature.

December 16, 2003

How about adding color options or putting more info on the screen for those with higher res color screens like the Sony CLIE?

Thanks,

Bobby

1.2k · December 16, 2003

If it had to guess it was because of existing programming structure made it ugly to do. Maybe too much coding for it to remember where it came from? I know I've run into that before, having to do rather major re-writes because there was no good way to add a reasonable feature.

Not so much the idea of too much code, but the only ways I could think of doing it without a major rewrite would make it too prone to unravel for my tastes (in other words, quite messy).

1.2k · December 16, 2003

How about adding color options or putting more info on the screen for those with higher res color screens like the Sony CLIE?

If I were doing my own drawing of text, then I'd say sure. The only place I'm doing that is in the list view, though, and the place where it would be most useful to use hi-res text is in the record view (description, etc), and I haven't yet found a way to set the font of a Palm OS field control to a hi-res font and actually have it work.

As far as color support, the details of that are still being worked out (the how, where and when to use it).

1.2k · December 16, 2003

As a new sub-topic, I'm going to try getting a new CMConvert release out before year's end, and wondering if there's anything people are looking for to put into it. So far, I've got the following:

- Option to auto-insert items taken/left notes template (someone asked for that in CacheMate, but it's easier to put it in the file converter)

- Stripping of HTML tags and leading/trailing whitespace from hints and cache logs (makes them cleaner for text display, and saves a bit of space as well)

Does anyone have anything else they want thrown in? As it stands, those 2 items already mentioned are done in the Unix/OSX version, and it's extremely simple to copy them to the Windows version.

December 16, 2003

Wasn't there mention one time about having a PC version of cachemate to use along with the palm version? Thanks

1.2k · December 16, 2003

Wasn't there mention one time about having a PC version of cachemate to use along with the palm version? Thanks

There was mention of a request for a PC-side companion for it aside from the file converter. I'm not sure when/if that'll happen, though, because the database as it currently stands doesn't lend itself to synchronization in the way that, for example, Address Book does.

1.4k · December 16, 2003

Not so much the idea of too much code, but the only ways I could think of doing it without a major rewrite would make it too prone to unravel for my tastes (in other words, quite messy).

Sounds like I hit the nail on the head Oh, well. I'll have to wait either for others to request the feature or for something else to happen to force a re-write.

1.8k · December 16, 2003

I would like to be able to convert the X number of caches closest to point Y where Y can be input, or a cache.

If pocket queries worked instantly this would not be necessary, but I often find a new query will not generate a GPX file until the next day, so I tend to have a few less well focused queries.

1.2k · December 16, 2003

I would like to be able to convert the X number of caches closest to point Y where Y can be input, or a cache.

That's something I've been kind of thinking about as well. May not get a before-year-end release out if I included that, but would be a nice addition for the next version

The math I can just copy over from CacheMate, but there's UI issues as well (both on the command line, which I could theoretically borrow from GPSBabel, and the Windows GUI).

1.8k · December 16, 2003

One of the reasons suggested it was because I could see it was a problem you had already tackled in principle.

I will look forward to it, whenever it is available.

December 16, 2003

As a new sub-topic, I'm going to try getting a new CMConvert release out before year's end, and wondering if there's anything people are looking for to put into it. So far, I've got the following:

- Option to auto-insert items taken/left notes template (someone asked for that in CacheMate, but it's easier to put it in the file converter)

- Stripping of HTML tags and leading/trailing whitespace from hints and cache logs (makes them cleaner for text display, and saves a bit of space as well)

Does anyone have anything else they want thrown in? As it stands, those 2 items already mentioned are done in the Unix/OSX version, and it's extremely simple to copy them to the Windows version.

I'm a UK user and would like to see the following in the program .....

1. it would be nice if the date in the 'Description' page was in the UK format i.e. dd-mm-yyyy (as it is in the 'Log' page 'Date of Hunt').

2. I'd also like to be able to search for caches by the 'Cache Set' date or, more importantly, the 'Date of Hunt' date.

Cheers for a great program.

1.2k · December 16, 2003

1. it would be nice if the date in the 'Description' page was in the UK format i.e. dd-mm-yyyy (as it is in the 'Log' page 'Date of Hunt').

Even better, I could format the date based on the locale setting on the computer because, once I get the UK date format in there, everyone else will come asking for their own Right now it's just copying the date as is out of the XML file. It's easy enough to parse it and do something more creative with it.

2. I'd also like to be able to search for caches by the 'Cache Set' date or, more importantly, the 'Date of Hunt' date.

By the date it was hidden, you mean? Not really sure how I'd do such a filter for both the Windows and *ix ports. Ideas?

1.8k · December 16, 2003

Surely it is set out that way because the description is taken from the GPX file and these use the official SI time format - Year, Month and Day in that order - it is completly unambiguous and has several advantages over UK and US conventions, especially in technical and international contexts.

The Log date is one you input using the Palm OS and will use the local date conventions which are of course configurable.

Note that the discription is always taken from the GPX file - for example, the type of cache is set in the description, and that is independent of anything you do on the info screen. Dates in past logs are also taken from the GPX file and are also in the international SI format.

I can see why it may appear odd initially, and I can see that Cachemate could be made to display these dates in a user configured way, but I find it difficult to see how an SI date can be misinterpreted, especially by a UK user who just has to read it backwards.

1.8k · December 16, 2003

To clarify - I was responding to MC and not Maeglin

December 17, 2003

<snip>
but I find it difficult to see how an SI date can be misinterpreted, especially by a UK user who just has to read it backwards.

Who said anything about misinterpreting the date?

All I said was it would be 'nice' if it was in the UK format.

December 17, 2003

Even better, I could format the date based on the locale setting on the computer because, once I get the UK date format in there, everyone else will come asking for their own :lol: Right now it's just copying the date as is out of the XML file. It's easy enough to parse it and do something more creative with it.

2. I'd also like to be able to search for caches by the 'Cache Set' date or, more importantly, the 'Date of Hunt' date.

By the date it was hidden, you mean? Not really sure how I'd do such a filter for both the Windows and *ix ports. Ideas?

Re 2. I keep a 'found' category and like to see what order, by date, the caches were found. I would really like to search on the 'date of hunt'.

The date the cache is hidden is unimportant (to me personally).

1.2k · December 17, 2003

Re 2. I keep a 'found' category and like to see what order, by date, the caches were found. I would really like to search on the 'date of hunt'.

The date the cache is hidden is unimportant (to me personally).

Ah, so #1 was for CMConvert, while #2 was for CacheMate. That's where my confusion came in, as the post you were replying to only asked for ideas for the former.

The locale-based date formatting to address #1 was quite easy to do. In fact, it's currently done for both ports of CMConvert.

The sorting by date I'll have to think about. Are you talking about the date when you found it, or the one of the latest "found" cache log? The former isn't that tough, but the latter is quite involved... I know where to get the date string from the latest log, but parsing it (now that it's not in a standard date format) is impractical if not impossible. If you were looking for the former, I'll take it under consideration at least.

December 18, 2003

Re 2. I keep a 'found' category and like to see what order, by date, the caches were found. I would really like to search on the 'date of hunt'.

The date the cache is hidden is unimportant (to me personally).

Ah, so #1 was for CMConvert, while #2 was for CacheMate. That's where my confusion came in, as the post you were replying to only asked for ideas for the former.

The locale-based date formatting to address #1 was quite easy to do. In fact, it's currently done for both ports of CMConvert.

The sorting by date I'll have to think about. Are you talking about the date when you found it, or the one of the latest "found" cache log? The former isn't that tough, but the latter is quite involved... I know where to get the date string from the latest log, but parsing it (now that it's not in a standard date format) is impractical if not impossible. If you were looking for the former, I'll take it under consideration at least.

For me personally I'm interested in sorting by the date 'I' found the cache.

Pease don't spend a lot of time over this ... I'm sure others have far more valid isues.

I'd like to say is this program adds so much value to my iQue 3600 - thanks - your efforts are very much appreciated here in the UK.

1.2k · December 18, 2003

47 hours since my "last call" post... all pending requests for CMConvert so far are done... as good a time as any for that before-year's-end release :lol:

CMConvert 1.6 is now on the site for download, in the separate packages near the bottom of the product list page. It'll show up in the CacheMate download when the next version of that is released.

This release adds the following:

- Distance filters (from coordinates or, in the Unix version, a waypoint ID)

- Option to automatically include items taken/left log notes template

- HTML tag stripping in cache hints and logs

- Dates now reformatted based on the user's locale settings

This was actually all finished last night, but I ended up adding more portability checks to the Unix version at the last minute, as well as an option to tell the configure script where the XML parser library is if it's not in an obvious place (as is the case in OS X sometimes, for example).

Now I just need to get JeremyA notified so he can update MacCMConvert...

1.2k · December 18, 2003

If pocket queries worked instantly this would not be necessary, but I often find a new query will not generate a GPX file until the next day, so I tend to have a few less well focused queries.

That should also be handy for a friend of mine around here who does benchmarking. He downloads the NGS data sheets and converts those, much like GeckoGeek does, but he doesn't have the room in his Zire to store all of them in the county, and currently uses GPSBabel's radius filter to create a more focused list. If he doesn't use the resulting GPX file for anything besides CMConvert fodder, then this would be just one less step.

1.8k · December 18, 2003

Thanks for the extra features, but I can't see a way of filtering by distance unless I choose Km or Nautical miles?

1.2k · December 18, 2003

You're looking for feet, or what? :lol:

Seriously, what unit are you looking for in there? I could add statute miles for a patch release later, but was initially modelling off of the same function in GPSBabel. Nautical miles are what GC.com uses, anyway.

1.8k · December 18, 2003

Really? I had no idea GC.com did not use statute miles, and I can't find anywhere on any of the screens I regularly use that indicates that, but it helps explain why everywhere always seems further away than I expected!

It is not that important, but I do feel uncompfortable being asked to filter using one of two units, neither of which I am particularly familar with. I suspect my discomfort would be eased simply by removing the N from N Miles in the drop down list! :-)

1.2k · December 18, 2003

Really? I had no idea GC.com did not use statute miles, and I can't find anywhere on any of the screens I regularly use that indicates that, but it helps explain why everywhere always seems further away than I expected!

I found it out when working on the nearest cache list. Originally I didn't have statute mile support in there, either, and the numbers matched up with GC.com exactly when I based from the home coords I have entered here. Then I added statute miles, switched to those and the numbers were slightly higher (as they should be... statute miles are around 800 ft. shorter).

Until I do add support for statute miles to the converter, you can always pull out your PDA and use the distance calc plugin that comes with CacheMate (provided you have it installed) :lol:

Edited December 18, 2003 by Maeglin

1.2k · December 18, 2003

On an unrelated note, the chances of a Magellan Nav Companion export plugin are looking rather bleak. Emailed them about it just over a week ago, only to receive an auto-reply and nothing since then. I guess they just aren't interested in sharing or explaining why, but I can guess.

Apparently robertlipe had the same luck, which is why he did it the way he did (reverse engineering) in GPSBabel, and made the disclaimer that Nav Com version support was going to be spotty. Personally, I don't want to go that route.

1.8k · December 18, 2003

It does seem strange to use N Miles in GC.com without telling anyone as, as you have pointed out, they are significantly different.

December 20, 2003

CMConvert 1.6 is now on the site for download...

Now I just need to get JeremyA notified so he can update MacCMConvert...

Not wanting to let the Mac version fall too far behind - MacCMConvert 1.3 is now available. This update means that it is now based on CMConvert 1.6 and adds a few goodies.

Jeremy

3.8k · December 20, 2003

Perhaps GC.com uses natical miles because that is what a degree minute is based on. One natical mile is 6000 feet. One minute latitude is 6000 feet. Of course this isn't true of longitude lines as they get closer together as the reach the poles. As an interesting aside the Portuguese where the world sea power in 1506 when they created the starting point for longitude lines through the Maderia Islands. The current prime meridian wasn't created until the English became the worlds leading power and wasn't set as the standard until 1884.

1.8k · December 20, 2003

Very possibly, but doesn't the very fact that you have a GPSr in your hand make the N miles - minutes equivalence redundant?

Edited December 20, 2003 by Learned Gerbil

3.8k · December 20, 2003

But it is less work when creating a miles from here map. No conversion, just simple subtraction.

December 20, 2003

On an unrelated note, the chances of a Magellan Nav Companion export plugin are looking rather bleak. Emailed them about it just over a week ago, only to receive an auto-reply and nothing since then. I guess they just aren't interested in sharing or explaining why, but I can guess.

Apparently robertlipe had the same luck, which is why he did it the way he did (reverse engineering) in GPSBabel, and made the disclaimer that Nav Com version support was going to be spotty. Personally, I don't want to go that route.

Thanks for looking into that for us Companion users. I have continued using NavCompanion and Cetus both for now. Although I have come to the conclusion that if I'm going to take $300 worth of technology into the woods, it really should be somewhat more durable than the Palm m515. I will be investing in a Meridian soon enough so I will be able to use the other Cachemate Plugins to Transfer Waypoints. Thanks for your efforts and thanks for a great product!

1.2k · December 21, 2003

Version 3.21 is now on the site, to fix a problem seen by a few Visor users, where the fields in the record view will become corrupted when switching between views of information. It was more a Handspring bug than one of mine, but thankfully it was easy to get around once I could identify it.

Thanks to robertlipe for helping me track down and fix that one. The fact that Handspring pulled the Visor ROM images off of their site long ago didn't help much in that regard.

1.8k · December 21, 2003

But it is less work when creating a miles from here map. No conversion, just simple subtraction.

I agree regarding the convinience of the equivalence - hence the smiley.

However, lets think about this. It only works N/S so is only one element in a distance calculation unless you always travel exactly North/South. A great help if you are navigating with sectant, ruler and tables, but not a lot of people Geocache that way.

Secondly, it is no help at all if you have no idea what Nautical Mile actually is. As it will take you about 20% longer to walk than a Statute Mile, I can't see how it is much of an advantage having an equivalence with a unit most people don't use.

December 21, 2003

We have discovered a anomaly (bug?) with cachemate.

While hunting a multi cache yesterday using cachemate on our iQues we were unable to locate the cache. As it turned out we were some 0.8 miles away from the actual cache location.

The reason was cachemate had 'discarded' a superscript 3. The clue description from the original cache page was

N**° **.(iii³)(ii+C)(ii) / W***° **.(iii³)F(iii³)

but cachemate had missed out the 'cubes' see below.

N**° **.(iii)(ii+C)(ii) / W***° **.(iii)F(iii)

Could this anomaly be corrected in a future release?

1.2k · December 21, 2003

We have discovered a anomaly (bug?) with cachemate.

It's neither... it's doing that because it was designed to. If those coordinates are in the description as they appear in your post, and I'm assuming there are numbers in place of the *'s, then it looks like you should have filled in something before exporting the waypoint to the iQue mapping software. The main cache coordinates, which would show up in the coordinates field of an imported cache record, would never be formatted that way.

What the coordinate parser does is look for characters matching N/W/E/S (case insensitive) and groups of characters representing unsigned floating point numbers, and ignores everything else. Anything else it treats as whitespace delimiting those groups of numeric characters. It happens to accept what you entered because the syntax pattern of what it found, as far as its parsing is concerned, matches "hddd dd.ddd" (latitude and longitude each being a heading character, followed by 2 numbers).

The accepted coordinate syntax patterns are in the documentation and help text (for the nearest cache search, anyway). The actual parsing algorithm isn't, because in most cases it's a little more information than is needed.

Cachemate 3.2

Recommended Posts

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment