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

In brief response:

That is not what was described, however that is what happens if you do that. Upon further testing, while the initial observation is valid, the behaviour is the same as Context Menus elsewhere. The positioning in the lower 12% creates an appearance of a behaviour in some circumstances that is not ordinarily observed, unless you would ordinarily activate a context menu in the lower 12% of the screen. In summary this matter is resolved.

Conversely, there is certainly nothing right with this, it being inherently entirely pointless. There is nothing wrong with what was proposed and it would therefore appear the issue is not the proposal itself, but the task of implementing it. It is a refinement that can be implemented at a later stage as when developmental priorities allow, and this is not a priority, but preventing situations such as this is standard practice and feature in modern software.

Conversely, it would not be necessary to have to change it back in the first instance if the relatively minor adjustment to existing functionality was implemented. It is a refinement that can be implemented at a later stage as when developmental priorities allow, and this is not a priority, but preventing situations such as this is standard practice and feature in modern software.

Unfortunately, similar issues exist with 'clean backround'. 'opaque background' would be better, being accurate, descriptive and thereby self explanatory and intuitive. It does however rely on a users command of English and being familiar with the meaning of the word opaque, whereas 'no map background' suggested earlier is straightforwardly readily understood, the same number of characters as 'opaque' and only one additional character more than 'clean'.

Firstly, GpsCycleComputer.exe, and indeed the entire base files in the installation folder, in comparison to Windows Mobile / Windows CE software for similar purpose, is in no way oversized at present.

Nonetheless the reduction can be achieved, and coupled with benefits that in and of itself may bring, it allows for introduction of further functionality and increased leverage of a devices available resources, the actual reasons that justify why this is worth the effort of implementation.

One method by which significant reduction in size could be achieved, estimated approximately between 161Kb to 220Kb, is by removal of embedded graphics resources, and providing the buttons of the default skin separately, and not compiled within the .exe file. This approach is taken by many applications.

Unless the default skin is actually in usage, it is inherently superfluous when an alternative skin is in use. There may therefore arise some benefit in reduced memory usage when a skin other than the default is in use.

Given GCC already relies on files external to the .exe in order to function properly, and given that in ordinary usage there would never arise a situation where GCC would actually be run absent the default skin folder, no issues would therefore arise, nor need lack of it make GCC either unable to function or unable to be used. Safeguard could be implemented where if the default skin folder was for some reason unavailable, a text description of the button could be in place of it, for example '[stop]' in place of the stop button etc where necessary.

As part of this implementation, the facility to handle more than one folder containing skins would also inherrently be created. These could be selectable as an additional option in Menu > Options > Options screen.

Whilst on the subject of skins: Control of foreground, background, and map text colour could be part of the skin, perhaps handled by a text file therein. If the buttons were available with a transparent background, it would aid those wishing to skin GCC.

Another method by which even further significant reduction can be achived, almost to nothing, involves splitting the existing .exe in to separate managed .dll files utilised and controlled from the main .exe file. The main advantage is not reduced .exe file size, but the reduced usage of GCC's own 32Mb virtual memory slot, and GCC access to vastly increased available memory of the device. This in turn drastically increases the potential and capabilities of GCC. See here. This approach is taken by many applications.

If implemented, changeover to this alternate structure of additional files as above would be handled by the existing .cab installation routine, with betas thereafter replacing existing file(s) where necessary as at present, there for the end user being no difference in this regard.

Whilst on the subject of .cab installation files, as a further compatibility measure for Windows CE device users, in addition to the .cab installation file, the files therein could be provided as a .zip file. Not all Windows CE devices can install .cab, and provision as .zip negates the user needing to extract a .cab and the dependency on the software to do that.

It can be stated any changes would not adversely affect any existing functionality or user.

Further information to be added.

low.flying.pigs