Question:

I have now tried to register the component manually, but then I get his
message:

"The module c:\...\ChilkatDotNet2.dll was loaded but the entry-point
DllRegisterServer was not found.
Make sure that c:\...\ChilkatDotNet2.dll is a valid DLL or OCX file and try
again."

Answer:

A .NET assembly is not an ActiveX component. It is not registered with regsvr32. If your application is written in C# or VB.NET (i.e. it is a .NET application), then you simply add a reference to the Chilkat assembly (such as ChilkatDotNet2.dll) within your Visual Studio project. If you need to use the ActiveX component from other languages, such as VB6, ASP, FoxPro, Delphi, etc., then download the ActiveX from http://www.chilkatsoft.com/downloads.asp and install. If the ActiveX DLL is already installed and you need it on another computer, you may simply copy the ActiveX DLL and register with regsvr32. Please read this blog post about using ActiveX components on win32 / x64.

Question:

I was wondering how it would be possible to make changes to an email on the server.

Answer:

Once an email is on a server, it cannot be modified.  This is not a Chilkat limitation, but it’s the way mail servers work.  However, with IMAP you may download an email, make changes, upload the new email to the mailbox via one of the Chilkat.Imap.Append* methods, and then delete the old email.  The new email will have a new UID assigned by the IMAP server, so it’s technically not the same email..

If you’re just starting to program with TCP connected sockets using the Chilkat Socket API, then these concepts should be understood before beginning.

1. Receiving Data from a Connected Socket.

The ReceiveBytes and ReceiveString methods will return whatever data has already arrived and is available on the connected socket.  It is not guaranteed to return the complete amount of data that may have been sent by the server.  It may require multiple calls to receive whatever was sent by the server, and your application must know when it has received the full amount.

2. Knowing How Much Data is to be Arriving on a Socket.

When two programs communicate by sending and receiving data over connected sockets, the receiver must know how much data is forthcoming (so that it knows when it has a full “message” — otherwise the receiver will continue trying to read the socket and will “hang” because nothing more is forthcoming..)   There are three ways of accomplishing this:

1. Use pre-defined packet lengths. In this case, the connected peers have pre-agreed upon a fixed-size amount of data that will constitute one “message”.  For example, if a message is pre-agreed to be exactly 1024 bytes, the receiver knows that it must read exactly 1024 bytes and once fully received, it can stop reading and process the “message”.
2. Prefix data with a byte-count. The connected peers could use a simple technique such that each message is defined as a fixed-length byte count followed by the message.  For example, if messages are to always be less than 256 bytes, one might communicate by sending a 1-byte integer length followed by the message data.  If messages are to be longer, one might send (perhaps) a 4-byte integer length followed by the message data.  If a multiple-byte integer length is sent, the byte-order (little-endian or big-endian) must be pre-agreed upon.   The Chilkat Socket API provides methods to help implement this technique:  SendCount, ReceiveCount, and ReceiveBytesN.
3. Read until end-of-message marker is seen. This technique is commonly used by many Internet protocols.  The idea is that the end of a message is defined to be a pre-agreed upon sequence of bytes or string.  For example, CRLF (carriage-return, line-feed) is commonly used in protocols such as FTP, POP3, SMTP, etc.    The receiver continues reading the socket until it receives the sequence of bytes that indicate the end-of-message.  The Chilkat Socket API provides methods to help implement this technique:  ReceiveUntilMatch, ReceiveUntilByte, ReceiveToCRLF, and ReceiveStringUntilByte.

3. Sending Data on a Socket.

When data is sent on a connection via any of the Chilkat Socket methods, what really happens is that the data is passed to the Windows OS for buffered output on the TCP connection.  (This is the same for all socket programming APIs, whether it is Chilkat or non-Chilkat.)  You can imagine that if an application sends a lot of data in a rapid succession of SendBytes method calls, the initial calls will return instantaneously because the Windows OS has plenty of space in the outgoing buffers.  If the application continues to send more data faster than the data can actually be sent over the Internet connection (perhaps because the connection is slow, or the peer is slow to process incoming data), then eventually the SendBytes method will “hang” until enough space is available in the outgoing buffers.  This is the reason for the existence of a MaxSendIdleMs property.  It is also the reason you’ll see throughput spike at the beginning of a data transfer and then slowly decrease to the steady-state throughput rate of the connection.

