database problems on CF card
-
I'm developing a CE data entry program using eVC++ 3.0 with MFC. It uses a memory-mapped database. The database file can reside pretty much anywhere on the CE device, but I've been recommending that users (testers) keep it in non-volatile memory such as a CF card for data safety. Well that sure backfired! Here's the problem: If the device (Pocket PC 2002 so far) is suspended then resumed while the program is running, all of the pointers to the database on the CF card seem to get scrambled, and point to garbage within the database. This does NOT happen if the database resides in the device's onboard memory, even after multiple suspend/restarts. Anyone know what's going on with the CF card? Right now the only work-around I can think of is to detect when the device is being suspended, and clean up/close the database, then re-initialize everything when the device is resumed. However, I can't find how to detect either suspend or resume. Aaaaaaaaaargh! majoob
-
I'm developing a CE data entry program using eVC++ 3.0 with MFC. It uses a memory-mapped database. The database file can reside pretty much anywhere on the CE device, but I've been recommending that users (testers) keep it in non-volatile memory such as a CF card for data safety. Well that sure backfired! Here's the problem: If the device (Pocket PC 2002 so far) is suspended then resumed while the program is running, all of the pointers to the database on the CF card seem to get scrambled, and point to garbage within the database. This does NOT happen if the database resides in the device's onboard memory, even after multiple suspend/restarts. Anyone know what's going on with the CF card? Right now the only work-around I can think of is to detect when the device is being suspended, and clean up/close the database, then re-initialize everything when the device is resumed. However, I can't find how to detect either suspend or resume. Aaaaaaaaaargh! majoob
majoob wrote: Right now the only work-around I can think of is to detect when the device is being suspended, and clean up/close the database, then re-initialize everything when the device is resumed. However, I can't find how to detect either suspend or resume. I've had the similar problem with power off/on wrt the COM port. I used the following to fix the problem: In my main exe I register a notification handler tied to NOTIFICATION_EVENT_WAKEUP that will be executed every time power is turned on:
CE_NOTIFICATION_TRIGGER nt; TCHAR szExeName[] = TEXT("\\windows\\XXXEventManager.exe"); TCHAR szArgs[] = TEXT("-P"); memset (&nt, 0, sizeof (CE_NOTIFICATION_TRIGGER)); nt.dwSize = sizeof (CE_NOTIFICATION_TRIGGER); nt.dwType = CNT_EVENT; nt.dwEvent = NOTIFICATION_EVENT_WAKEUP; nt.lpszApplication = szExeName; nt.lpszArguments = szArgs; hNotificationHandle = CeSetUserNotificationEx (0, &nt, NULL);Then in XXXEventManager.exe I notify my com-port handler that it needs to reinit itself. In my case, that was housed in a DLL that I could load and reinit, but I guess it could be handled in many ways, even w/o an extra exe-file. Just remember to call CeRunAppAtEvent(PathToYourExe, NOTIFICATION_EVENT_NONE) somewhere when you dont need the notification anymore, otherwise you will never get rid of the notification w/o a hard reset. majoob wrote: Anyone know what's going on with the CF card? I know too little about how the CF port get mapped/mounted to even try to answer that. =) “Our solar system is Jupiter and a bunch of junk” - Charley Lineweaver 2002 -
majoob wrote: Right now the only work-around I can think of is to detect when the device is being suspended, and clean up/close the database, then re-initialize everything when the device is resumed. However, I can't find how to detect either suspend or resume. I've had the similar problem with power off/on wrt the COM port. I used the following to fix the problem: In my main exe I register a notification handler tied to NOTIFICATION_EVENT_WAKEUP that will be executed every time power is turned on:
CE_NOTIFICATION_TRIGGER nt; TCHAR szExeName[] = TEXT("\\windows\\XXXEventManager.exe"); TCHAR szArgs[] = TEXT("-P"); memset (&nt, 0, sizeof (CE_NOTIFICATION_TRIGGER)); nt.dwSize = sizeof (CE_NOTIFICATION_TRIGGER); nt.dwType = CNT_EVENT; nt.dwEvent = NOTIFICATION_EVENT_WAKEUP; nt.lpszApplication = szExeName; nt.lpszArguments = szArgs; hNotificationHandle = CeSetUserNotificationEx (0, &nt, NULL);Then in XXXEventManager.exe I notify my com-port handler that it needs to reinit itself. In my case, that was housed in a DLL that I could load and reinit, but I guess it could be handled in many ways, even w/o an extra exe-file. Just remember to call CeRunAppAtEvent(PathToYourExe, NOTIFICATION_EVENT_NONE) somewhere when you dont need the notification anymore, otherwise you will never get rid of the notification w/o a hard reset. majoob wrote: Anyone know what's going on with the CF card? I know too little about how the CF port get mapped/mounted to even try to answer that. =) “Our solar system is Jupiter and a bunch of junk” - Charley Lineweaver 2002Thanks Jonas, After doing a little research I discovered that its not that the pointers are getting permanently "scrambled" as I first thought, but that it takes the WinCE operating system a few seconds after a resume to reinitialize the card (handles and pointers to the files that were open on the card). It probably depends on the make and model of the card, but my Kingston CF card took right around 5 seconds after a resume to kick in. If I waited those five seconds before entering data then all was well. So, here's what I did in the data entry loop: CWaitCursor wait; m_cFile.GetStatus(m_sFileName, m_rStatus); wait.~CWaitCursor(); Execution stops for 5+/- seconds on the GetStatus line until the card is initialized, then the waitcursor goes away and the user can continue. Once the card is initialized there is no perceptible delay in execution and the user doesn't see the waitcursor. Seems a little kludgy but it works. Anyone see a danger in doing this? majoob