Archived Forum Post
Index of archived forum posts
Question:
Archived Forum PostQuestion:
My system pops roughly 100 mailboxes, each potentially containing a couple hundred email. I'm attempting to pull the mail by first obtaining the number of messages in a mailbox, then retrieve each of them by message number. My problem is the "email" object is never created. It seems simple enough ..... what am I missing. My code follows. Thanks in advance.
Dim mailMan As New ChilkatMailMan2
Dim email As ChilkatEmail2
Dim success As Long
Dim i As Long
Dim numMessages As Long
mailMan.UnlockComponent("my auth code")
mailMan.MailHost = "my smtp host"
mailMan.PopUserName = "my username"
mailMan.PopPassword = "my password"
numMessages = mailMan.GetMailboxCount()
If (numMessages > 0) Then
For i = 1 To numMessages
Set email = mailMan.FetchByMsgnum(i)
If email Is Nothing Then
MsgBox mailMan.LastErrorText
End
else
fname$ = email.GenerateFilename
fname$ = "c:\temp\aa\" & fname$
fnum% = FreeFile
Open fname$ For Output As fnum%
Print #fnum, email.GetMime()
Close fnum%
endif
Next
End If
A NULL / Nothing return value indicates the method call failed. Examine the contents of the LastErrorText property. Also, the amount of information in the LastErrorText is likely to be too large for a MsgBox. If it is truncated, make sure to get the full contents of the LastErrorText in some other say, such as displaying it in a text box capable of holding more information (w/ scroll bars, etc.)
Post the contents of the LastErrorText here. (Enter code and lastErrorText inside html <pre> / </pre> tags to make them readable.)
Hopefully this will help .... the many thanks for the support. This should be so easy, so it's not clear why it's failing. I'm expecting that I should be able to check a mailbox, determine the number of email in the mailbox, then retrieve them one at a time, saving the email to disk. Thanks again.
/
ChilkatLog:
FetchByMsgnum:
DllDate: Apr 17 2012
UnlockPrefix: BERKUTMAILQ
Username: L_JBOUMA:boumaj
Architecture: Little Endian; 32-bit
Language: ActiveX
msgnum: 1
Success.
--FetchByMsgnum
--ChilkatLog
the crazy thing is that I can use FetchSingleHeader, specifying that I want the first 500000000 (500 million) lines and it works - allowing me to essentially fetch an entire message - a work-around
works - saving the entire email as a .eml file Set email = mailMan.FetchSingleHeader(500000000, i&)
when I use set email = mailman.FetcyByMsgnum (i&) all I get is the following - which is the descriptor of the message - not the message itself.
MIME-Version: 1.0 Date: Fri, 11 Jan 2013 13:42:19 -0500 Message-ID: <942F36F9E2B13EF6667AA282A974332397E683CD@L_JBOUMA> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal)
The FetchByMsgNum documentation states:
IMPORTANT: A POP3 connection must first be established by either calling Pop3BeginSession explicitly, or implicitly by calling some other method that automatically establishes the session. This method will not automatically establish a new POP3 session (because if it did, the message numbers would potentially be different than what the application expects).
I don't see a call to Pop3BeginSession in your code snippet, but I don't know if explicitly calling it will help anyway since you are getting a partial result. This seems to imply that you have a connection, but it might be worth a try to call Pop3BeginSession explicitly.
I can see from the LastErrorText contents that you are using an older version. The line "DllDate: Apr 17 2012" is what identifies it.
I would recommend testing with the latest version (v9.4.0). I checked the internal implementation, and all mailman methods that fetch full emails do so by calling the same internal method. The only difference is in whether a UIDL or msgnum is passed by the application. In the case of UIDL, Chilkat must first convert it to a msgnum and then call the same internal method that is called directly by FetchByMsgNum. For this reason, I would think it unlikely that a problem like this exists within Chilkat -- because it would imply that all POP3 methods that fetch full emails would be broken. Chilkat has a large user base and there are no other problem reports on the subject. Regardless, even though I think it unlikely, if you wish, please post the LastErrorText using the latest version and I'll be happy to have a look.
This is very frustrating, and it should be so simple.
I've updated the DLL and dont see a difference.
I successfully open the POP3 session and determine the
number of email in the mailbox. I then go into a "For" loop
pulling the email, from 1 to NumberMessages
I retrieve the same mailbox using two different methods (independantly),
using the lines of code shown below, using the same "email" object.
I'm not mixing methods - I'm using one or the other of the
options below - but not both
- Option 1 - using FetchByMsgNum
set email = mailman.FetchByMsgNum(i)
- option 2 - using FetchByUIDL
set email = mailman.FetEmail(uidl)
I'm successfully completing the action (the fetch) using either
option 1 or option 2.
I then attempt to write the email object to a file using the exact same
line of code in either option
Print #fnum, email.GetMime()
When using option 1 for retrieving the email, all I get are essentially
the same lines. They differ for each file, but I ONLY get these lines
MIME-Version: 1.0
Date: Fri, 25 Jan 2013 17:59:35 -0500
Message-ID: <7942980C64DFDD0510F7D8DC7EA9541B3EE13884@L_JBOUMA>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
When I use option 2 for retrieving the email, the file that's saved on the disk
contains the entire email.
What am I missing? I'm opening the same connection, using the same
object names, using the same code for saving to disk. The ONLY difference is the
single line of code that actually retrieves it from the server.
In my case the .FetchEmail works, while the FetchByMsgNum doesn't.
by the way - thanks for the assist - I appreciate it. I've tried explicitly opening the connection using the .Pop3BeginSession action - but it made no difference.
All - thanks for the viewing / support. It turns out a new release of the activex fixed the issue. I wasn't crazy after all. :)