(PC developers specifically)
The Palm/USR conduit system is designed to allow a hotsync to occur with both native and foreign data. The designers assume that foreign data is in such a format that code will have to be written to implement a hotsync. Therefore, the conduit system assumes that each conduit will be different/unique. And that the data format for each conduit will be different/unique.
The designers of the HotSync system also provide a "backup conduit" which simply transfers raw data, in bulk.
I felt that these assumptions were a bit onerous. They assume that everybody who develops a PC app will be interested and capable of writing a DLL. I didn't think this was a reasonable assumption.
[Aside: To be a "real" Pilot programmer, you have to be conversent in 4 API's (Mac, Pilot, Win32 and ConduitSDK). That's 2 too many for me.]
The Conduit Manager system uses a generic conduit, which can sync any Pilot database on a record-by-record basis. In order to do this, here are my assumptions:
This means that developers on the PC can work at a simpler level. There is no need to learn the entire Conduit management system. On the other hand, we (the PC developers) have to write the code to read and write MAC style numbers, and deal with fixed format records that are created by a foreign app. If you can live with this, climb abord.
In the coming weeks, I will bolster this package with documentation on the file formats, and sample code for the use of the GenCond.DLL and the Generic Conduit Manager.
(hackers only)
In order to write a generic conduit, I had to figure out how to make sure that the conduit gets called by the HotSync system. Using HotSync 1.0, that is not simple, since the HotSync.exe (actually syncmgr.dll) enumerates the databases in the Pilot, and only calls the DLL's that are required to service this list. If the app that the user has requested does not make it onto this enumeration, the DLL will not get called.
To get around this, I install a proxy in the MemoPad conduit, by inserting an ApplicationX registry entry. During the startup of the gencond.dll, I reach back into the Component3 registry entry and execute the memcond.dll first, and then run through the ConduitManager entries.
For each one, the gencond.dll uses the registry information to locate a file and reads it into memory. It then tries to sync up, record by record and creates a new local file. If all went well, the old file is renamed and the new file written.
If you have an application that is running, it will get a couple of DDE messages. Before the file is opened by the conduit, you will get a "application/notify" message command with the string "sync start". You have 1.5 seconds to write the file to disk before the gencond.dll will try to read it.
After the file has been written, you will get a "application/notify" message command with the string "sync finished". You can then re-read the file into the app. [All records will be marked clean, and deleted records will have been purged.] [Look at the source for cbasVw, in Form_LinkExecute.]
In order to locate the files, each time the gencond.dll is executed, it puts an entry in the registry: HKCU/Software/Palm Computing/PilotDesktop/Preferences/LastUserDir ="name of user dir, without trailing backslash"
To locate the data files, simply concatenate a "\DirName" to this string. This should be the same DirName that the user put into the ConduitManager. Examples are "DinkyVw" or "cbasVw".
If you wish to use it, the GenCond.DLL exports a simple little routine to build up multiple backup files.
/*SDOC
Function: MakeBackupFiles
Params: sFileName the name of the target file nBackups the number of backups to keep
Action: The sFileName is used to locate a directory where the output files will go.
If the sFileName does not exist, the function exits with a 0
The current backup files are enumerated and the actual file called sFileName will be renamed to a backup file.
Files which exceed the backup limit are deleted.
Returns: 0 if no file activity took place; usually means that the given file does not exist
Comment: Style 0 backups proceed like
file.txt (original)
file.txt.1
file.txt.2
file.txt.3 ... (note: this destroys the Win95/NT association)
EDOC*/
C/C++ int MakeBackupFiles(const char* sFileName, int nBackups);
VB Declare Function MakeBackupFiles lib "gencond.dll"
alias _
"_MakeBackupFiles@8" (ByVal sFileName as String, _
ByVal nBackups as Long) as Long