4. Making a Connection

Initiating a connection with a remote peer (or server) is like making a telephone call.  The attempts to connect to a remote endpoint specified by an IP address and port number.  (If a domain name is used, it is internally converted to an IP address via a DNS lookup.)  An application calls Connect and then waits for an answer.  The maximum amount of time to wait is specified in the last argument to the Connect method.  The ConnectFailReason property indicates the reason for failure.  If the Connect fails because of a timeout, it is due to one of the following reasons:

1. A firewall at either the client or server side is blocking the connection.
2. There is no server listening at the remote host:port to accept the connection
3. Some other software, such as an anti-virus or anti-spyware program is blocking the connection.
4. The server was too slow in accepting the connection.

It is impossible to know which is the reason because just like a telephone call, the only information you have is that it wasn’t answered.

5. Sending and Receiving Strings

Let’s say you want to send the string “ABC” to the connected peer.   Most programmers implicitly assume it means sending three bytes:  0×41, 0×42, and 0×43.   This is usually correct, but the assumption was made that the communicating programs have pre-agreed upon using the ANSI charset (such as Windows-1252)  such that “A” is represented by a single byte having the value 0×41, and “B” is represented by 0×42, etc.    What if the sender sends ANSI but the receiver is expecting Unicode (ucs-2).  The receiver would be expecting 6 bytes because “A” is represented by 2 bytes (0×41, 0×00), “B” is represented by 0×42, 0×00, and so on..

The StringCharset property controls how strings are sent and received.  It defaults to “ANSI”.  If, for example, it is set to “Unicode”, then a call to SendString(”ABC”) would result in the sending of 6 bytes:  0×41, 0×00, 0×42, 0×00, 0×43, 0×00.   The ReceiveString method would know to interpret the incoming bytes as 2-byte/char Unicode chars and correctly return the string “ABC” to the caller.

This is even more crucial when sending non-English characters, where there are many more choices for character encodings.  For example, Japanese strings might be sent in Shift_JIS, iso-2022-jp, utf-8, Unicode (ucs-2), euc-jp, etc.  It is important that the communicating peers agree on the byte representation of the strings sent and received.

Question:

I recently purchased the Chilkat HTTP component and am using it with a Visual FoxPro application. However, each time I run it the form freezes and I get the Not Responding message in the title bar. I have an animated GIF that I am using as a quasi-progress meter but that freezes as well. As soon as the HTTP Download finished, the form gets the focus back and the download is successful.

I need the animated GIF to keep working and to avoid the freeze and Not Responding message. Happens every time. Plus the mouse cursor pointer disappears from the VFP form.

Answer:

To answer this question, I must first describe the basic architecture of all interactive Windows-based applications w/ user-interfaces. This applies to all programming languages: FoxPro, VB6, MFC (C++), C#, VB.NET, etc.

Microsoft Windows programs are event-based. They act upon messages that the operating system posts to the main application thread. These messages are received from the message queue by the application by repeatedly calling the GetMessage (or PeekMessage) function in a section of code called the “event loop.” (See this Wikipedia article: Message Loop in Microsoft Windows)

In higher-level programming languages such as FoxPro, VB6, etc., the actual code for the app’s message loop is hidden from you. The application programmer interactively designs a user-interface and provides code (handlers) for user-interface events. For example, when “Button A” is pressed, call this subroutine (or function). Typically, the code in your button handler finishes quickly and returns control back to the caller. It happens so fast that you never notice that technically the user-interface was “frozen” for the short amount of time spent in your button-handler code.

