EmailDLL Using the Email Class FAQs
The page has answers to FAQs related to using the Email
class and methods. The other categories are:
Integration with your application,
Direct DLL Access,
Creating and Sending Messages,
What files are needed for the Email class?
We recommend that you install the EmailDLL in its own
directory, and copy the necessary files into the forms
directory of your application. If you store them elsewhere, you
will have to modify the email.js file to ensure the extern
declarations refer to the correctly DLL storage location. The
appropriate files are:
- email100.js the email class wrapper
- email100.dll the email DLL file
- shrlk20.dll the license authorization DLL
- emaildll100.hlp windows help file (optional)
- emaildll100.cnt windows help contents file (optional)
- email_defines100.js email errors and messages (optional)
The help files are only needed if you plan to access the online
manuals from the debugging log window. If you do plan to access
them in this manner, place them inside the Borland IntraBuilder
install directory. For example, C:\Borland\IntraBuilder.
Where do I put the #INCLUDE statement?
You must place the statement "#INCLUDE email100.js" (no semicolon)
place the #INCLUDE statement outside of any other class
definition. The recommended place is just before the form class
If you place the class definition in a directory different than
where the reference is made, you must include the relative or
absolute path in the #INCLUDE statement.
What methods do I need to check for errors from?
All the methods in the Email class definition return
error codes. But, unless something serious happens,
most of them will never indicate errors.
In general, you need to check for errors from only the
Email.Create() and Email.SendMessage() methods. If the
Email.Create() operation is successful, it is extremely
unlikely that the other methods will return an error. That's
because the others only set data values inside the DLL,
and I have never seen them return an error. On the other
hand, if Email.Create() failed, then you shouldn't be
issuing the other commands, since the internal email object
likely can't be accessed.
The exception is that Email.SendMessage() can produce many
different errors. From basic operational errors to
communications and Winsock errors, this method is the one to
pay attention to.
I keep getting "Object doesn't exist" errors. What's Wrong?
These messages are usually the result of an out-of-scope reference.
Check to make sure the variable to which you've attached the
Email object is visible in all places where it is referenced. If
it is not, consider moving the Email object into the main form's
definition. Even if you don't call Email.Create() until the object
us to be used, making it global to the form reduces the liklihood
that you'll get these errors.
Should I create one persistent object per form?
That depends. If you have only one method on your form that
sends email, then the object can be local to that method. If you
have multiple methods that need to send email, using the same
email object in all of them will increase performance slightly,
since the Email.Create() method is only called once.
What do these error codes mean?
EmailDLL produces two categories of error codes. All of them
are negative values returned by the Email class. Numbers from
-1 down to -9999 are reserved for the EmailDLL itself. Zero
represents success. Version 1.0 only generates error values
from -1 to -16. At this site, you can
a complete listing of the EmailDLL error messages.
The EmailDLL also returns Windows Sockets errors that are
discovered by various functions inside EmailDLL. These can
be distinguished because they are all negative numbers less
than 10000. At this site, you can
a complete listing of the Winsock error messages.
You can find a complete listing of the error codes and their
text equivalents in the file email_defines.js.
You can convert an error value into an American English text
string with the Email.GetErrorString() method.