EmailDLL Integration FAQs
This page has answers to FAQs regarding how to integrate
the EmailDLL into your applications. The other categories
Direct DLL Access,
Creating and Sending Messages,
What are the pieces of EmailDLL?
The files provided in TLRSWP EmailDLL version 1.0 are:
The "Email" class is defined in this file, and functions as
a "wrapper" around the function calls to the Email100.DLL
The Dynamic Linked Library that sends the messages.
This DLL has three entry points for performing all
and their matching strings. Note that the strings
are also available from the Email.GetErrorString()
DLL function calls, and the command operator values
used with the EmailCmd() function.
Windows-95/NT online help and table of contents files.
To access these from the debugging log window, copy them
to the IntraBuilder base installation directory.
An example IntraBuilder form using the EmailDLL. Nothing
fancy, just a small test you can play with.
The security authorization DLL. This is required so
that your evaluation period can proceed, and so that
your registration codes can be authenticated.
How do I choose: Email class or Direct DLL?
The EmailDLL has two ways you can access it. You can access the
Dynamic Linked Library (DLL) directly, or your can use the
class provides a familiar object/property/method style of
programming, and insulates you from having to directly access
the DLL. But, it comes with the price of having another
DLL directly means you don't have the overhead of the class,
but it means you have to do some extra programming yourself.
We recommend using the provided Email class, since the
programming effort needed is lower, with no loss in features.
Directly accessing the DLL is only useful in applications that
will experience very high volume, or where application and server
performance are critical. Most applications will not require
that small performance increase. The improvement comes almost
entirely from not having to load the Email class definition and
keep it in memory on the server.
The real choice comes down to how comfortable you feel with
directly accessing the DLL and doing that programming work,
compared with slightly better performance in application
load time and memory usage. The table below summarizes how
the methods differ:
Program memory consumed by IntraBuilder
Application Load/Compile Time
Data memory consumed by IntraBuilder
Very Little Difference
Affect on application running speed
Very Little Difference
Mail transmission speed
Online help emphasis
Need an example? The online manual has examples for both.
Compare the code for sending an email message with the
Email class versus
sending that same email message using
direct DLL access.
Where should I put the files?
Assuming you followed our
and you installed the EmailDLL into its own directory, then
you have several choices. We recommend that you copy the
files into the directory where the application forms are
kept. This keeps you from encountering problems when you have
multiple applications being updated and revised.
For example, suppose you create one application with the
EmailDLL version 1.0. Six months later, your first application
is still in use, but now you're deploying a second one. The
second application uses the great new features in version 1.5 of
EmailDLL. Unfortunately, your boss hasn't allocated any time
to update the first application to the new EmailDLL version.
code? Do you skip testing and rely on hope and prayer?
In this scenario, the best solution is for the first
application to specifically call the EmailDLL v1.0, and for the
second application to call the EmailDLL v1.5. Keeping the files
inside the application's form directory makes this much easier.
That way the first application can continue using the EmailDLL
version it was tested with.
If you choose to place the class and DLL files outside your
application's forms directory, you will have to modify the
email.js file so that the extern declarations point to the
correctly DLL location.
Because EmailDLL is licensed per server computer, you can have
as many copies, or whatever versions you choose, running at any
time on that computer. What you can't do is take the
new version of EmailDLL, deploy it to another computer while
the older version continues to run on a different computer. You
need a separate license for that added computer. Remember, you
agreed you would do this in the original license.
How many email messages can I have open at once?
The number of "open" email sessions is limited only by the
memory on your computer. Briefly, as long as you're using
the Email class instead of the DLL, you should never have
problems with the capacity of the EmailDLL.
EmailDLL keeps an internal object in memory for each email
session currently in progress. That object is retained from
the time it is created with the Email.Create() method, until
that object is destroyed with the Email.Free method.
When an IntraBuilder application calls a DLL, the DLL is loaded
into memory once for each user agent on which the application
is run. For example, suppose you have 5 agents running, and two
people have started sessions using that application. At most,
there will be two copies of the DLL loaded, in the case where
IntraBuilder used different agents for the two user sessions.
In fact, if IntraBuilder used the same user agent for both
sessions, only one copy of the DLL will be loaded.
If you're using the Email class wrapper, each user-session
will have only one Email object. That's because the class
wrapper uses the IntraBuilder netInfo.sessionID as the handle
for the Email object.
If you're handling your own handles, accessing the DLL directly,
then your application can have multiple email object open inside
Typically IntraBuilder is configured so that each agent can
handle up to 60 user sessions. When using the Email class wrapper,
then, each DLL would have up to 60 email objects open. This is
well within the capabilities of the internal data structures,
but may overwhelm your SMTP server if it or the network connection
to it is slow. If fact, the limiting array inside the DLL is
limited to 1 billion objects, since it's addressed by a positive
integer data type.
If you're directly accessing the DLL, then the
sessions-per-agent limitation doesn't apply. This allows many
more email objects; the limit on the DLL would then be the 2GB
memory space limitation. Certainly the SMTP server will be
overloaded long before it can handle that many email messages.
If you do experience problems with the DLL related to number of
sessions or open email objects, please
Why does the DLL load more than once?
Multiple instances of the EmailDLL are loaded because
IntraBuilder loads a separate copy of the DLL for each user
agent on which the application is running when the DLL is
For example, suppose you have 5 agents running, and two people
have started sessions using that application. If IntraBuilder
uses two different agents for the sessions, two copies of the
DLL will be loaded. If IntraBuilder uses the same user agent
for both sessions, only one copy of the DLL will be loaded. At
most, there will be two copies of the DLL loaded. If you have
those same 5 agents running, no more than 5 copies of the DLL
will be loaded.