I can only speak for myself but it has been my experience that when PurePop3_OpenPop3Connection() refuses to work it is when the Internet connection is disrupted after a successful connection.
- 1) OpenPop3Connection() connects successfully.
2) Internet connection becomes blocked; rj45 gets unplugged or software blocks the port.
3) Some other PurePop3 function is called, either to get the # of messages, or retrieve a message and naturally it fails.
4) 15 seconds later the PurePop3 experiences a server timeout.
5) Internet connection gets re-established.
And it doesn't seem to help to call PurePop3_CloseConnection().
I suspect there is a boolean variable (called something like alreadyConnected) inside the PurePOP3 library that should (but doesn't) get cleared in the case of a server timeout.
This hypothetical boolean variable might be used to keep track of whether or not a connection has been established.
In this example, upon successfully connecting via PurePop3_OpenPop3Connection(...), the variable alreadyConnected is set to true.
Of course PurePop3_CloseConnection() would set the variable to false.
Picture this:
- 1) PurePop3_OpenPop3Connection(...) successfully connects and sets the hypothetical boolean variable alreadyConnected to true, meaning "we're connected.. yeah baby, yeah."
2) Internet connection is blocked or otherwise disrupted.
3) Some other PurePop3 function is called and errors out.
4) PurePop3 library experiences a server timeout after 15 seconds, but doesn't reset the boolean variable alreadyConnected to false!!!
5) Internet connection is re-established.
Now, if this boolean variable exists and is now erroneously still true, perhaps it is preventing the PurePop3 library from connecting from now on!
The OpenConnection function might read something like this:
Code: Select all
Procedure PurePop3_OpenPop3Connection()
If connected = #False
;attempt to connect
[b]alreadyConnected[/b] = #True
else
;don't connect, we're already connected
endif
EndProcedureEven in a scenario like this, I would think that calling PurePOP3_CloseConnection() would reset the boolean variable.
Thus calling PurePOP3_CloseConnection() first and then calling PurePOP3_OpenPop3Connection() should work!
Still hypothetically speaking of course, it's as if because technically we're not still connected, and thus PurePOP3_CloseConnection() isn't able to fully complete it's desired course of action, the boolean variable alreadyConnected never ends up getting cleared / reset to false.
This would certainly explain why no sequence of calls to PurePOP3_CloseConnection and PurePOP3_OpenPop3Connection() seems to make a difference.
It would also explain why closing the app and reopening it would fix the problem.
In this case, the boolean variable alreadyConnected would finally be initialized to false, thus making it possible to connect once again!
- This is why I was thinking there might be a PurePOP3 function to re-initialize all library variables that would be helpful to know about.
Or if there's a way to ask PureBasic to restart a specific library.
Or a way to fake PureBasic into "thinking" the app was just launched, ie a way to initialize all variables, essentially restarting the app from the beginning, but not having to launch another instance of the app before shutting down the current instance, etc.
Perhaps something (dare I say a 'bug') has crept into the library? :p
A friend of mine recently said, "it sure seems that a development environment these days should come with a fully functional suite of POP3 and SMTP functions."
Sad to say, this could reflect poorly on Pure Basic in general.
Roark[/b]
