A conduit dll from PalmOS is the code that contains the MFC references, as acknowledged by Mr. Combee. Without access to the referenced MFC components on my system, the code that references it can't link to it. One would have to write some sort of replacement. I'd rather not. A dll is compiled code. I don't want to spend my time creating my own versions of MFC classes. Being able to call one function or many in a dll from any language was never in question. The problem I encountered came from referenced functions in a dll that I do not have, which interfered with linking. (People with MFC on their system and IDE's that are set up to look in the MFC directories for the MFC code may well be able to develop in any language that is set up to link with MFC code without them even being aware that this is happening.) The MFC code can not be linked into one's program if one does not have the MFC code, unless one wishes to find a way to develop one's own version of the MFC code as replacements (hence the recommendations to develop a "stub dll" or to recompile the dll code so as to eliminate references to code that one does not have). If I'd had MFC on my system, the problem might not have arisen in the first place assuming that Builder could find and link to the MFC code without use of IMPDEF and IMPLIB to insure compatibility, although there would have remained the question of whether I could legally link Borland code with MFC classes from a Borland IDE. (I don't have the VC++ licensing agreement and don't know if it stipulates that use of MFC classes is restricted to the VC++ development environment.)
My problem was largely a product of not having the major development platforms supported by PalmOS for C++ under Windows, which is C++ .NET. (I'd acquire it, but I'm concerned that some of my older software might not run under Windows XP, given that I am now running Windows 98 SE.) By supported, I refer to having access to a PalmOS wizard and sample code that is restricted to classes and header files provided with a particular IDE and PalmOS documentation describing how to develop the conduit with meaningful references to the IDE menus and the classes that come with the IDE. (Use of Microsoft VC++ also positions one to access the MFC in a manner that leaves no doubt with regard to whether one can legally incorporate them into one's software.) I simply have never been inclined to use Microsoft VC++, having learned C++ in classes that employed Borland's IDE. My perspective previously has been that one could use VB for the front-end, and write dlls in C++ for any mathematically intensive application requiring use of complex numbers and matrices, given that VB was once considered to execute mathematical operations more slowly than other languages. The COM approach wasn't my first choice in terms of accomplishing the code using API access through direct calls, as described in the PalmOS documentation and reinforced by advice I have received from others here. It is compatible with VB 5.0, and thus one of my favorite programming languages. Accessing the Palm database under Builder was recommended by Mr. Combee using COM, and would have represented another, supported option, although one with few advantages over using VB from my perspective given inability to directly access API calls. Thanks to all who have responded. > There is nothing special about writing DLLs. The just have to have some > pre-agreed "entry point" functions, so that external code knows what it can > call. Otherwise you can do pretty much everything you would do in a normal > application. > > This is a red herring. You can call into any of the conduit DLLs. I do it from a > completely different language, so calling it from C is no problem. Other people > on this group have used Borland C++ Builder, for example. This MFC stuff is > irrelevant. Your sample code may use MFC for other things, but it is not > necessary to access any of the conduit APIs. > > > A Borland programming group had suggested that > > I recompile the dll from source code -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
