Jump to content

Gsak (geocaching Swiss Army Knife)


ClydeE

Recommended Posts

The filter screen no longer has the option to select caches with travel bugs

 

or is there another way to do this now?

 

<snip>

:):D

 

cap65.png

 

Edit: Woops, sorry didn't mean to rub it in . I hit reply on the previous page before noticing we are now up to page 2 :)

Edited by ClydeE
Link to comment

Darn - I just irreproducibly reproduced the dialog "lock in front" problem in the released 6.5.

 

Actually I was able to reproduce it a second time, but it's kind of unpredictable as to when it's going to lock up. I hope I can reproduce it again on demand, but no guarantees.

 

The key seems to be to keep modifying the same filter. In my case, I was trying to produce a filter to identify caches not found by me and another cacher. In other words, ones we both haven't found.

 

In experimenting, I kept launching the filter button to modify the last filter, and in a few tries, the filter seems to complete, but the dialog window remains in front. The hourglass has gone away and the background database report seems to be updated.

 

The dialog will move around, but remains in front. Cancel and close are ignored. After moving the window, trying to cancel, close etc, then moving it back, the window suddenly vanished. I thought maybe the filter hadn't finished maybe? Only the next attempt to edit the filter, the dialog stayed in front and now I couldn't move the dialog or anything.

 

I wonder if the problem is related to trying to cancel a complex filter in progress? I've previously noticed that the cancel buttons sometimes don't cancel anything, so maybe I'm just moving a little too fast.

 

Let me know if there's something I can do/turn on/etc. to help you capture it (assuming I can reproduce it again).

 

Jon

Link to comment
When connecting to Google Earth throught GSAK, the caches selected are identified by a white square with a white flag. Can I change that so it as the cache type icone?

Yes :) , one GSAK user has written a macro that will do exactly this.

 

There were a few minor issues and it would only work under version 6.5

 

I think everything has been resolved now so when I get a moment I will add this macro to Http://gsak.net/Macros.php

Link to comment
Darn - I just irreproducibly reproduced the dialog "lock in front" problem in the released 6.5. 

 

Actually I was able to reproduce it a second time, but it's kind of unpredictable as to when it's going to lock up.  I hope I can reproduce it again on demand, but no guarantees.

 

The key seems to be to keep modifying the same filter.  In my case, I was trying to produce a filter to identify caches not found by me and another cacher.  In other words, ones we both haven't found.

 

In experimenting, I kept launching the filter button to modify the last filter, and in a few tries, the filter seems to complete, but the dialog window remains in front.  The hourglass has gone away and the background database report seems to be updated.

 

The dialog will move around, but remains in front.  Cancel and close are ignored.  After moving the window, trying to cancel, close etc, then moving it back, the window suddenly vanished.  I thought maybe the filter hadn't finished maybe?  Only the next attempt to edit the filter, the dialog stayed in front and now I couldn't move the dialog or anything.

 

I wonder if the problem is related to trying to cancel a complex filter in progress?  I've previously noticed that the cancel buttons sometimes don't cancel anything, so maybe I'm just moving a little too fast.

 

Let me know if there's something I can do/turn on/etc. to help you capture it (assuming I can reproduce it again).

 

Jon

Yep, this one is a strange one all right.

 

After literally hundreds of hours on this one I have still not been able to reproduce or get anyone to provide me with the steps to do so.

 

There seems to be a lot of things in the mix that cause it to happen but so far no one has been able to pin point exactly what that "mix" is.

 

Of the few that have reported this issue, most get around it by clicking on the red x in the tool bar before setting the filter (this destroys the filter dialog in memory and then regenerates it from scratch) In fact, if you can get to the red x in the tool bar (not the cancel button in the filter dialog) this has also been reported to resolve the problem when it happens.

 

So if you hit the magic formulae, please let me know.

Edited by ClydeE
Link to comment

got messed up with the time out issues - this should have been posted here -

 

tools => Grab Coordinates

 

I click on Current Waypoint and it comes back with all zeros -

I make a list with only a couple caches and click Current Filter and get all zero's

 

so what am I doing wrong -

 

read the help a dozen times and it still says the same thing -

 

there seems to be two functions -

a - to get coords into gsak

b - to get them out of gsak

 

can someone make sense of this for me?

 

and ya - I'm trying to learn all the cool new features here <grin!>

 

cc\

