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) inside your Javascript code to access the EmailDLL features. The email100.js file contains a Javascript class definition. Since Javascript doesn't support nested class definitions, you must place the #INCLUDE statement outside of any other class definition. The recommended place is just before the form class declaration. 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 view 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 view 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.