Hello Joel, You got me right. Going to suspend either happens when the user presses the power key or the device automatically powers down after the specified idle timeout has been reached.
The way to handle those events is quite tricky and device dependent. Normally, the device manufacturer provides some kind of SDK. The manufacturer of the devices we are developing for provides functions to enable and disable the power key. If the user presses the power key when it has been disabled, the device doesn't go to suspend mode. Instead a window message (WM_POWERBROADCAST with WParam=PBT_APMSUSPEND) is sent and the application has to handle this message (i.e. finishing and blocking disk I/O and powering down the device). When the device resumes from suspend, another message (WM_POWERBROADCAST with WParam=PBT_APMRESUMESUSPEND) is fired. Our application receives that message and unblocks disk I/O. Blocking disk I/O can be done by using a semaphore. Acquire the semaphore before doing any disk I/O and release it afterwards. The component which monitors suspend/resume-from-suspend messages also has to acquire this semaphore before going to suspend and has to release it after the device resumed from suspend and the removable media has been remounted. So suspending and doing disk I/O are mutual exclusive. Keep in mind that waiting for the remount process to complete requires monitoring the device notifications (RequestDeviceNotifications API function). Surely, this whole thing requires a lot of changes to your application. That's why you should follow your idea to move the database file to the internal memory. Greetings, Christian ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