Link to comment
When connecting to Google Earth throught GSAK, the caches selected are identified by a white square with a white flag.  Can I change that so it as the cache type icone?

Yes <_< , one GSAK user has written a macro that will do exactly this.

 

There were a few minor issues and it would only work under version 6.5

 

I think everything has been resolved now so when I get a moment I will add this macro to Http://gsak.net/Macros.php

Now available.

 

The macro is called ge.txt and can be downloaded from here

Edited by ClydeE
Link to comment
got messed up with the time out issues - this should have been posted here -

 

tools => Grab Coordinates

 

I click on Current Waypoint and it comes back with all zeros -

I make a list with only a couple caches and click Current Filter and get all zero's

 

so what am I doing wrong -

 

read the help a dozen times and it still says the same thing -

 

there seems to be two functions -

a - to get coords into gsak

b - to get them out of gsak

 

can someone make sense of this for me?

 

and ya - I'm trying to learn all the cool new features here <grin!>

 

cc\

The "Grab Coordinates" will scan through the descriptions of the caches you select and "grab" likely looking coordinate pairs (Parking for example)

 

If there isn't any of these coordinate pairs in the waypoints you select then no waypoints will be "grabbed"

Link to comment
It's reproducible for me anyway at this point.  Emailed recipe directly.  Hope this helps the bug overcome its shyness.

I am one of the folks that occaisionally is troubled by this bug. I have a general sense that is may be associated with the poly/arc feature.

 

ikim & noj, does your filter include polygons?

Link to comment
It's reproducible for me anyway at this point.  Emailed recipe directly.  Hope this helps the bug overcome its shyness.

I am one of the folks that occaisionally is troubled by this bug. I have a general sense that is may be associated with the poly/arc feature.

 

ikim & noj, does your filter include polygons?

No, in this case it is a log filter.

 

I still can't repeat, but Jon can get it to happen each time by clicking on the cancel button while the filter is still running - then the filter dialog will not go away.

 

I can fix this instance by disabling all buttons on the filter dialog as soon as you click on the "go" button.

Link to comment
When I loaded the new version of GSAK, the coordinates for caches that I previously had "locked" were overridden to the original coordinates. (I use the lock feature after solving a puzzle cache to update the coordinates in GSAK before downloading to mapsource and GPSr.)

Strange, I have no other reports of the lock status being removed on upgrade (we are over 3,000 downloads now) and I couldn't reproduce on a test box here. Are you sure you didn't select the "Clear database before loading" option when you loaded the GPX file?

 

Also, If you are changing coordinates in this manner I would recommend using the "corrected coordinates" feature. That way only the coordinates are locked and not the whole cache. By locking the whole cache you prevent changes to the cache in your database that might subsequently be made by the cache owner.

Link to comment
Also, If you are changing coordinates in this manner I would recommend using the "corrected coordinates" feature. That way only the coordinates are locked and not the whole cache. By locking the whole cache you prevent changes to the cache in your database that might subsequently be made by the cache owner.

Yeah, I need to get out of this habit myself. Once you the cache description became an editable field within GSAK, I putting my puzzle cache answers right in the description - easier to see them in Cachemate that way. But on two different occasions in the last week I've searched for a cache that wasn't there anymore because I had locked the record and it didn't get updated with the unavailable flag set by the owner. Need to go through my database and transfer my notes and answers to the User Notes field instead. Imagine, using a field created specifically to hold my notes! What will I think of next?

Link to comment

The "Grab Coordinates" will scan through the descriptions of the caches you select and "grab" likely looking coordinate pairs (Parking for example)

 

If there isn't any of these coordinate pairs in the waypoints you select then no waypoints will be "grabbed"

Clyde, you're the Best! You constantly amaze me with all the improvements to GSAK! I just discovered the "Grab Coordinates" utility in version 6.5.0 and it works great! I love it! Thanks so much for all the fine work you put into GSAK!

Edited by Timpat
Link to comment
It's reproducible for me anyway at this point.  Emailed recipe directly.  Hope this helps the bug overcome its shyness.

I am one of the folks that occaisionally is troubled by this bug. I have a general sense that is may be associated with the poly/arc feature.

 

ikim & noj, does your filter include polygons?

No, I can reproduce the hang with a log filter that takes a few seconds to run. I see Clyde already said that though. I can do it consistently, so I'm hoping it's not some kind of database corruption on my machine that would make it irrelevant for the others that have reported the problem.

 

