[Touch Diamond, MDA Compact IV General] low.flying.pigs:
Hello Hello Blaustein / Klaus,

In brief response to your comments:

Thank you for the explanation. In summary, theoretically there is nothing inherently wrong with a nearer usable point. Potential GPS inaccuracy and error which varies dependent on device and an assortment of other variables, means without an additional margin of safety, less than 100m ahead is potentially unreliable.

Most users probably do not use live logging. Of those that do, most probably turn off live logging when finished, and therefore currently have to select an interval on every usage anyway. Those that have live logging routinely enabled are therefore probably a significant minority. No users of any type are realistically going to be genuinely inconvenienced by setting an interval on a single occasion any more than they already are, as user effort involved is trivially insignificant at most, and many will probably select something other than what they currently use anyway as previously detailed.

It was envisaged for ease of use live logging On/Off would be selected by tick box like other options with the interval then set by up/down button (and retained when switched off like other settings) as previously detailed.

Thank you for the explanation. I will pass that on and confirm if it suffices.

That is a potential solution, and perhaps least work to implement. Attached are screen shots of how 'blank image and no text', 'blank image with description', 'blank image with unavailable', and 'image with unavailable' appear, to aid consideration. Each combination has merit. For a number of reasons, I agree it is best to retain buttons in order, having considered the alternative which is not without merit, but raises some additional issues.

As GCC already reassigns buttons at the bottom of screen dependent on working state, it was apparent to myself it would not be overly complex to implement the proposal. Indeed it was not and was rapidly acomplished.

It may be more work to make the feature optional, and integrate with existing confirmation functionality, but again ought not to be overly complex or difficult to acomplish for a talented software engineer familiar with the source code.

Confirm 'Pause' and 'Stop' becomes

Confirm 'Pause', 'Stop', 'Exit' and 'Shutdown' shortened to 'Confirm Actions' or similar.

The primary purpose of the Exit functionality is, on a dedicated device where the primary usage is GCC, to remove interaction in normal everyday usage with Windows Mobile entirely. From initial power on, everything including device shutdown occurs within GCC. It was envisaged the exit button functionality option would combine eventually with 'auto load GCC' when the device powers on, and the option for this will be a tick box 'Dedicated Device' or similar, and further features switched by that option, will be incorporated as required towards that objective.

The dedicated device essentially ceases being a basically obsolete Windows Mobile Smart Phone or similar and becomes literally a fully functional GPS Cycle Computer. Later Windows Mobile devices lend themselves particularly well to this purpose, but all are capable, and lower specification devices will remain functional as any feature they cannot readily support will be optional and not affect them adversely.

'Dedicated Device' being optional, will not effect non dedicated device users.

Features desirable to dedicated and non dedicated device users will be available to both.

It is important to recognise realistically, dedicated devices are perhaps how GCC is actually used by at least a significant number of users, if not the significant majority. Probably relatively few users now continue to use the same device as their main mobile phone etc as was the case when Windows Mobile was at it's peak. This trend, whatever the current situation, is likely only to increase in the future hence the importance of this now before more users are lost.

The GCC project will be on a much firmer footing for the future given the irrelevance of the underlying Operating System and it's developmental status which can only be positive for the GCC project, and something all users should to be supportive of.

Regarding any 0.1~0.2 second delay, in context, it is approximately equivalent to the average blink of a human eye, with some sources stating it takes longer to blink, between two and four times longer. This near imperceptible delay would realistically go unnoticed and cause no genuine inconvenience to any user.

There is scope potentially for options to be optimised in a number of ways if cumulative delays are actually an issue. In comparison to other Windows Mobile applications, GCC actually loads very quickly, and given the number of options, far quicker than would be expected if each caused a 0.1~0.2 second delay.

low.flying.pigs