The Basic Concept of LastErrorText

There are a few important things about the LastErrorText:

1) Each Chilkat method call (or property access) clears the LastErrorText and writes new information about what transpired during the method call.  This information is available regardless of the success/failure of the method call.  Most Chilkat objects include a VerboseLogging property that controls whether more or less information is recorded.  Only use VerboseLogging for debugging situations as it may impact performance.  (Note: Some property accesses will not write anything to LastErrorText because the internal implementation is trivial and it could adversely affect performance, especially if the property is used in a “for” loop statement.)

2) Make sure to get the LastErrorText from the same object instance.  If interested in the LastErrorText after calling imap.FetchSingle, then get imap.LastErrorText.  (Not email.LastErrorText, or any other object instance.)

3) LastErrorText contains information about the last method call for an object instance.  (i.e. the most recently called method or property)  To get the information about what occurred during a call to imap.FetchSingle (for example), one must get the contents of the LastErrorText *before* calling any other method or property on the object.  (Thus the significance of the word “Last” in “LastErrorText”.)

4) The LastErrorText indicates the name of the method (or property) for which it contains information.  For example:

ChilkatLog:
SetFromMimeText:
DllDate: Jan 19 2012
UnlockPrefix: NONE
Username: joe
Architecture: Little Endian; 32-bit
Language: ActiveX
--SetFromMimeText
--ChilkatLog

LastErrorText Standard Information

All Chilkat classes / components use a property named LastErrorText.  It provides a way to get detailed information about what happened during any Chilkat method call.  The LastErrorText will contain information even when the method call is successful.

In almost every case, the LastErrorText will begin with information such as this:

ChilkatLog:
  Connect:
    DllDate: Jun  2 2009
    UnlockPrefix: ****
    Username: Jake
    Component: ActiveX

When contacting Chilkat support (support@chilkatsoft.com) you will probably be asked to provide the contents of the LastErrorText property. The information at the beginning of the LastErrorText is important. Here are the details:

DllDate: It tells Chilkat support how old of a version of the Chilkat component/library is being used. In most cases, if the DllDate is old, you will be asked to try the latest released version. The reason is that most problem reports are already fixed in the latest version (especially if the DllDate is old) and the information in LastErrorText is always improving. It’s best to begin investigating a problem by using the latest version.

Also, Chilkat may provide a new build and ask the customer to re-test. In a surprisingly large percentage of cases (especially when using the ActiveX or .NET components), the customer does not actually use the new build and re-test using the same old-version. The DllDate allows Chilkat support to know if the customer is really testing with the new build.

UnlockPrefix: Provides Chilkat support with licensing information. If your 1-year support expired, you *may* be given a 1-support grace incident with the expectation that support will be renewed prior to any future support requests.

Username: This is the logged-on Windows OS username of the process. The main reason it is included is to allow us know if the process is an IIS worker process, or perhaps running as a Windows Service. In these cases, file access and I/O permissions may be more restricted than when running other applications.

Component: Allows Chilkat support to know if you are using the ActiveX, .NET, VC++ libs (and the version of VC++), etc. It saves time from having to ask which Chilkat lib/component is being used.

Also.. the first line after the opening “ChilkatLog” will be the name of the method call. In the sample above, it can be seen that “Connect” was the method call. (Quite often, a customer will not capture the contents immediately after the intended method call. )