At this point, I've been able to download every element of a PalmOS record and place it in a field using COM.
I appreciate the fact that this COM approach is well-documented in the PalmOS Sync Suite, and not at all objectionable in terms of relative ease of use. I am inclined to note that the C++ code to which I was originally directed and which produced the results that have been described in prior posts was said to not contain MFC classes by the party who pointed me there. I had stipulated this requirement in the request that resulted in that recommendation. The problems that Builder had were with a .def file generated by the IMPDEF routine. That file included what someone who seems to be fairly esteemed by the Borland user's group (and certainly are by me in terms of some past responses received from them) identified as several "mangled" references to what were probably Microsoft Foundation Classes (MFC) in the .def file that IMPDEF produced from the pre-compiled sync20.dll. (IMPDEF is simple to use and requires only a dll name and a .def file output name. IMPLIB was also used on the sync20.dll in an attempt to get rid of any incompatibility with Builder.) Builder would not initially link with the sync20.dll, which contains functions that the C++ code that I had downloaded from the site to which I was referred did include in terms of a number of function prototypes but which my linker could not seem to identify and perceived as "unknown". It was the sync20.dll, which produced a .def file that included "mangled" references to "unknown" functions. I do not know if the MFC classes were actually used in the base code as I did not review it myself in detail given the linker error. I don't know with certainty if the references to which I previously referred in a .def file produced from the sync20.dll and which I listed in a prior post were "mangled" references to MFC classes as someone else suggested to me. The problem linking seemed fundamental and not one that I could easily get around. I note that recompiling the dll for C and not C++ was recommended at the Borland user group site. Mr. Ben Combee, the PalmOS representative, has referred to accessing the API C function calls directly, and not C++ calls. This makes me wonder if the sync20.dll is compiled for C++ or C, and is, as a result and for reasons that I acknowledge are beyond my present comprehension, not compatible if you don't have the means for a linker to identify the compiled C++ classes that it contains. (I was happy to transition from C to some grasp of what C++ and class structures were all about in the hours I spent after work learning these languages in evening college courses several years ago. The fine points of linking, in terms of linking with code within dll's compiled as C or C++ code and potential impediments due to use of classes compiled within the dll weren't part of those courses, being, I presume, associated with computer science theory on a more advanced level.) I don't want to drag this out, as I seem to have found a solution using COM and VB 5.0, which didn't prove to be the nightmare I had begun to anticipate given the way in which COM seems to be perceived by some. (Maybe that only occurs when it is run on a user's system and OS after a software release!) I am responding to the prior posts not be obstinate or difficult, but merely because there seems to be something missing from conclusions that ignore the following: 1. The conduit code I was using (and had downloaded) was not supposed to contain MFC references. I don't have MFC on my system, and have never used these classes, so I would not be tempted to add them to any code that I employ. Everything C or C++ on my system is made by Borland (C++ 4.5 and Builder 6.0). 2. The sync20.dll file alone was the original source of references to what were identified as "possibly" mangled MFC references in a .def file produced from it. 3. The sync20.dll file was the file that I was advised to recompile as a C file instead of a C++ file by a knowledgeable person in the Borland Builder user group in order to link with it without having MFC on my system. 4. A recommendation from a professional C++ programmer with PalmOS to call C API functions directly that are compiled within the sync20.dll file raises a question in my mind with regard to item 3. (Is the sync20.dll compiled for C or for C++? Also, would the settings on my compiler, for C or C++, have any effect on the ability to link with a dll even if C API functions were being directly referenced by the code I am using? Note: There are still all those question marks created by IMPDEF in the .def file produced from sync20.dll with regard to those "mangled" function names, which are at the core of the problem, given that Builder stops and references those functions when I attempt to compile and link with the sync20.def file as part of the project.) Please keep in mind that this is largely a moot point for me given my present direction with regard to conduit development by means of the COM client server interface. The effort to respond to my inquiry by knowledgeable professionals for whom I have great respect is certainly appreciated. If anyone can include items one through four in an explanation that does not casually dismiss any of these points, I'd love to hear it if only to extend my grasp of the linking process under Builder and C++ and why a dll compiled for C would link with Builder but a dll compiled for C++ would not. In the process my conduit construction capabilities with regard to PalmOS (in the long run, as COM under VB 5.0 is very appealing right now) might be expanded. Best Regards, and Thank You. ----- Original Message ----- From: "Jim Cooper" <[EMAIL PROTECTED]> Newsgroups: palm-dev-forum To: "Palm Developer Forum" <[email protected]> Sent: Thursday, December 08, 2005 8:56 AM Subject: Re: Linker Error > > > If you use just the SyncManager API (the raw C API), you should be able > > to use the sync DLLs. If you use the C++ classes, you'll have MFC > > dependency issues, since the classes are derived from MFC classes. > > Yes (I did try and explain that at one point, but I don't think I was clear > enough :( ), and I think Del is confusing the two. > > > Cheers, > Jim Cooper > > __________________________________________ > > Jim Cooper [EMAIL PROTECTED] > Skype : jim.cooper > Tabdee Ltd http://www.tabdee.ltd.uk > > TurboSync - Connecting Delphi to your Palm > __________________________________________ > > -- > For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/ > -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
