Now that you have an idea what each of the classes does and which functions you override, it is time to use this information to add syncing to the Sales application conduit. We use these new sync classes for syncing the customer database. We continue to use our own routines that we created in Chapter 12 to upload the orders database and download the products database.
There is also a problem in the implementation of two of the classes: CBaseConduitMonitor and CBaseTable. We use an unorthodox approach, which involves circumventing normal inheritance and copying the classes by hand. We talk about this as part of our discussion of each of these classes in the sample conduit. Other classes are used normally.
This is the class that is based on CBaseConduitMonitor. Let’s look at a problem we have before going any further.
Our customer database doesn’t use categories, but CBaseConduitMonitor expects them to exist. CBaseConduitMonitor’s ObtainRemoteCategories function reads the app info block of the handheld database and causes an error if the AppInfo block doesn’t exist. In the original class, there were two functions that expected information about categories. The first was SynchronizeCategories, which is responsible for syncing the categories. We overrode this routine to do nothing. Unfortunately, a second function dealing with categories was not declared virtual in the original class ...