By the way, the hang doesn't happen the first time my problem filter is invoked/provoked. The first time there's just an extra delay after the main screen refreshes before the dialog dismisses. The hang happens if I don't clear the filter before invoking the filter dialog again.

Jon

Edited by ikim & noj
Link to comment
When connecting to Google Earth throught GSAK, the caches selected are identified by a white square with a white flag.  Can I change that so it as the cache type icone?

Yes :( , one GSAK user has written a macro that will do exactly this.

 

There were a few minor issues and it would only work under version 6.5

 

I think everything has been resolved now so when I get a moment I will add this macro to Http://gsak.net/Macros.php

Now available.

 

The macro is called ge.txt and can be downloaded from Http://gsak.net/Macros.php

Hy Clyde,

 

First, for your information, since yesterday, when I try to click on your macro link, I get a message that says that the page requested cannot be shown. Just tried the same thing from PC at work and it does the same thing. As for this new macro, I'm not a macro type guy so here is the question, this is a macro by itself so when I connect to Google Eath using the GoogleEarth macro to show the caches I filtered out, how does this new macro goes to work. I mean do I have to copy paste this macro into the GoogleEarth macro. Boy, I hope my question is clear :wacko:

Link to comment

The link is http://gsak.net/Macros.php . I'm not sure why the other one didn't work...uppercase "H"?

 

The macro is a script that is run from within GSAK...so (if I understand your question) you shouldn't have to do anything special within GoogleEarth (disclaimer: I haven't looked at or used the macro in question, so I may not necessarily be giving you all the information you need).

Link to comment

I finally tried the My Finds Pocket query and when I imported it into GSAK all of our user notes were deleted. I didn't notice this until AFTER we had backed up the data base so we can't get the notes back.

 

We use the notes a lot on puzzle caches, Virtuals and multis and now we have lost all that info.

 

Did anyone else experience this using that particular PQ? Is there a setting in GSAK that would prevent it from happening again?

Link to comment

 

The macro is a script that is run from within GSAK...so (if I understand your question) you shouldn't have to do anything special within GoogleEarth (disclaimer: I haven't looked at or used the macro in question, so I may not necessarily be giving you all the information you need).

Well, I can't figure out how to have it working. Of course, if you run the GE.txt macro by itself, it will open Google Earth showing all the caches you have in GYSAK or only the ones resulting in a filter search, with the caches symbol. But, if I run a first macro like this one (which allows you to see only the cache you highlighted in GSAK)

 

" $GEMacro=$_Install + "\Macros\GoogleEarth.txt"

MacroFlag Type=Clear Range=All

MacroFlag Type=Set Range=1

Mfilter if=$d_MacroFlag

Macro File=$GEMacro

CancelFilter"

 

How can you run the GE.txt macro at the same time so it shows the cache type? Can a macro be merge into a second macro so it only makes one macro?

Edited by Nomade
Link to comment

 

The macro is a script that is run from within GSAK...so (if I understand your question) you shouldn't have to do anything special within GoogleEarth (disclaimer: I haven't looked at or used the macro in question, so I may not necessarily be giving you all the information you need).

Well, I can't figure out how to have it working. Of course, if you run the GE.txt macro by itself, it will open Google Earth showing all the caches you have in GYSAK or only the ones resulting in a filter search, with the caches symbol. But, if I run a first macro like this one (which allows you to see only the cache you highlighted in GSAK)

 

" $GEMacro=$_Install + "\Macros\GoogleEarth.txt"

MacroFlag Type=Clear Range=All

MacroFlag Type=Set Range=1

Mfilter if=$d_MacroFlag

Macro File=$GEMacro

CancelFilter"

 

How can you run the GE.txt macro at the same time so it shows the cache type? Can a macro be merge into a second macro so it only makes one macro?

I think you are getting confused by the fact there are now two Google Earth macros:

 

GoogleEarth.txt - simple macro, shows white flag only.

ge.txt - complicated macro, shows cache type.

 

So taking your example above if you wanted just see the current cache using the "complicated" version that shows the cache type then $GEMacro must be set to ge.txt

 

So assuming you downloaded the ge.txt macro to the Macros folder of the install folder of GSAK:

 

$GEMacro=$_Install + "\Macros\ge.txt"

MacroFlag Type=Clear Range=All

MacroFlag Type=Set Range=1

Mfilter if=$d_MacroFlag