It becomes apparent that user-interface events are not being handled when your application code takes longer to complete before returning control back to the app’s main event loop (i.e. before returning control to the FoxPro, VB6, C#, etc. runtime). It may also help to think of it this way: Since the application is single-threaded, it can only be doing one thing at a time. While the application thread is executing the application code, it can’t possibly be doing something else, such as executing code to update the user-interface.

The solution is that within your application code you must periodically handle any accumulated user-interface events. In Visual Basic 6.0, C#, and VB.NET, this is accomplished by calling the DoEvents function:

(from the Microsoft online documentation for Application.DoEvents)

“When you run a Windows Form, it creates the new form, which then waits for events to handle. Each time the form handles an event, it processes all the code associated with that event. All other events wait in the queue. While your code handles the event, your application does not respond. For example, the window does not repaint if another window is dragged on top.

If you call DoEvents in your code, your application can handle the other events. For example, if you have a form that adds data to a ListBox and add DoEvents to your code, your form repaints when another window is dragged over it. If you remove DoEvents from your code, your form will not repaint until the click event handler of the button is finished executing…”

In Visual FoxPro, it is the DOEVENTS command.

Since the bulk of the time spent within your application code may be within a Chilkat function call (especially if it involves communications over the Internet), then you must tell the Chilkat component to make periodic callbacks to your application code, so that your application can then call DoEvents. The standard way of doing this w/ Chilkat is via the AbortCheck event. The HeartbeatMs property controls the frequency of AbortCheck event callbacks. The default value is 0, which indicates no AbortCheck events. Set it to a value such as 100 for event callbacks every 1/10 of a second.

For more information: ActiveX Events in FoxPro

For more information: AbortCheck in C# and VB.NET

Question:

A quickie question about the FTP2 control. I have some clients with strange
FTP servers that return the directory listings in formats that no control
seems to be able to handle (although I have not tried yours!). However, it
is next to impossible to test, since I do not have access to their server.
For them, we use the MLST command, so they return plain filenames (since this
is universally supported, while the full listings vary by server). How do I
do this with FTP2?

Answer:

The Chilkat FTP2 component automatically detects at connect-time whether the FTP server supports MLST. If so, then MLST is automatically used internally. If the server does not support MSLT, then Chilkat FTP2 is already capable of parsing FTP directory listings from virtually every variant of FTP server, including MVS (old mainframes), AS/400’s, OpenVMS, Unix variants, Windows, and many others. In summary: You shouldn’t need to worry about what the FTP server is sending for directory listings. Chilkat FTP2 handles it all internally..

The Chilkat VC++ static libraries are for unmanaged C++ applications. A Managed C++ application (using Microsoft’s Managed Extensions for C++) runs within the .NET Framework and therefore must use the Chilkat .NET assembly.

The Chilkat C++ online reference documentation and online examples are for unmanaged C++ applications. For Managed C++, the best choice is to read the C# online documentation and C# online examples (at example-code.com). Managed C++ syntax is closer to C# syntax than unmanaged C++ syntax.

To see the differences in syntax, here are some sample code fragments in unmanaged C++, Managed C++, and C#.

Unmanaged C++

#include <CkFtp2.h>

void FtpExample(void)
    {
    CkFtp2 ftp;

    //  Any string unlocks the component for the 1st 30-days.
    bool success = ftp.UnlockComponent("Anything for 30-day trial");

    ftp.put_Hostname("ftp.example-code.com");
    ftp.put_Username("myLogin");
    ftp.put_Password("myPassword");

    success = ftp.Connect();

 ...

Managed C++

    Chilkat::Ftp2 ftp;
    ftp.UnlockComponent("30-day trial");

    ftp.Hostname = "www.example-code.com";
    ftp.Username = "myLogin";
    ftp.Password = "myPassword";

    bool success = ftp.Connect();

    ....

C#

Chilkat.Ftp2 ftp = new Chilkat.Ftp2();

bool success = ftp.UnlockComponent("Anything for 30-day trial");

ftp.Hostname = "ftp.example-code.com";
ftp.Username = "myLogin";
ftp.Password = "myPassword";

success = ftp.Connect();

...

Using the Chilkat IMAP API: To download emails having the exact contents of a header field, or all emails where a given header field contains a specified substring, use the Search method like this:

    (C++)
    CkMessageSet *mset = imap.Search("HEADER Message-ID 48208D0C",true);

    (C#)
    Chilkat.MessageSet mset = imap.Search("HEADER Message-ID 48208D0C",true);

If the Search method returns a non-NULL message set object, then download the emails by calling FetchBundle:

    (C++)
    CkEmailBundle *bundle = imap.FetchBundle(mset);

    (C#)
    Chilkat.EmailBundle bundle = imap.FetchBundle(mset);

Once you have an email bundle object, you may iterate over the emails contained within the bundle.
See the IMAP examples at http://www.example-code.com/
(There are examples in many different programming languages)