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

Many thanks for 4.11beta7. Appreciated as always.

Regarding the points to consider:

As the reordering of the buttons was to group the most used features (for normal users, in normal usage, i.e. the majority) at the top and related features together, Exit probably is correctly located upper right. The behaviour of the menu currently displaying in the scroll position where it was last displayed was considered prior to proposal as it somewhat breaks the purpose of the reordering, The solution is to disable the behaviour , as you state 'reset the menue shift, that means line 1 is always visible on menue activation'.

As the second phase of the button reordering development, it was envisaged user configurable button placement could be implemented to cater for the minority the existing default does not suit. This perhaps can be most easily done by enabling user configuration of a .txt file or similar. Users requiring such a feature should have no difficulty with this. A full GUI solution can be implemented if general user demand arises, or if not overly difficult to do so in the first instance.

Many thanks for implementing this, and as an option which it should remain, from myself and on behalf of the group.

Left or right positioning was considered prior to proposal. Right has merit as you state and was recognised. The main deciding factor for left was simply because it's function already substantially changed dependent on state, and the usual action after ending logging was to exit and shut down, not enter the menu. Access to menu by tap and hold, as when the left button is 'Map' when logging, remains available if required, which inherently dismisses 'Exit', as does 'Start' and 'GPS On' if wishing to log again.

Another reason was this was thought to be the path of least resistance to implementation, bearing in mind there would undoubtedly be resistance, undoubtedly from someone that had no need of the functionality, would not be using it and therefore not even be affected by it, as indeed did turn out to be the case, as indeed unfortunately it invariably does. What a shame such a thing had to be considered.

Please do make the change to right position exit button, reverting the menu button back as was in beta 6.

This completely seperates Menu and Exit / Shutdown functionality further negating any possibility of any 'accidents' and facilitates the second phase of 'exit button after stop', device shutdown, part of a range of features for dedicated device users.

Right Position Exit Button becomes:

Single Press - Exit

Press and Hold - Device Shutdown (to be implemented, reasoning as previously detailed)

Ordinary users in normal usage, once GCC is configured as required, probably do not access Options routinely thereafter at all, instead only to make occasional changes.

A possible exception to this are users of Live Logging, which are possibly a minority of users, and can be addressed better differently as below.

The Recall buttons in any event have always provided ready access to three different additional stored configurations, making four configurations in total, catering potentially to some extent, for any unusual non standard usage. One example is multiple different map download sources / folder locations. Using Recall functions for that and any other frequently used configurations is considerably easier than using Options etc each time.

The Microsoft Windows Style Guide affirms that Options would often be positioned as it is now.

Live Logging:

If activated, currently when commencing logging, the message is displayed

'Live logging is activated, proceed?' [Yes] [No]

Selecting 'Yes' logs and uploads live logging, selecting 'No' does neither.

Changing this to:

'Upload Live Logging?' (or similar text) [Yes] [No]

Selecting 'Yes' logs and uploads live logging, selecting 'No' logs only without live logging.

This enables the user to leave live logging configured under options, and select at the point of logging whether to log live as well. When not wishing to live log, just selecting 'No' is considerably more user friendly than 'No' > 'Menu' > 'Options' > 'Live Log' > 'Off' > 'Main Screen' > 'Start'.

Live Logging:

90 - Could not establish a connection to the server!

This issue persists. Further testing shows the following:

Deleting the existing GpsCycleComputer.dat to reset GCC and start afresh made no difference.

Configuration of privacy settings at www.crossingways.com made no difference.

There are no general internet connectivity issues, everything else works normally and satisfactorily.

ping www.crossingways and tracert www.crossingways.com results are both inconclusive since they can be disabled server end for security purposes.

There is at least some connectivity to www.crossingways.com. Within GCC verify password returns '00 - Credentials verified!' and Live Logging functions, showing in the Info section of the main screen 'livelog ok'. Live log position can be seen on www.crossingways.com

The .gcc always converts fine to .gpx. Errors are encountered after 'Do you want to upload GPX file' and selecting yes as below.

