Arno and all,

I realized and appreciated your hint to perform it all event-driven and 
I tried to accomplish it the way you suggested. However, I have some 
problems building the correct logic, it seems. In short words, the mail 
sending part of my application is as follows:

1. Opening a SQL server query
2. Fill the standard properties (like Host, Port etc.) which are common 
between calls
3. Invoking my OnGetNextMailParam notify procedure *directly*, as if it 
had been called from the OnRequestDone handler
3a. OnGetNextMailParam checks if the query has still records, read some 
fields, sets HdrTo if the record contains an mail address, calls 
Connect() and Next() for the query
3b. OnGetNextMailParam calls a message handler procedure if there's no 
target mail address, which invokes 3 again.
4. OnRequestDone is built like the sample code in MailSnd1.pas, except 
for the smtpQuit part. In my handler, OnGetNextMailParam is called 
again, and if it reports a valid target address, it calls Connect() 
again (if not, it should have been handled by 3b)

This all should work from the beginning of the query to the end, where 
each record containing a target address should invoke the sending 
process and each other record should not (records without an mail 
address are handled otherwise). But it doesn't - it calls Connect() for 
two records and then it leaves.

I don't like you all to analyze my procedures but I'm looking for some 
basic framework which would do it. I first thought of building the whole 
procedd into the smtpConnect part of OnRequestDone, but this isn't 
possible due to the lack of mail addresses in some of the records. I'm 
really stuck here and I now realize my concept won't work as needed.

The whole thing is not more or less than walking through a record set 
and sending a mail to each receiver within that record set having a mail 
address. Other records having no mail address are handled otherwise, 
must be processed within the same loop but don't invoke any mail sending 
process. And - of course - it should be async ;)


Arno Garrels schrieb:

>>while not FlagDone do begin
>>  //Application.ProcessMessages;  // Don't know whether or not to use
>>the message pump here   Sleep(50);
>This is bad design. Do not wait in a loop. While sleeping the calling
>thread is blocked. Instead let your derived component do the work in 
>the background. In order to get notified when the job has finished add
>a custom event that fires when the work is done, or may be add another
>custom event that notifies the application when a single message has
>been sent/failed. In other words, control the application completely
>thru events while executing the mailing. So in the ButtonClick handler
>there the call to start the mailing should be the very last line. 
>Arno Garrels [TeamICS]
>Kochendoerfer, Michael wrote:
>>You all are giving excellent information in this mailing list, thanks
>>a lot! 
>>I guess my problem is - as you describe - that the component is still
>>active, even if smtpQuit has been reached within OnRequestDone. I
>>don't currently check if it's still connected, but I will change it.
>>Errors will be checked and force to abort the entire mail and write
>>some log entries.    
>>As Arno said earlier, I'd like to have async components because of
>>their benefits. But in fact, for me it is a sync call, at least for
>>each single mail. IOW, I've to wait until each particular mail has
>>been finished before I'm advancing to the next one. So I'm starting
>>with Connect(), let the OnRequestDone do the background stuff and set
>>a flag if either aborted or quit. Now I know I've to wait also for
>>not Connected. But what's the correct method to wait for completion?
>>Currently, I have a loop after calling Connect() looking like this:  
>>while not FlagDone do begin
>>  //Application.ProcessMessages;  // Don't know whether or not to use
>>the message pump here   Sleep(50);
>>Any thoughts?
>>>-----Original Message-----
>>>[mailto:[EMAIL PROTECTED]
>>>Behalf Of DZ-Jay
>>>Sent: Tuesday, January 16, 2007 10:57 AM
>>>To: ICS support mailing
>>>Subject: Re: [twsocket] Still problems while sending SMTP
>>>On Jan 16, 2007, at 02:49, Arno Garrels wrote:
>>>>When the response to the Quit command is received the connection
>>>>(may) still be alive. So watch both, whether Quit response has been
>>>>received as well as the SessionClose event. Call connect only
>>>>after the session has been closed.
>>>>Don't start a loop directly from an event handler but post a custom
>>>>message to some Window, in it's message handler start the next loop.
>>>You could, in fact, re-use the connection if the next message
>>>is to be
>>>sent through the same server.  All you have to do is, after the DATA
>>>command is completed and the server acknowledges receipt, check
>>>SmtpCli.Connected, if you are still connected then reset your
>>>state-machine to start the cycle fromthe MAIL FROM command.  Some
>>>servers required a "reset" (RSET) command be sent to reset state, and
>>>it doesn't hurt to send it anyway.  The important thing is to
>>>check the
>>>connection, because something may have happened -- and indeed, some
>>>servers have anti-spamming filters that will kick you out after
>>>receiving DATA that they determine is spam, and some won't
>>>allow you to
>>>re-send after one message.  So the algorithm would be something like:
>>>1. Connect
>>>2. HELO
>>>4. RCPT TO
>>>5. DATA
>>>6. If connected:
>>>6.a (yes) RSET then back to 3
>>>7. QUIT
>>>8. back to 1
>>>Of course, you should check for errors after each step (in
>>>OnRequestDone, before changing states).  Keep in mind that
>>>some errors
>>>are recoverable (transient: 400+), some errors are not
>>>500+), and some are somewhere in between (like RCPT warnings, etc).
>>>Recoverable errors allow you to try again, or require a RSET
>>>and start
>>>from step 3, while non-transient errors require closing the
>>>and starting from scratch.  If you are sending general messages to
>>>strange servers "in the wild" it gets pretty complicated, specially
>>>when you factor in all the non-RFC-compliant servers; but if your
>>>application is of limited purpose, sending using the same server all
>>>the time, the errors and issues that may occur are predictable and
>>>substantially less.
>>>Building this logic in a simple state-machine using
>>>OnRequestDone makes
>>>it fairly easy to make your application powerful and efficient -- the
>>>reason we always push for the use of async methods.
>>>DZ-Jay [TeamICS]
>>>To unsubscribe or change your settings for TWSocket mailing list
>>>please goto
>>>Visit our website at

To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at

Reply via email to