I now have a method called from 4D my_email
`my_email
$$hostname:="smtp.mac.com"
$msgFrom:="my_email account"
$msgTo:="someonesemail"
$subject:="Automatic Email Response from registration site"
$message:="You have received this email because "+[name]First+" "+[name]Surname+" "+[name]Email+"has just registered."
$error1:=POP3_Login ($hostName;mylogin;mypassword;1;pop3_ID)
$error2:=SMTP_QuickSend ($hostName;$msgFrom;$msgTo;$subject;$message)
$error3:=POP3_Reset (pop3_ID)
The email actually works the correct information is sent via email but I get a 'The Script timed out.' message from Active 4D
Any ideas welcome
Graham,
The problem may be that most 4D Internet Commands routines run syncronous. Unless things have changed my experience has always been that the Email commands exhibit this behaviour (although I've heard this has improved somewhat in 4D 2003). This means that when called, the 4DIC commands don't yield back to 4D (or Active4D) until they have completed. This effectively stalls the web process w/in which Active4D is running, be it 4D, ITK, or TCPsd. If you have a slow connection to your SMTP server, or that server is unresponsive, what you are experiencing can easily happen.
Try this:
$$hostname:="smtp.mac.com" `<== I assume the $$ is a typo in your message?
$msgFrom:="my_email account"
$msgTo:="someonesemail"
$subject:="Automatic Email Response from registration site"
$message:="You have received this email because "+[name]First+" "+[name]Surname+" "+[name]Email+"has just registered."
$ms = milliseconds
$error1:=POP3_Login ($hostName;mylogin;mypassword;1;pop3_ID)
$error2:=SMTP_QuickSend ($hostName;$msgFrom;$msgTo;$subject;$message)
$error3:=POP3_Reset (pop3_ID)
$ms = milliseconds - $ms `how many milliseconds did it take to do the email stuff?
alert ("Email processing took "+$ms/1000 + "seconds". ) `For debugging. You could alternately write this to a log file if you don't
`want to throw up an alert on the server.
The timing code will show you if slow email processing is source of your problem. That said, I would strongly recommend that that you create a table in the database called [Queued_Email] and have Active4D write a message record to this table. Have 4D run a background process that routinely queries this table for unsent records. If any are found have 4D send them in the background. The delay will still exist in the code, but having it run inside 4D in another now-web process will insulate Active4D. Even better, if you are running Active4D in a Client/Server environment have another client send the email messages. As an alternative you could have 4D run a paused background process, and have my_email pass the email message contents to this process and wake it. After it send the email the process would pause itself and wait for the next 'message' to send email. The key to either of these techniques is that your Active 4D code can quickly compose the message information and hand it off to another process to do the work of actually sending email.
A simpler solution might be to upping the script time in Active4D.ini. The default is 30 seconds. Try 60. However, 30 second or longer response times in a web environment is totally unacceptable. If your user submits the form and doesn't see a speedy reponse they may go elsewhere, quit their browser (thinking something is wrong) or repeatedly re-submit the form unless you can provide some type of status mechanism which might be difficult or impossible given the synchronous nature of the 4DIC commands.
hth,
Brad
Graham
_______________________________________________ Active4d-dev mailing list [EMAIL PROTECTED] http://aparajitaworld.com/mailman/listinfo/active4d-dev