Macro File=$GEMacro

CancelFilter"

 

You could of course alter the ge.txt macro directly to include this code. However, I have done it this way to insulate against future changes. The problem with changing the macro directly is that if a new version (with some whiz bang feature) is published on the web site, you then have to figure out how to integrate your changes with the new version all over again.

Link to comment
I finally tried the My Finds Pocket query and when I imported it into GSAK all of our user notes were deleted. I didn't notice this until AFTER we had backed up the data base so we can't get the notes back.

 

We use the notes a lot on puzzle caches, Virtuals and multis and now we have lost all that info.

 

Did anyone else experience this using that particular PQ? Is there a setting in GSAK that would prevent it from happening again?

I tried loading my all finds PQ into my finds database and all the notes were left in tact.

 

However, if you take the option to clear the database before loading then this setting will cause you to loose all your notes:

 

cap66.png

Link to comment
I finally tried the My Finds Pocket query and when I imported it into GSAK all of our user notes were deleted. I didn't notice this until AFTER we had backed up the data base so we can't get the notes back.

 

We use the notes a lot on puzzle caches, Virtuals and multis and now we have lost all that info.

 

Did anyone else experience this using that particular PQ? Is there a setting in GSAK that would prevent it from happening again?

I tried loading my all finds PQ into my finds database and all the notes were left in tact.

 

However, if you take the option to clear the database before loading then this setting will cause you to loose all your notes:

 

cap66.png

Following on ......

 

I forgot to add that if you have not turned off the automatic backup feature in GSAK (Tools=>Options=>General) then you have the 5 most recent backups kept in the backup folder of GSAK

 

cap67.png

 

These backup files are called GSAKAuto1.zip .... GSAKAuto5.zip

 

So I would immediately turn off the backup feature (so you don't loose any of them) and try restoring GSAKAuto1.zip (most recent) and then down to GSAKAuto5.zip (oldest) and stop the restore process when a backup restores your notes.

 

When finished remember to resume automatic backup

Edited by ClydeE
Link to comment

Since we're on the subject of backups...

 

I have a general GSAK question which I've wondered about for a long time. I have about 10 different databases set up in GSAK with about as many Pocket Queries coming in to populate them. I'm always concerned about dropping a Pocket Query into the wrong database, thus polluting the contents of that database (i.e. dropping my "Home" PQ onto my "Found Caches" database).

 

If I were to inadvertently do this, will a backup restore my database the way it was? I've rarely messed with the backups, so I'm not even sure I'd know how to fix the problem if it happened.

 

Jamie

Link to comment
Since we're on the subject of backups...

 

I have a general GSAK question which I've wondered about for a long time. I have about 10 different databases set up in GSAK with about as many Pocket Queries coming in to populate them. I'm always concerned about dropping a Pocket Query into the wrong database, thus polluting the contents of that database (i.e. dropping my "Home" PQ onto my "Found Caches" database).

 

If I were to inadvertently do this, will a backup restore my database the way it was? I've rarely messed with the backups, so I'm not even sure I'd know how to fix the problem if it happened.

 

Jamie

Yes, backups will restore your database to the exact image at the time they were taken.

 

The Automatic backup will take a copy of all your databases. However, when you do a restore you have the option to select the database(s) you want to restore.

 

You can also do a manual backup at any time (File=>Backup) and this is a good way to transfer data from one computer to another, or just take take a "snapshot" of your current databases at a given point in time.

 

Backups also include your settings (filters, views, sticky dialog settings, etc) and on restore you can select to restore databases or settings or both.

Link to comment

How do you go about setting up a new database and then pulling individual waypoints out of the Default database and placing in the new one? The ultimate task I am trying to do is create a map of an area in Mapsend Topo that has only certain waypoints on it. I dont want to put my entire database on this map. Any help/pointing in the right direction would be appreciated. This is just a part of both GSAK and Mapsend I have never messed with before.

Link to comment
How do you go about setting up a new database and then pulling individual waypoints out of the Default database and placing in the new one? The ultimate task I am trying to do is create a map of an area in Mapsend Topo that has only certain waypoints on it. I dont want to put my entire database on this map. Any help/pointing in the right direction would be appreciated. This is just a part of both GSAK and Mapsend I have never messed with before.

Use the "Database=>Move/Copy Waypoints..." to copy waypoints from one database to another.

 

Just set a filter in the source database of all the waypoints you want to copy over.

 

However, from what you describe I can't see why you need to create a new database to do this.

 

Just set a filter in your default database of the required waypoints, then do the export to Topo. All exports respect your current filter so only those waypoints will end up in Topo.

 

If the real issue is trying to select the waypoints to include in your filter then please see item 8 of the GSAK FAQ in the help file or online here

Link to comment

I've just started geocaching and downloaded and experimented with Gsak this week. So far I'm getting it figured out and it's working great. I have one request, though, would like to see a USB option available for Magellan GPSr's in the next release. Or, is it there somewhere and I'm missing it?

 

Thanks! :)

