Login
Templates, Tools and Utilities
for Clarion Developers
Templates, Tools and Utilities
|
||
|
|
|
Add a comment to an Icetips ArticlePlease add your comments to this article.
Please note that you must provide both a name and a valid email address in order
for us to publish your comment. Comments are moderated and are not visible until they have been approved. Spam is never approved!
Back to article list Search Articles Add Comment Printer friendly Direct link 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
Today is November 23, 2024, 2:21 am This article has been viewed 35393 times. Google search has resulted in 29 hits on this article since January 25, 2004.
|
|