Contents
- Index
Version 7.2 extra notes
Symbol Name support.
For those users that store waypoints other than Geocaching, it should greatly help you to categorize your "other" cache types. I'm sure Geocache users will find this a welcome addition too.
1. You can add the Symbol column to display in your grid via "Tools=>Options=>display"
2. You can filter on Symbols via "Tools=>Options=>General"
3. Global replace of symbols "Database=>Global replace" is supported
4. When sending to GPSr you now have the option to use the "Symbol name" as per the database. If the symbol name in the database is blank, then the corresponding GUI symbol name is allocated
5. I do see an issue when loading GPX files (File=>Load GPX/LOC). That is, you may have set up all your symbols in the database just the way you want them, but then if you load a GPX file from Geocaching.com they will all get updated with "Geocache" or "Geocache Found" (the only two symbols provided in the GPX files from gc.com). To prevent this from happening, I have provided a checkbox which you can uncheck to disable the updating of symbols from the incoming GPX file.
6. Another change to the "File=>Load GPX/LOC file" is the introduction of a "Found symbol". This defaults to "Geocache Found" (The symbol used by Groundspeak to indicate you have found the cache). If the incoming GPX file symbol matches this symbol, then the cache will be marked as found. By making this a user changeable field it paves the way for you to load other GPX files that have a different symbol to indicate found caches. This is also supported in the new "Receive Waypoints" dialog.
7. Another issue I see is when you Generate GPX files. The introduction of symbol support could break the work flow of some users when they generate a GPX files because they may currently depend on the fact that the symbol is always generated as per a Groundspeak GPX file. That is, you only get "Geocache" or "Geocache Found" for the <sym> element in the generated GPX file. I have updated the "File=>Export=>Gpx/loc" file to still behave this way by default. However, should you want to take advantage of the new symbol support and ensure the database symbol is generated for the <sym> element then uncheck this box:
8. Symbols can be updated individually via "Waypoint=>Edit", or directly in the grid (just click your mouse in the cell and start typing)
9. A new database variable $d_symbol has been added to support the use of symbols in the macro language
Added UserSort, SmartName, and LastGPXUpdate to the GSAK extensions
UserSort is read/write enabled. That is, this value will be exported in the GSAK extension section and also updated in the database when you load a GPX file that has been created by GSAK. SmartName and LastGpxDate are write only and provided solely for other applications that read GSAK generated GPX files. This is because these fields are calculated internally and we don't want the incoming values in the GPX file for these values overriding the database values.
Default font set to "Microsoft Sans Serif"
For what ever reason the Delphi default font for all forms is "MS Sans serif". However, I have found that this font will not correctly display some characters (the "emdash" being a popular culprit). In the past I have been reluctant to change the default font in GSAK because it would make everything look different. However, I just recently discovered that "Microsoft Sans Serif" has the identical shape and look as "MS Sans serif" but with the added benefit of being able to display a larger number of characters.
New method of loading child waypoints
The previous load routine of child waypoints was using a "DOM" method to read the XML. Not a problem with small files, but recent "alternatively generated gpx files (benchmarking for example)" have literally thousands of child waypoints, and it was causing memory issues. That is, the "DOM" method requires that the whole document be in memory to process it. To make matters worse the actual memory being consumed was way more than the raw file size (I guess it must internally set up work areas and buffers etc). One of the larger files (a 200mb raw file, with 17,000 child waypoints) was causing GSAK to consume more than 1GB of memory to process.
I have now converted the routine for loading child waypoint to use the "SAX" method. This is event driven and does not require the whole file to be in memory to process. This will allow GSAK to process very large files, yet use only a small amount of memory (usually just a 1mb buffer)
Deprecated use of $xxx variable to populate the ComboBox "Values"
The combobox control currently has two variables associated with it. One for the setting and returning the selected value, and the other for "values" which is the list of options for the combo box. This was an oversight and I am now bringing this control into line and deprecating the use of a variable for "values". When I introduced the CheckListBox control I purposely moved away from having a separate $ variable to populate the values. You either populate the values directly in the properties dialog, or use EditForm() to update "values". The Combo box now works the same way. The added benefit is that you can now populate the "values" for a combobox in the properties dialog, which means you don't have to set a variable outside the form. Using a $ variable to populate the "values" for a combobox will still be supported for backwards compatibility.
Macro path no longer required
You no longer need to enter the fully qualified path name to your macro file if the file exists in the gsak default macro folder (which is currently the sub folder "Macros" within you install folder of GSAK).
Macro "Lockdown"
GSAK is not a great "Multi tasker" and many error dumps are caused by users taking options in the GUI while a macro is running. This new feature will "lock down" the main GUI while a macro is running so it should not be possible to start up another task while a macro is running.When running a macro all tool bar buttons will be disabled and a new big red "Stop" button will be added in the middle of the tool bar. This is the only tool button that will be active while a macro is running, and clicking on it will terminate the currently running macro.