OOP: Better OOP part 7 2003-04-24 -- Dan Pressnell Newsgroups: comp.lang.clarion,topspeed.topic.oop March 5, 2006: Note that the code is now available at: http://www.icetips.com/downloadfile.php?FileID=59 With a little help from a template that manages the EXP file, it's possible to have a system that uses DLLs that refer to different dictionaries than your main system. The big problem with this is that the AppGen wants to export more than you can handle in this situation, causing linker conflicts. If you've downloaded the sample OOP app from http://toolwares.com/oop_sample.ZIP, download it again, because I've added more to it. Included now is an APP (States.App) and DCT (States.Dct) that can be linked into the oop app. It uses an entirely different dictionary than the OOP dictionary, and the file system it uses is TopSpeed. In the States.app, there is a StatesClassType class, which reads the tps file to retrieve the list of states. Also, that class has a method that will allow you to select a state from a popup window. The StatesClassType is used by the OOP app. First compile states.app. Then compile oop.app. Then run the oop.exe, and select the "Select state" procedure from the program menu. You can see the states. At that point, you are actually running code that is in the DLL. After you select a state (or click on Cancel), you are shown the states data from the class. Admitedly, there is not much to the example, but the important thing is that it shows a system using two different dictionaries--and even two different file systems--in ways that are consistent. The consistency is made possbile with the use of classes. Here is how the DLL was constructed: 1. First, create a normal app using a dictionary. Make it a DLL app. Create the classes that you need in the app, and write your code for the INC and CLW files that are generated. (See the Classes:1 "procedure" that generates the INC and CLW files.) Don't make ABCs external, and have it generate all file declarations. 2. In global embeds, there is this: states_linkmode equate(1) states_dllmode equate(0) include('states1.inc'), once That informs the compiler of your class declaration and sets the flags to compile and link in your class code. 3. In global extensions, add the template extension "Limit Exports." That extension will prevent anything at all from ending up in your EXP file that is generated, with the exception of PROCEDURES that are set as "Export" and the classes that are generated and set as "export" by the DP_Class_Source template. (Look at the properties window of the Classes:1 procedure and notice the "Export Classes" checkbox. 4. It is important that nothing be in your generated class INC file that refers to anything global (variables, files, etc) in your DLL app. If you don't observe this rule, your class will not be usable by another app, because the INC file will cause compile errors in your other app. 5. Compile the app. Now you have the DLL that can be used by any other app, even if the other app file doesn't use the same dictionary. Now for preparing the app that will use the class. 1. In the OOP app, notice this in the global embeds: states_linkmode equate(0) states_dllmode equate(1) include('states1.inc'), once 2. Add states.lib to your libraries in the project settings. 3. Compile and run. Is this cool or what? Dan Printed November 23, 2024, 5:49 am This article has been viewed/printed 35393 times. Google search has resulted in 29 hits on this article since January 25, 2004. |