Stumped? Don't worry, we all get that way at times. Here are some of our favorite things to forget when using EmailDLL. See if one of them helps you! (Go back to the top)

• Read the documentation The guideline to use is "don't ask for help unless it's something you can prove is wrong." We won't hold you to that requirement, but we recommend using it. Search the online help and the readme.txt file; don't give up. We try to cram as much information into the help files as possible. Every detail, every error condition, every possible question you might have. Check for it; you will likely find it.
• Read the FAQ This source of information may be invaluable. Often, a FAQ deals more with "how to use" the tools. The documentation, on the other hand, tends to more address the "what does it do" questions. When you're trying to do something, this approach may be just what you need.
• Remain Calm If you encounter a problem, take a step back and think about the problem. Don't immediately give up and request help. Often the solution will be right in front of you. If you can't figure something out, give it some time. Take a break; have a cup of whatever you prefer. Think about the problem with a clear and rested head.
• Check the installation locations. One of the more common problems people encounter is having their EmailDLL files in the wrong place. Consult the online manual topic Where to put the files. Try placing the class file (email.js) and the DLL files (email.dll and shrlk20.dll) into the directory where your application resides.
• Can't locate the help files? To access the help files from the debugging log window or the registration reminder screen, the files emaildll.hlp and emaildll.cnt must be located in the same directory as the email.dll file.
• Remember to create the Email object Yes, it seems so obvious. But if you get "Object not found" type messages, check to see if somehow the object you're referencing isn't actually initialized with the Email object. And, make sure you call the Email.Create() method with a proper parent object. The parent object should be your main form, since it is needed to get the session ID value for the email message handle.
• Don't throw away the return status The methods return status values. While many of the header, recipient and other methods don't give much in the way of usefull information, others do indeed. So, don't ignore the error messages. Any value less than zero indicates a problem occured.
• Check the SMTP Server. This problem will likely be a source for consternation. If the server is not responding, then email can't be sent, and you will receive errors for each email your application tries to transmit. Try using the "ping" command to check your server. Also, be sure to use the Email.SetDebugOn() method, as that will display a log of errors encountered.
• Try the example form. If you still can't figure out what's wrong, try the sample form included in the package. If you're using some method that's not used in the sample form, then add a call to that method in to the form. If the email gets sent properly, then it's like some other problem in your application.
• Check the data The debugging log window displayed with the Email.SetDebugOn() method doesn't display the data of the message. So, if there's a problem with the message data, then check that the data is actually being sent to the Email class. For example, a message received with no text might indicate that the string to which you think you're adding message text is actually empty when the call to the Email.AddMessageLine() method is called. Same thing for header lines.
• Is the message file still there? If you're using the Email.SetMessageFile() method, make sure that the file doesn't get deleted or overwritten before it's used.

If you still can't fix the problem, then by all means send an email message to support.

Please use these guidelines when requesting help. If your message doesn't include this information, and we need it to locate the problem, finding the solution may be delayed. Also, going through the exercise of preparing definitive data on a problem often reveals the nature of the problem. (Go back to the top)

• Describe your system. Be sure to provide information on your server machine(s). This will be invaluable when trying to duplicate some problems. This includes processor type, whether there are multiple processors, what operating system, how much memory, other programs, your method of connection with the SMTP server, etc. Anything you can think of that might be getting in the way of your sending messages.
• Describe the installation locations. If the problem is some file that can't be found, be sure to indicate where the files are located. This includes email.dll, shrlk20.dll, and email.js.
• Explain the problem fully. A clear description of the problem is absolutely essential to quick problem resolution. Yes, we know that Javascript may have become your native language, but using good grammar helps us locate and resolve your problems more quickly.
• Make a simple test case. If there is a problem, you should be able to provide a small piece of code which illustrates the problem. Sending large pieces of untested code may significantly delay a response to your inquiry. Also, be sure to test the test case to ensure it really does display the problem. If possible, try to find the key statement that makes the problem appear. Indicate that statement where possible.
• Don't make the test case proprietary If a support question and the answer might be asked by another user, then we'd like to put it in a FAQ entry. Sometimes it's difficult to decide what information is confidential to your company. So, either don't include confidential information in your email, or clearly indicate what information is confidential. We want to avoid revealing your proprietary and confidential information, and will endeavor to avoid doing so. But, if you don't tell us, we might not know .

Still stumped? Well, we're here to help. Just click the link below or send email to that address, and we'll do our best to answer.