FPiette

Try with passive mode.

The download should always be done from http://wiki.overbyte.eu/wiki/index.php/ICS_Download which is more up to date. Currently, V8.64 is the latest stable version recommended.

I don't see anything wrong in line 277. Strangely both files have an error at the same line, same column. Download ICS again and retry.

Angus, this model is not suitable for CGI. A CGI module is expected to run as quickly as possible. If a queue and retries have to be done, it must be launched independently by the CGI so that it becomes an independent process. Or the CGI could call a service doing the actual send. Or other similar solutions.

Simply remove the inline keyword. This will not affect the function, only the performance.

Maybe there is a caching device between your application and the server. This device always returns the same result. Just a guess.

You need to look at your form. "Action" is the URL you have to use to submit your form. "Method" is the way to submit if: Get or Post which maps directly to HTTP component. Then you have to look at all "input" tags to find the name of the items to send. Then you have to format a buffer with name/values pair and submit it. François Piette

That is correct. But this doesn't prevent ICS from being used from several threads. ICS do not need multithreading to do simultaneous operations on hundreds of sockets. It works nicely on a single thread. You only need multithreading if you need thousands of ACTIVE communications. And you need thread to off-lone the communication thread from processing. For example, if you have a lengthy database request and use a synchronous (blocking component) then you need a worker thread for the blocking database request. If you create a thread for each communication, you'll be quickly have poor performances. The best is to balance number of thread and number of connections. If well designed, you can develop an application using ICS having as much thread as the CPU core and each thread handling hundreds of connections. Whatever component you use, it is sure that handling thousands of simultaneous active connections requires proper design and proper hardware.

This is how Delphi and Windows works. Anything related to Windows messages and many other things need to be created/destroyed within a thread's context not the thread constructor. This is because a thread constructor run on the context of the calling thread, which obviously not the thread under construction. If you had given a look at ICS multihread samples, you'd known...

Calling connect is not enough to send a mail. See the sample program, seen the code behind "all in one" button.

Colek, I would create a new component instead of modifying the ICS one. You can either inherit from THttpCli component or inherit from TComponent and embed a THppCli to do what needs to be done. Either way has pros and cons but both are exactly what object oriented programming is all about. Think about moving the logic behind your application into a component instead of putting it into a TForm.

Do you have full source code for the add-ons you use? If yes, it should be fairly easy to port the code to the current Delphi version. I have done that a lot of times with great success. Without source, you have to replace the old add-ons by current version if it exists or by other ones. This may be more difficult. Advice: never use an add-on without full source code. btw: If you want to discuss porting your code, you should post in another forum, maybe this one https://en.delphipraxis.net/forum/4-vcl/ if we are talking about VCL.

Well, again this one is fixed. Only those omitting to apply ALL updates are at risk. And by the way, this is not related to DNS which is the subject of this conversation.

I checked a few of those and all I have checked are fixed by Microsoft. The recomandation is simply to get ALL updates from Microsoft as soon as they are published (Just turn on auto update. Tht's what I have always done).

I never had this need.