What are the pieces of EmailDLL?

The files provided in TLRSWP EmailDLL version 1.0 are: Email100.js A Javascript class definition that allows you to use the DLL using the object/property/method style of Javascript. The "Email" class is defined in this file, and functions as a "wrapper" around the function calls to the Email100.DLL library. Email100.DLL The Dynamic Linked Library that sends the messages. This DLL has three entry points for performing all functions. Email_defines100.js A Javascript include file listing error code values and their matching strings. Note that the strings are also available from the Email.GetErrorString() method. DLLDefines100.js A Javascript include file that defines the external DLL function calls, and the command operator values used with the EmailCmd() function. EmailDLL100.hlp, EmailDLL100.cnt 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. EmailTest100.jfm An example IntraBuilder form using the EmailDLL. Nothing fancy, just a small test you can play with. ShrLk20.DLL 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 provided Javascript class definition. The Javascript Email 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 Javascript class in memory for your application. Accessing the 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: Criteria Email Class Direct DLL Programming/Coding Effort Low Medium Programming Style Object-Oriented Non-OOP Program memory consumed by IntraBuilder Higher Minimal Application Load/Compile Time Slightly Slower Slightly Faster Data memory consumed by IntraBuilder Very Little Difference Affect on application running speed Very Little Difference Features Available No Difference Mail transmission speed No Difference Online help emphasis Equal Coverage 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 installation recommendations, 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. Do you update the old application without changing the Javascript 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 the DLL. 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 report them.

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 referenced. 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.