Handling Categories

The Generic Conduit Framework handles categories oddly—it expects that the category data will be stored on the desktop in the same way it is stored in the AppInfo block. Most applications won’t use this strategy, but instead will probably choose to store categories by saving the following:

  • The category name

  • The category ID (a number from 0 to 255, where 128 and above are reserved for categories created on the desktop)

  • A dirty bit (showing that the category has been edited on the desktop since the last sync)

To begin with, you’ll need to notify the Generic Conduit Framework that you’ll be using categories. You can do this in OpenConduit (see Example 16-5) by changing the last parameter in the constructor from the 0 value that signifies that you don’t use categories.

Example 16-5. OpenConduit that supports categories
ExportFunc long OpenConduit(PROGRESSFN pFn, CSyncProperties& rProps)
{
    long retval = -1;
    if (pFn)
    {
        CMemopadConduitWithCategoriesSync* pGeneric;
        pGeneric = new CMemopadConduitWithCategoriesSync(rProps, 
            GENERIC_FLAG_CATEGORY_SUPPORTED| GENERIC_FLAG_APPINFO_SUPPORTED);
        if (pGeneric){
            retval = pGeneric->Perform(  );

            delete pGeneric;
        }
    }
    return(retval);
}

In order to deal with categories, you’ll need to write out the category ID of each record when you write out your file. In addition, you’ll need to write out the categories themselves. Example 16-6 shows a modified StoreDB, with emphasized lines showing the changes that were necessary for categories.

Get Palm OS Programming, 2nd Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.