[Touch Diamond, MDA Compact IV General] low.flying.pigs:
Attached is a modified 4.12beta15 for Windows Mobile users only (Windows CE users should use standard 4.12beta15) which restores Windows Mobile functionality to that of 4.12beta14 in respect of Minimising the application. In all other respects it is identical to standard 4.12beta15. This is provided in the interim until 4.12beta16 addresses the issue. Details of that below:

Incorrect usage from the outset of the terminology 'App maximized' for what has in fact always on Windows Mobile actually been 'App full screen' has created some difficulties. That terminology in the Context Menu will be changed to 'App full screen' in a forthcoming beta.

On all Windows Mobile Operating Systems, Minimised is when the application is running but not on screen, Maximised is when running and on screen with Taskbar, Full Screen is when running and on screen without Taskbar. No Windows Mobile OS has a Titlebar.

On Windows Mobile, applications ordinarily run Maximised or Full Screen. When Closed, they usually are actually Minimised unless the application implements actual exit, it can be seen in Task Manager / Memory > Running Programs, they are still running. From Task Manager / Memory > Running Programs, they can then be displayed again, Maximised or Full Screen, back to whichever they previously were. Some devices have task switchers to allow easier switching between running programs.

As the below can be readily observed in the Emulated Environments, it can be anticipated a forthcoming beta release will resolve the issue shortly now it has been clearly observed and identified. *

All Windows Mobile OS Emulated Environments - GCC 4.12beta14:

When a button assigned as 'OK / Close' or 'Today' is pressed when GCC is actually Maximised, or when the mislabelled 'App Maximized' is selected and GCC is actually is Full Screen, the device returns to the Today screen.

Windows Mobile 6.5 Emulated Environment - GCC 4.12beta15:

When a button assigned as 'OK / Close' is pressed, if GCC is Maximised, the Today screen is shown. If the mislabelled 'App Maximized' is selected and GCC is actually is Full Screen, there is no reaction from pressing the button.

Windows Mobile 6.0, 5.0 and 2003 SE Emulated Environments - GCC 4.12beta15:

When a button assigned as 'OK / Close' is pressed, whether GCC is Maximised or not when the mislabelled 'App Maximized' is selected and GCC is actually is Full Screen, the device shows if open another application (for example File Explorer), and if not, or pressed again, the Today screen, but with GCC displayed where the Today content should be, as per attached screen grabs.

The OK / Close button is dual function. OK will close and exit an application, Close (X) minimises it as described previously. GCC on the taskbar ordinarily has a Close button (X). It would appear whilst GCC correctly minimises from Full Screen when pressing a hardware OK / Close button, except in the circumstance of the Today screen.

Another way of considering this is that other application upon pressing hardware OK / Close button to 'Minimise'

GCC, other applications become Maximised / Full Screen (whichever they were running in), but the Today screen does not. What actually happens is GCC does not in fact Minimise at all upon pressing hardware OK / Close button, hence why the Today screen cannot be seen.

Ideally, it should not just Minimise, but Minimise to System Tray from where it can be displayed again.

Due to implementation of FormBorderStyle.None; to remove Titlebar in Windows CE, the above is resultant from an unforeseen effect on Windows Mobile. This necessitates some further code to rectify. Two possibilities are immediately apparent, there may be others.

Operating System detection could be implemented and thereby FormBorderStyle.None; would only apply to Windows CE and not affect Windows Mobile.

Alternatively, in form1.cs handling of FormWindowState.Minimized; linked to detection of press of hardware OK / Close button perhaps via CloseReason.UserClosing function would Minimise on OK / Close button press. For sample source code that could be adapted and integrated, and that would also Minimise to System Tray correctly, see here.

* Separately, the above is only observed on devices with hardware buttons under the direct control of the Windows Mobile OS. Where another application, such as a User Interface and or User Experience enhancement, such as HTC Sense, is running and implements functions correctly and has relieved Windows Mobile, this is not observed and buttons work normally resultant from the separate handling by an alternate method.

As no Confirmation prompt is observed when signal is reaquired when the current position is within 1Km of the last position, then either the original issue is resolved, or was not observed in that circumstance in the first instance. If the latter, it would explain why it could not be reproduced.

Ordinarily, if when resuming logging the current position is not within 1km of the last position, it is a necessary design feature of GCC that Confirmation prompt is shown to determine whether the user actually wishes to continue logging in such a circumstance, as it is by no means obvious they actually would.

'Confirm 'Pause' and 'Stop'' whether selected or not, has no effect on Continue log file Confirmation prompt.

As detailed previously, the issues can be resolved with the proposals in post 2161 explained further in post 2164, in brief, by not triggering the prompt in any circumstance unless GPS has been switched off.

Further information to be added.

low.flying.pigs