|GSAK (Geocaching Swiss Army Knife)|
Rewrite of hints section in HTML.
Prior to V7, in Tools=>Options=>HTML you had the option to "display hints on separate page". This was implemented so as not to "spoil" the cache by immediately being able to see the hints. I regret adding that option as it causes problems with depth levels in plucker and it also means another file has to be generated.
V7 sees a rewrite on how hints are now handled by GSAK in the HTML
Basically, I have removed the "show hints on separate page" option and replaced with "Decode hints". This now means that all GSAK generated HTML is always only one file. You can set this option for split screen and offline viewing via Tools=>Options=>HTML, and there is also an overriding option when you select File=>Export=>HTML
Rewrite of XML parser.
When first writing GSAK, the Groundspeak GPX files would crash the XML parser I was using. With no other alternative at the time I wrote my own custom parser (in retrospect not a really good decision) to get around this. Unfortunately, over time. weaknesses have been exposed in the "home grown" parser and I finally decided to convert to a *real* one.
This ended up being a way bigger change than I expected. Not quite as bad as the conversion from the old to new macro engine, but certainly a lot of code needed changing.
I forgot how much "custom" code I had in my home grown parser (especially for non gc.com formats like Terracaching, dashpoints, GC Australia, etc) and it all needed to be converted and tested.
This is one of those changes I should have done long ago (too busy chopping wood to sharpen my axe) and will bear fruit for me later down the track. The code is much cleaner (better for debugging problems), any valid GPX/XML file will now parse correctly (it really was a bit of a lottery before), and adding support for other formats is now a lot easier.
Unfortunately from a user point of view you will notice very little difference and may well ask "if it ain't broke, why fix it?". I ask you to indulge me on this one, keeping in mind the long term view for GSAK and its continued survival.
 - I am embarrassed to admit I had some really bad *kludges* in there to make some GPX files read correctly.
 - Testing would indicate there is a slight "speed" hit (because of all the extra code being executed by the *real* XML parser) but I wouldn't say it is significant.
Changed export order to current sort sequence.
For the life of me I can't figure out why, but prior to V7 just about all the exports sort your data by waypoint code before generation. This means your application receives the data in waypoint code sequence rather than your current sort sequence. It has been pointed out to me that his is rather odd, and I have to agree. I think this has not been reported too much in the past because most applications sort the data in some default sequence anyway, so you don't notice.
TomTom export converted to use GPSBabel.
When I first supported the TomTom export, GPSBabel could not do this format. Previous versions have been using the command line utility provided the makers of TomTom to generate the ov2 files. I have been meaning to bring this one back to GPSBabel for a while, so here it is.
HTML export now uses cache code if it generates a valid file name.
Version 6.x generated HTML file names with just a sequential number, rather than the cache code. The reason being that the code could contain characters that would generate invalid file names. There were quite a few users that did not like this, so this change is an attempt to placate them. Basically it is a compromise where by GSAK now checks the waypoint code for any characters that would generate an invalid file name. If said characters are found then the HTML file generated is just a sequential number, otherwise the generated file is the same name as the cache code. For the majority of users that only deal with GCXXXX codes this means that all files will revert back to having the file name the same as the Cache code.
Simplified custom export.
The custom export (File=>Export=>Custom) is a bit of a misnomer. It was mainly set up with the intention of allowing you to run GPSBabel with a GPX file as input, so you could generate any of the output formats supported by GPSBabel. However, you are not limited to just exports, you don't have to process a GPX file, and you can actually run any program you like - not just GPSBabel. Anyway, back to the change in this release. While looking at this dialog to add the new "maximum waypoints" field etc, I noticed that for the generation of the GPX file it should really support all the options provided by "File=>Export=>GPX". I noticed how much duplication this would mean and how easily the whole dialog could be made just by letting you select a GPX export "setting" if you wanted to first generate a GPX file. Unfortunately this does mean that it will now "break" any exports you may currently have in a macro that uses the custom export with a GPX file, but it shouldn't be too hard to track them down and convert to the new format.
Saved setting with the name of <macro> are now just copied to the clipboard.
This has been simplified to be consistent with other options of this nature. I found the previous behaviour of showing a prompt and having to generate to a file as overkill and actually counter productive.
You can have a smart name override in GSAK (see Waypoint=>Edit) which allows you to enter a smart name and not have GSAK override it with its own calculated one. However, there was no way to set or test the "override flag" in the macro language. This variable fills that void.
CacheMate conversion now shows all messages
GSAK uses CMConvert to generate the Palm .pdb file for Cachemate. This utility generates messages when converting and currently if there are too many messages they don't all fit in the GSAK message box. The message box has been changed to a memo box, so you can now scroll within the memo box to see all messages.
Complete removal of the old macro engine
The old macro engine code has now been completely removed from GSAK. So adding the comment "#Macroengine1" has no special meaning in your macro code (it will just be treated as a normal comment). For those not aware, this special comment was allowed to be placed in any macro to force it to use the old engine - thus giving users time to convert over to the new macro engine. This also removes some of the constraints in the current macro language.
Double quotes fidelity now preserved
Previously when you used special tags in a macro or database variables in a command (not function - all functions currently preserve double quotes), double quotes would be stripped from the data. Double quotes are now preserved in all macro functions, variables, and special tags. For example, take a cache with the name of:
Three "wise" men
Before this change the following code would produce this result:
After this change it should now display:
Macro command parameters can now be in any order
Removing the old engine enabled the code to be changed such that macro parameters can now be given in any order. So the following code is now valid, but would have crashed your macro before, because the parameters are not in the exact sequence as given in the help file:
Input Varname=$data msg="input some data"
Basically it just means you now only have to get the parameter names correct, as they can now be in any order you like.
Note: This change only applies to commands (because all parameters are named). Functions have positional parameters only, and hence must be given in the exact order as shown in the help file.
Changed command syntax Mfilter if= to Mfilter expression=
If= is still supported for backwards compatibility. The new syntax was introduced mainly to allow users of external code editors that have syntax highlighting and code folding to correctly identify the IF and corresponding ENDIF commands
Copyright 2004-2014 CWE Computer Services |