There appears to be two types of error, some form of connectivity issue which has always been present, and something introduced by Data Array Size options.

If GCC up to 4.11beta2 (last version before Data Array Size options introduced) or 4.11beta3 - 4.11beta7 with data Array Size 4k or 8k, using any .gcc file:

In this instance, the error '90 - Could not establish a connection to the server!' is displayed. It may be simply that dependent on the starting point and route through the internet to the CrossingWays server in Austria, the connection simply times out as uploading a file is more data than a 'verify password' or 'live log'. This may explain why it works for some dependent on their location and ISP and not others. Perhaps extending the time out in GCC if possible may resolve this.

If 4.11beta3 - 4.11beta7 with Data Array Size 16k or more, .gcc files are as above, up to undetermined file size no greater than 129Kb, which converts with GCC to a .gpx of 320Kb:

In this instance, GCC crashes with an unexpected error, detailed as an Out of Memory Exception.

Actual physical memory available is abundant.

Nothing else to date has been observed or confirmed as being adversely affected by Data Array Size. Ordinarily it is permanently set at 256K.

See attached CrossingWays Error.zip

Map Screen - Missing Tile Infill Feature:

The issue of 'black lines' and lines between tiles' has been mentioned before, but not in detail. These are my observations resultant from testing claimed lack of smoothness and fluidity with 'draw map while shifting' which only now have I had time to compile and submit. These are provided should they assist with resolving the issue.

Contrary to the adamant belief of some, this confirms the key and critical importance of the content of the users specific map folder in determining whether primary or secondary effects are observed, and that the map folder cannot be readily recreated without specific and exact information of what tiles are present, and not present, in addition to which would be required the Default Zoom.

When a map tile is missing, not always and only in some circumstances, what appears to be a 'line' can be observed between the missing tile and surrounding present tiles, which is coloured black unless 'White Background' is selected from Options > Map Screen

The effect can seem random, however, it is consistently reproducible.

Whether or not this is observed seems to depend on combinations of:

Specific tile that is missing.

Specific zoom level of missing tile.

Specific positioning of the map on screen.

Specific 'Default zoom [radius in m]' selected from Options > Map Screen

Possibly other as yet undetermined factors.

From observation, the 'line' seems actually to be a 'gap' which varies in width dependent on the above, between not visible (0 pixel width), thin (1 pixel width estimated), and thicker (2 pixel width estimated). Very careful observation, the gap seems to displace the affected tile in the opposite direction, i.e. gap top displaces down, gap left of tile, displaces right.

These effects can be observed whether 'draw map while shifting' is enabled or not (except in 4.10 pre implementation of it), but is easier to observe with it on, simply because the map is always visible.

Since these primary effects are not observed when tiles are present, only when missing, and only when the 'infill missing tiles with nearest available lower zoom level tile' feature is present, in 4.10 and 4.11beta3 to 4.11beta7, it would seem confirmed that feature is the cause of the issue. (4.11beta1 and 4.11beta2 did not have the feature working, creating a different effect, not to be conflated)

The feature seems to cause other secondary effects (there may be others):

Disruption of the smoothness and fluidity of 'draw map while shifting' if tiles missing, worsening the more are missing.

Momentary tile effects: If tiles are missing, other tiles that are present are blank, then appear, or display lower level, then appear.

This seems at least in part due to the feature requiring additional processing being done, in addition to any bugs within the feature.

The symptoms of these secondary affects can therefore also arise in different ways, and compound them, where device resources are limited, or being used elsewhere on background tasks etc.

With the attached 'proof of concept' map, the primary effects are consistently reproducible and readily observable by going to zoom level 9 and moving the map around. Secondary effects can be spotted but less easily by zooming and moving the map until observed.

Disabling tiles as below (by appending filename, as supplied) causes primary effect if Default Zoom 600 or 900 (other values may cause effect).

9/254/166.png and / or 9/255/166.png and / or 9/256/166.png

Enable / Disable tiles to see variations (other tiles may cause effect).

Change zoom Default Zoom to 300 and effect is no longer observed (other values may cause effect).

See attached Map Tile Infill Error.zip

low.flying.pigs