Here you define your custom fields
Field Name - Field name that will be used to reference this field (Used in the Grid display, Macro language, etc)
Type - Custom fields can be String,Integer,Real,Date, or Boolean. GSAK will try to enforce this type when adding/editing values. If you change the type of a field then the contents of existing data will be converted (best it can) to the new data type.
Scope - Designate the field to appear in all databases, or just the current one only (global vs local)
Sequence - The order the field will display in dialogs (edit custom data, GUI filter, etc)
Default - The default value when a new cache record is added to the database (every cache record must have a corresponding Custom record, which is automatically enforced by GSAK)
Sqlite Expression (Grid display only) - Allows you to enter a sqlite expression, the result of which will be shown in the grid rather than the actual value of this filed. You may then think if this field as a "calculated" field, but note that this calculated value only displays in the grid, no where else. Let us take a simple example. We want to display in the grid the sum of the Difficulty and Terrain. Sure we could create a custom field and then run a macro to update that field with the correct result. However, this method requires that you remember to run the macro *every* time the difficulty or terrain value changes (which could be the result of a GPX load, manual edit, running a macro, refresh cache data via api, etc)
Using this new method, the result is calculated "on the fly" so the result will *always* reflect the most up to date values of Difficulty and Terrain. So for this example we would add the following custom field:
Now if we add this field to the grid display we see something like:
Clicking on the column heading to sort will also sort the grid on the calculated value.
Holding down the "Ctrl" key and clicking on the column heading also respects the calculated value in the output:
Note: Normally, a custom field that uses a sqlite expression would not contain any value in the underlying database. However, this does not have to be the case. The field can be updated with data just like any other custom field - it is just that the value that will always show in the grid will be the result of the sqlite expression. When would you want to do this? - You may not want to show the actual value of the custom field in the grid but you need that field/value to use in your sqlite expression.
The calculated value can be the result of any valid sqlite expression - which of course can include GSAK custom functions. Take another example - you want to show in the grid the distance to the cache from your friend's home. Sure you could set a center point on your friend's place then the distance column would then show your required distance. But in this example I want to see the distance from my home and my friend's home both at the same time.
We add the following custom field:
The full sqlite expression being:
round(g_distance(latitude,longitude,-32.5533293,115.752227,'k'),2) |
The coordinates I have chosen here are random, so obviously you would substitute the coordinates for your friends home here. Also note that I have used the Round() function to round the result to two decimal places (otherwise the result is rather unwieldy) though you could change this to reflect any precision you like.
For more information see this link
Note: When Type = String, you also get the edit box option. Use small for the standard one line edit box which is usually associated with small length strings. Use large when the text for this field is large (notes for example). When set to large you can also set the pixel hight for the data input box (via Waypoint=>Custom data)