Login
`
Templates, Tools and Utilities
|
||
Icetips Article
Back to article list
Search Articles
Add Comment
Printer friendly
Direct link
Par2: How to create an "Application CLASS" that is compiled and linked into a DLL 1998-06-26 -- Steve Olensky A simple explanation of how to create an "Application CLASS" that is compiled and
linked into a DLL and can be called from any other DLL in the Application.
What I wanted to do is create a "Smart Procedure" that could apply the City and State
to a telephone long-distance record. Basically all I had to work with was a table of area
codes and prefixes that had the city and state. This table is over 98,000 records, so
once I had looked up a record I wanted to keep it in a queue so that I would not have
to go to disk again for that area code/prefix (SQL over the network). I could have used
a "module" with its own queue and several procedures, however I might want several
threads calling this routine at one time.
Because a class has its own data, this was a perfect solution. I had several problems in
the CW environment I needed to overcome.
1.I wanted my class to be part of a utility DLL.
2.I wanted my class to have access to all of my data files.
3.I wanted my class to be linked and compiled with the utility DLL and be external to
all other calling DLLs so that any changes made in the class and recompiled into
the utility DLL will be immediately visible to all other DLLs without having to
recompile them.
Here is how I accomplished each of the hurdles above.
1.I created the class .INC file and put the include in the global data section of the DLL.
2.I pointed the MODULE statement to the DLLs .CLW file.
3.I used flags to tell the class how to link. These flags must be set so that in the "home"
DLL the class will be linked and not external, and just the opposite for all other DLLs.
4.I had to add the prototypes to the "Inside EXP file" global embed so that calling DLLs
could link to the class properties (data) and methods (procedures).
Below is an explanation of the class header.
Cprice class,type,module('cprice.clw'),link('cprice.clw',_SOLinkMode_),DLL(_SODllMode_)
Data !data goes here
Procedure !procedures go here
Qcpx &qcpxtype !sample queue definition
showcus procedure !sample procedure
End
Notice the two flags SOLinkMode and SODLLMode.
When these flags are zero, then the directive is ignored. This is how you control when
to link your class into a DLL and when the class is in an external DLL.
In my utility (home) DLL I declare the class as follows.
_SOLinkMode_ equate(1)
_SODllMode_ equate(0)
include('cprice.inc')
In my calling DLLs I declare the class like this.
_SOLinkMode_ equate(0)
_SODllMode_ equate(1)
include('cprice.inc')
Since I want my calling DLLs to actually use the external class, I had to be sure that my
Utility DLL Export file (.EXP) includes the class's properties and methods. This is where
it is a real PIA in that you have to embed this in the DLL's global section. It would be
nice if a Clarion APP had a mechanism for including these export definitions for us. The
easiest way that I have found to get the correct definitions is to compile a calling DLL
and when you get the link error, use this for the export information. For example, this is
what I had to include in the export file for the above example.
VMT$CPRICE @?
SHOWCUS@F6CPRICE @?
The header for the .CLW class file is.
member('autl.clw')
map
end
include('cprice.inc')
Notice the MEMBER statement. This is normally left blank so that the class will be totally
independent of any program. However, in this case I wanted my class to see all of my
data files and global data. This is not a problem since this class is designed to work only
with this application, or any application using the exact same data files.
I am sure that the terminology used in this explanation is NOT correct. What I was hoping
to do was to document a way of adding a class to an application, the same way we
add a DLL.
Any and all comments, corrections, suggestions, and better ways of doing what I have
described are welcomed. This document is posted at http://www.olis.com/cw/oop. All
responses will be posted here also.
Steve Olensky, VP.
Software Technology, Inc.
800-844-0884 x 148
steve@ssts.com
Today is November 21, 2024, 3:55 am This article has been viewed 35187 times.
|
|