Link to comment

I've had a start-up macro that has run fine the last few releases. It basically checks my mail, improts new PQ's and sorts them as I designate. All of a sudden, I'm getting the following error midway through the macro running:

 

gsak_error.jpg

 

I hit OK and then viewed each DB to 'update' them. I then ran the macro again. Same error. I restarted GSAK. Same error occurred. I can't seem to see what I'm doing wrong. Any ideas?

Link to comment
would like to see a USB option available for Magellan GPSr's in the next release.  Or, is it there somewhere and I'm missing it?

It's done this for a long time and fully support Explorist (both geocache and user poi) and Meridian models. See: http://gsak.net/help/hs8700.htm

I'm not trying to put it on a SD card, I just don't want to have to scramble around the back of my tower to plug in a serial cable when I have the adapter cable to be able to just pop it into my USB hub on my desk. Just a convenience thing. The Setup for Magellan GPSr's doesn't have the checkbox for USB, as the Garmin one does. For now I've left the serial cable plugged in, so it's not a big problem, but I've been told that downloading maps takes a seriously long time with serial, so I'll have to pull it to plug into the USB adapter for that. Would like to avoid switching back and forth.

 

Thanks! :)

Link to comment

Since I can't think of any Magellan receiver that has both USB _and_ serial and you didn't find the answer that it supports both very satisfying, I need to know exactly what receiver you're using to clarify the above.

 

The referenced link explains how to write to Explorist via USB - either SD or internal memory and how to write to a Meridian SD card.

 

If what you're using is a serial port (i.e. a Meridian with a serial cable plugged into a USB-based serial port) then from the viewof GSAK (indeed, any other program) it's not USB - it's serial and the instructions at http://gsak.net/help/hs8100.htm apply.

Link to comment
I've had a start-up macro that has run fine the last few releases. It basically checks my mail, improts new PQ's and sorts them as I designate. All of a sudden, I'm getting the following error midway through the macro running:

 

<snip>

 

I hit OK and then viewed each DB to 'update' them. I then ran the macro again. Same error. I restarted GSAK. Same error occurred. I can't seem to see what I'm doing wrong. Any ideas?

This error should only come up when you are using a move/copy where the destination database has not yet been opened under version 6.5

 

What this implies is that your macro is doing a move/copy to a database that has not yet been opened under 6.5

 

Take a look at your macro and check every move/copy line you have in it and make sure you have opened each of the corresponding databases at least once before running it.

Link to comment
I tried sorting my database by OwnerID.  The sort isn't quite right,  it thinks 1000010 is less than 10124

 

<snip>

 

Not sure how often I will use this.  Would it be hard to fix?

I know it doesn't seem to look right but as this field is actually a string (as per the Groundspeak name space), that is the correct sorting sequence.

 

If it were strictly numeric then it would be in the numerical sequence you would expect, but I don't want to change that column to be strictly numeric.

 

As GSAK allows for other GPX files to be loaded (not just from Groundspeak), some may contain Id's that are not numeric.

Edited by ClydeE
Link to comment
I tried sorting my database by OwnerID.  The sort isn't quite right,  it thinks 1000010 is less than 10124

 

<snip>

 

Not sure how often I will use this.  Would it be hard to fix?

I know it doesn't seem to look right but as this field is actually a string (as per the Groundspeak name space), that is the correct sorting sequence.

 

If it were strictly numeric then it would be in the numerical sequence you would expect, but I don't want to change that column to be strictly numeric.

 

As GSAK allows for other GPX files to be loaded (not just from Groundspeak), some may contain Id's that are not numeric.

 

this is because, as Clyde said - it is an alpha sort (not numeric)

 

you can make it come out "right" be editing and adding leading zeros so all entries are the same length.

 

not likely, but that's the drill - been there done that -

 

cc\

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...