RESOLVED - Suggestions to resolve Runtime Error 75 path/file access denied

Hey guys,

Need your help in solving this problem.

My program executes a function once every 2 minutes. When this happens, my code further down below writes an entry into a text file. This occurs every 2 minutes indefinitely.

Everything works fine until day 7. On the 7th day this error appears "Runtime Error 75 path/file access denied". The error occurs on this line...

Open app.path & "\Logs\Bin\" & "Log these details here.txt" For Input As #xfilenumbr

'Here's my full code

Private Sub Timer31_Timer()

Timer31.Enabled = False

Dim xfilenumbr As Integer
xfilenumbr = FreeFile

dim abc as string
dim xyz as string

dim sttr as string
sttr = WeekdayName(Weekday(Now, vbUseSystemDayOfWeek), _
False, vbUseSystemDayOfWeek)


'opens the txt file and reads all the existing entries into the list2 box
List2.Clear
Open app.path & "\Logs\Bin\" & "Log these details here.txt" For Input As #xfilenumbr
Do While Not EOF(xfilenumbr)
Line Input #xfilenumbr, xyz
List2.AddItem xyz
Loop
Close #xfilenumbr

'deletes the txt file and all of its contents from the Bin folder
abc = app.path & "\Logs\Bin\" & "Log these details here.txt"
Kill abc

'Recreates a new empty Log these details here.txt file into the Bin folder
Open app.path & "\Logs\Bin\" & "Log these details here.txt" For Output As #xfilenumbr
Close #xfilenumbr


'If the entries in the list2 box are 1000 or more, the list2 box entries are cleared and the most recent entry is added to the file.

If List2.ListCount > 1000 Then

List2.Clear
Open app.path & "\Logs\Bin\" & "Log these details here.txt" For Append As #xfilenumbr
Print #xfilenumbr, "-This process completed successfully on" & " " & sttr & "," & " " & Now & "."
Print #xfilenumbr, " "
Close #xfilenumbr

Else
'If the entries in the list2 box are less than 1000, the most recent entry is added to the top of the file and the remaining list2 box entries are then appended below that entry.

Open app.path & "\Logs\Bin\" & "Log these details here.txt" For Append As #xfilenumbr
Print #xfilenumbr, "-This process completed successfully" & " " & sttr & "," & " " & Now & "."
Print #xfilenumbr, " "

For r = 0 To List2.ListCount - 1
Print #xfilenumbr, List2.List(r)
Next
Close #xfilenumbr

List2.Clear

End If

End Sub

I'm using an admin account for my testing and all works fine for 6 days straight. I cant figure out why the code throws the error on day 7. If anyone has any insight or another method to write/read the text file, Id really appreciate the help.

Thanks,

Patrick

Error 75 path/file access denied normally means you don't have admin rights to manipulate files in that folder.

Open app.path & "\Logs\Bin\" & "Log these details here.txt" For Input As #xfilenumbr

You have this line three times in your code. If your using FreeFile then show it else it will use the same number each time. ;)

xfilenumbr = FreeFile()

each time you using it.

That doesn't seem to be a copy of your actual code since things like dim aren't capitalized. Can you show us your actual code?

How are you handling errors?

The 'access denied' isn't always related to permissions. Its possible you already have the file open or locked.
Perhaps something caused an error 2 minutes ago and left the method before calling Close#. Then when you come back in, 2 minutes later, the file is already open.
Because it is consistantly 7 days, maybe the ACTUAL error is with some date handling/parsing. Is it always 7 days, or is the 7th day always Sunday (or Friday or whatever)
And yes, as Keith suggested, make sure you reset your fileNumber everytime you use it. That could be related to your problem, but that would be very strange that it's every 7 days.


Annnnnnnd... a final thought... to test whether the error is due to process or if it's related to dates... start your program, then set your system date to 7 days later (6 6and 23 hours, or whatever would trigger the problem) Then you have some control on when the problem should fire. If it fires just because you changed the date, I'd check out those functions. (They look right to me, but maybe Im missing something)

does the file get to a specific size every 7 days?

can you open the file from someother vb code /app?
can you open the file in any other application?

Hey Guys,

Thanks for replying.

Keith,

I figured since I was using the Close #xfilenumbr statement, the file number in use would clear each time and then I could reuse it. How do I reset the file number?

MartinLiss,

You're right. per your prompt, please see below...

Golgo1,

I'm not handling errors for this code yet. In the past, I was thinking of adding the On Error GoTo errHandler statement and then use the file Close #xfilenumbr statement but I was hoping to resolve the problem and then use error handling to catch any other errors that may occur which would at least keep the program running.

yes, the file open/lock scenario did cross my mind. So, I tried a static number ie: For Input As #1, close #1 etc. but the problem still happens.

as for as the 7 day situation. The error occurs on the 7th day from program startup. so it can occur on any day of the week. It also occurs at diffferent hours on the 7th day.

Pete,

I would have to test out and come back with the results. Which I'll definitely do but was hoping to try a possible fix first.

Code:

---

Private Sub Timer31_Timer()

Timer31.Enabled = False

Dim xfilenumbr As Integer
xfilenumbr = FreeFile

Dim abc As String
Dim xyz As String

Dim spath As String
spath = App.Path

Dim sttr As String
sttr = WeekdayName(Weekday(Now, vbUseSystemDayOfWeek), _
False, vbUseSystemDayOfWeek)

List2.Clear
Open spath & "\Logs\Bin\" & "POP3 Connection Log.txt" For Input As #xfilenumbr
Do While Not EOF(xfilenumbr)
Line Input #xfilenumbr, xyz
List2.AddItem xyz
Loop
Close #xfilenumbr

abc = spath & "\Logs\Bin\" & "POP3 Connection Log.txt"
Kill abc

Open spath & "\Logs\Bin\" & "POP3 Connection Log.txt" For Output As #xfilenumbr
Close #xfilenumbr

       
If List2.ListCount > 1000 Then

List2.Clear
Open spath & "\Logs\Bin\" & "POP3 Connection Log.txt" For Append As #xfilenumbr
Print #xfilenumbr, "-This POP3/Single PC mode computer successfully logged into the remote POP3 email account on" & " " & sttr & "," & " " & Now & "."
Print #xfilenumbr, " "
Close #xfilenumbr

Else

Open spath & "\Logs\Bin\" & "POP3 Connection Log.txt" For Append As #xfilenumbr
Print #xfilenumbr, "-This POP3/Single PC mode computer successfully logged into the remote POP3 email account on" & " " & sttr & "," & " " & Now & "."
Print #xfilenumbr, " "

For r = 0 To List2.ListCount - 1
Print #xfilenumbr, List2.List(r)
Next
Close #xfilenumbr

List2.Clear

End If

spath = vbNullString
sttr = vbNullString

abc = vbNullString
xyz = vbNullString

End Sub

---

please use code or highlight tags to display code
how big does your file get by the 7th day?

i seem to remember from somewhere, any open files are implicitly closed at the end of a procedure
close without filenumber will close all

Pete,

got it.

Im not sure on the file size as I'll need to re-run the program again for a full 7 days.

Thanks for the Close approach. I now have that working at the bottom of the sub





Patrick

I added Code tags around your code that you posted above but since you don't use indenting it doesn't help much. Here is how most people would format your code to make it easier to read.

Code:

---

Private Sub Timer31_Timer()

Timer31.Enabled = False

Dim xfilenumbr As Integer
xfilenumbr = FreeFile

Dim abc As String
Dim xyz As String

Dim spath As String
spath = App.Path

Dim sttr As String
sttr = WeekdayName(Weekday(Now, vbUseSystemDayOfWeek), _
False, vbUseSystemDayOfWeek)

List2.Clear
Open spath & "\Logs\Bin\" & "POP3 Connection Log.txt" For Input As #xfilenumbr
Do While Not EOF(xfilenumbr)
    Line Input #xfilenumbr, xyz
    List2.AddItem xyz
Loop
Close #xfilenumbr

abc = spath & "\Logs\Bin\" & "POP3 Connection Log.txt"
Kill abc

Open spath & "\Logs\Bin\" & "POP3 Connection Log.txt" For Output As #xfilenumbr
Close #xfilenumbr

       
If List2.ListCount > 1000 Then

    List2.Clear
    Open spath & "\Logs\Bin\" & "POP3 Connection Log.txt" For Append As #xfilenumbr
    Print #xfilenumbr, "-This POP3/Single PC mode computer successfully logged into the remote POP3 email account on" & " " & sttr & "," & " " & Now & "."
    Print #xfilenumbr, " "
    Close #xfilenumbr

Else

    Open spath & "\Logs\Bin\" & "POP3 Connection Log.txt" For Append As #xfilenumbr
    Print #xfilenumbr, "-This POP3/Single PC mode computer successfully logged into the remote POP3 email account on" & " " & sttr & "," & " " & Now & "."
    Print #xfilenumbr, " "

    For r = 0 To List2.ListCount - 1
        Print #xfilenumbr, List2.List(r)
    Next
    Close #xfilenumbr
   
    List2.Clear

End If

End Sub

---

I left out the setting of the string variables to vbNullString as VB initializes local variables each time the sub is run so you doing it is totally unnecessary.

BTW how often is that timer run?

Quote:

---

Originally Posted by techsent

Keith,

I figured since I was using the Close #xfilenumbr statement, the file number in use would clear each time and then I could reuse it. How do I reset the file number?

---

Just set it again before you use it.

xfilenumbr = FreeFile()

There maybe another part of your program thats using xfilenumbr that you're forgotten about. As stated just using just the Close statement will close all files your app has open.

But it still comes down to the original question. An Error 75 means you don't have admin rights to deal with files in that folder.

I'm not sure what this 7 days bit means? Are you trying to open and change these files on different days? ;)

I believe what he is saying is that once the program is started that it runs constantly and that for example if he starts it on a Monday it fails the next Monday, or if he starts it on a Wednesday that it fails the next Wednesday, etc.

techsent: Could you zip up and attach your whole project please?

Thanks MartinLiss. Yes, it runs every 2 min 8 sec.

Right on Keith. I have it in there now.

Attached is the project. Go through the Readme.txt file to get it up and running.

Patrick

I haven't run your program but I've noticed several things.

1) There's no need to have 3 timers just so you can have a 2 min 8 sec interval. Just use one timer with an interval of 32 seconds and do this instead.

Code:

---

Private Sub Timer1_Timer()
Static intCount As Integer

intCount = intCount + 1

If intCount = 4 Then
    ' Do your processing or call a sub. The Interval for this timer is 32000 (32 seconds)
    ' so your code will run every 2 Min 8 seconds (4 x 32 seconds)
    Debug.Print Now
    ' Restart the count
    intCount = 0
End If

End Sub

---

2) Variables like sttr defined globally at the top of the form should be defined using Private rather than Dim. That's just a matter of style but Private is the more "modern" way of doing things. More important however is that you also have an sttr defined locally in Timer31_Timer and that's not a good thing to do since any reference to sttr in that sub refers only to the sttr in that sub and not the global one and you (or someone else maintaining your code) may not realize that.

3) As I mengtioned in a previous post, variables don't need to be initialized at the end of subs. VB will do that for you the next time the sub is run.

4) You have a sub that looks like this:

Code:

---

Private Sub Winsock1_Close()

On Error GoTo errHandler

username = vbNullString
password = vbNullString


Exit Sub

errHandler:

username = vbNullString
password = vbNullString

spath = App.Path
sttr = WeekdayName(Weekday(Now, vbUseSystemDayOfWeek), _
                    False, vbUseSystemDayOfWeek)
                   
Dim hFile As Integer
hFile = FreeFile()
                   
List2.Clear
Close #hFile
' and a lot more code

---

There's no reason to have an error handler in that sub because there's no way that setting username and password to vbNullString is going to cause an error, and even if it did you have the same code in the error handler which would be a problem if setting those variables to vbNullString did cause an error.

(I've got more to say but I'm going to post this now since my computer is acting up.)

4) You don't need spath, just use App.Path directly. You could however do something like Private sErrorLogPath As String and Private sConnectionPath As String at the top of the form and then in Form_Load do sErrorLogPath = App.Path & & "\Logs\Bin\POP3 Error Log.txt" and sConnectionPath = App.Path & & "\Logs\Bin\POP3 Connection Log.txt" and then every other place you want to open one of those files just do for example Open sErrorLogPath For Input As #xfilenumbr.

Hey Martin,

Thanks for your guidance on this. I've implemented all of your corrections.

I variated a bit on the timer1 code because I think timer31 should only fire when the login was successful. So the timer1 code fires the login sequence only.

re: vbnullstring, about 3 months ago, I was getting really frustrated with the winsock data arrival event because after 4 days of continuously running I would get the 10055 Out of buffer space error.
So I ended up changing the Dim statements in that event to Static and then added the vbnullstring to all the strings in the project thinking I wasn't clearing the string variables thus the error would occur.
Based on your prompt, Im thinking the Static change made the difference because the error no longer appears. Then I thought I was home free til the error 75 problem.

I've started the program about 15 min ago for the new test, so I'll report back next Sunday if the error appears or Monday on the 8th day.

Again, I appreciate everyones help.

Thanks,

Patrick

Hey guys,

Here's the status...

On saturday (day 6), an error 53 file not found message appeared. I checked the Bin folder and both files were still present. The POP3 connection log.txt files was 51kb in size.

Unfortunately, I didn't run the test in VB so I don't know what line of code generated the error.

Based on the error message and that the file is still present, Im guessing that it may the Close statement so I removed it. Also for the freefile () entry, I added a rangenumber thinking that it may help. ie: freefile (50).

Now, I running a new test (inside of VB this time). I'll report back again in a week.

Thanks,

Patrick

The Close statement closes all files so unless you inadverently closed a file that you needed to be open, it probably isn't that. FreeFile generates an (unused) integer so unless you had 32767 files open, which of course is unlikely, it's probably not that either.

I just checked and the FreeFile limit is a lot smaller than I thought. If you try to open more that 255 files, FreeFile will generate error 67.

Hi Martin,

Thanks for replying and your info.

Yes, I'm not too confident about my changes. I figured the freefile () and Close statements aren't the problem. changing code and hoping just doesn't replace the methodical/logical approach.

Admittedly, I've been working on my main project for over 2 years now and the problem in this thread is the last hurdle. As a result, Ive been fighting a loss of enthusiasm and frustration for quite awhile now.

I was thinking of trying to use the Binary Lock Read Write As #nFileNum method instead of what I have. What do you think?

Techsent

Sorry but I have no idea if Binary Lock Read Write would affect anything.

Could you attach your project again please?

did you try any of the suggestions i made in post #5?

when the error occurs, copy the file to someother location
make a simple program in vb to open the file, also the copy file, see if either will work
try opening the file in word, notepad or some application

i doubt that it was a problem with your code, even the original version

can you start a new file every 6 days so that it never gets to the point of error?

Hi Martin,

I would really like to attach my main project but I plan on selling the compiled exe's so unfortunately, I can't broadcast my code to the public. I know it's a catch 22 because its tough to assist someone when you don't have the whole project to look through.

Pete,

I didn't but I definitely will this time. Im on day 3 so I'll have the answers in a few more days.

Thanks,

Patrick

I am not sure what your updated code but when you are closing the filenumber then before you use it again it is better to still get the FreeFile.

Code:

---

xFileNumbr = FreeFile
    Open sPath & "\Logs\Bin\" & "POP3 Connection Log.txt" For Output As #xFileNumbr
    Close #xFileNumbr

---

And so on.

Quote:

---

Originally Posted by dee-u

I am not sure what your updated code but when you are closing the filenumber then before you use it again it is better to still get the FreeFile.

Code:

---

xFileNumbr = FreeFile
    Open sPath & "\Logs\Bin\" & "POP3 Connection Log.txt" For Output As #xFileNumbr
    Close #xFileNumbr

---

And so on.

---

Yes I've mensioned this before Dee. ;)

Guys,

okay, day 6, The error 53 file not found message appeared again and was generated on the bolded line.

Code:

---

abc = sConnectionPath
Kill abc

---

I spoke with Martin and the abc string value was removed and the code is now modified like this...

Code:

---

Kill sConnectionPath

---

I also added the Close statement back in and left the freefile (50) as is.

Ive just started a new test.

Pete,

"when the error occurs, copy the file to some other location make a simple program in vb to open the file, also the copy file, see if either will work try opening the file in word, notepad or some application."

I was able to open the file using another vb app and also within notepad with no problems.

"can you start a new file every 6 days so that it never gets to the point of error?"

great idea and I'll definitely implement it as a workaround.

Techsent

Any problem with me attaching a modifed Form1 from the POP3 Connect folder? I made a number of changes all of which are marked with 'Marty so you can find them easily.

I also added some questions and comments in the code. In addition to those I strongly suggest you use meaningful names for your forms and controls rather
the default Form1, Combo1, etc names. When you name global or form level variables you should also name them for example mintCurrentMessage rather
than intCurrentMessage (they should also be Private rather than Dim) to indicate that it's a form-level variable and if you had global variables
(which would be Public rather than Dim) in one of your code modules they should be prefixed with a g, so gMyVar rather than MyVar. I am also curious
why you need 16 timers in the server portion of the app.

I've been watching this thread for some time and thought I may be able to make a contribution...

I think that the Winsock 10055 error may be the root of the problem. It is indicative of a lack of system resources. When associated with a long running application such as yours it may mean that you are not releasing memory and you're eventually starving the application. Alternatively the application may be leaking memory and after 6 days you've 'run out'. The result of this may be an almost 'random' error such as the one you're experiencing (after all, you do have access to the file, so the error message may be / is misleading you)

Making the change you did to 'resolve' the 10055 error has, perhaps, just allowed the problem to manifest itself somewhere else.

Trying to find what's eating up memory is not easy. If my theory is right you should see a steady increase in Working Set size during the running of the application, although if it's associated with the Winsock Buffers you may not see it, as the internal buffers use non-paged memory. It may be worth using Task Manager to monitor it.

I noticed some other 'issues' with the code you posted:
In the DataArrival event:

Code:

---

Static strData1            As String
Winsock1.GetData strData1, vbByte

---

vbByte should be vbString.

and there's an 'orphan' Close statement in the DataArrival event:

Code:

---

For r = 0 To List2.ListCount - 1
 Print #hFile, List2.List(r)
 Next
Close #hFile
Close

---

Also, I see some DoEvents which are not needed. If you want to make sure that the "QUIT" command has been sent before you close the Socket you should use the SendComplete event to signal rather than rely on DoEvents. If I was being really picky I'd point out that DoEvents is a Function which returns an Integer value (the number of currently open Forms in the Application)

Code:

---

Dim intF As Integer
.
.
intF = DoEvents
.

---

but I think I'm going over the top on that !!!

Saying all that, I doubt if any of those issues are causing the problem but with memory issues which manifest themselves after 6 days it could be something quite trivial.

Have you reduced the number of Timers as Martin has suggested? I think life would be made a lot easier if you reduced the number of asynchronous events to a minimum to avoid the possibility of "events-within-events" which can cause unpredictable results.

No problem, That would be great. Thanks for the info on Dim etc..., I'll action on my end.

Yes, I do use alot of timers :o. I mainly use them as events. Once a specific action has occurred in the app, the timers turn on then turn off again. I figured since the timer intervals usually start a few seconds after the specific action has occurred/completed in the app, it would be ok.

Timer8_Timer() runs continuously because it's checking the registry for the newest data to send to the network clients. Once the data is detected, the timer event also broadcasts the data to those connected clients.

Hey Doogle,

Thanks for chiming in. I've reverted vbByte back to vbString. I had previously changed it to byte thinking it may have been part of the 10055 error. That 10055 error has been tough. I worked on that problem for a couple of months and finally the latest code worked for 17 days straight before I ended the test. The error would always appear after running it for 3 days.

Yes, the orphaned Close entry was added to ensure that all open file numbers were closing.

Your memory comments sounds like a definite possibility. I have monitored taskman in the past and while the working set value does rise via pop3 login it appears to drop off and remain steady until the next login.

The Timers that Martin mentioned are in another sub project which isn't used for the testing of the attached project in this thread. Please see my comments above.

I appreciate the DoEvents details. Here's my modification.

Code:

---

Private Sub Winsock1_DataArrival(ByVal bytesTotal As Long)

SaveSettingString HKEY_CURRENT_USER, "Software\System Pitstop", _
      "quitwinsock", _
        "1"
                   
m_State = POP3_QUIT
Winsock1.SendData "QUIT" & vbCrLf
'DoEvents
'moved to Winsock1_SendComplete()
'winsock1.close

---

Code:

---

Private Sub Winsock1_SendComplete()

Dim hhg As String
hhg = getstring(HKEY_CURRENT_USER, "software\System Pitstop", _
        "quitwinsock")

If hhg = "1" Then

  SaveSettingString HKEY_CURRENT_USER, "Software\System Pitstop", _
      "quitwinsock", _
        "0"
       
  Winsock1.Close

Else

  SaveSettingString HKEY_CURRENT_USER, "Software\System Pitstop", _
      "quitwinsock", _
        "0"

End If

End Sub

---

Talking of DoEvents, I had a peculiar encounter a couple of years ago on Vista. This piece of info might or might not have a direct relevance to your current case, given here just for your longshot reference.

In my viewport user control, I had something like this:

PicDisp_MouseDown
.....
Action1
Action2
.....

For a certain reason, I had to add a DoEvents between Action1 and Action2. Now the system would execute PicDisp_MouseUp before coming back to execute Action2 of PicDisp_MouseDown. (It took me a long time to discover that, but once discovered, a solution was easy). This phenomenon didn't always appear; I now can't recall whether it was depending on how quick the user's mouse action or how long the Action2 took.

Remarks: The specific reason for adding a DoEvents was to enable user to drag (to scroll) picDisp in the viewport on a non-active child form immediately on its becoming active, e.g. there were several child forms on MDI screen and picDisp in the viewport on each form was visible to the user, the user might thus mouse down on any picDisp (to scroll) while making that form active. (Without the said DoEvents, the user would have to click to set focus to that form first, then mouse down to scroll picDisp).

Here it is.

Thanks Martin,

Here's the latest update.

*A new test has now been started with this attachment.

petersen,

Yes, I also found that certain situations where the DoEvents helped. I think whether it helps or creates conflicts may depend on what code it's preceded or appended too.

Techsent

I think you're missing the point of my comment about your hhh variable. The way your code is now your obr9f, a, i, j, and k variables will never contain anything because you fill hhh and then immediately set it to vbNullString. If you don't set it to vbNullString the variables willl all contain the same value. The following is some code that shows both cases. Paste it into a new project and try it.

Code:

---

Dim hhh As String
Dim obr9f As String
Dim obr9a As String
Dim obr9i As String
Dim obr9j As String
Dim obr9k As String

hhh = "fullscan"

hhh = vbNullString

obr9f = Mid(hhh, InStr(hhh, " ") + 1)
obr9a = Mid(hhh, InStr(hhh, " ") + 1)
obr9i = Mid(hhh, InStr(hhh, " ") + 1)
obr9j = Mid(hhh, InStr(hhh, " ") + 1)
obr9k = Mid(hhh, InStr(hhh, " ") + 1)

MsgBox obr9f
MsgBox obr9a
MsgBox obr9i
MsgBox obr9j
MsgBox obr9k

'do it again without the vbNullstring line

hhh = "fullscan"

obr9f = Mid(hhh, InStr(hhh, " ") + 1)
obr9a = Mid(hhh, InStr(hhh, " ") + 1)
obr9i = Mid(hhh, InStr(hhh, " ") + 1)
obr9j = Mid(hhh, InStr(hhh, " ") + 1)
obr9k = Mid(hhh, InStr(hhh, " ") + 1)

MsgBox obr9f
MsgBox obr9a
MsgBox obr9i
MsgBox obr9j
MsgBox obr9k

---

Regarding this code:

Code:

---

Open sErrorLogPath For Output As #hFile
Close #hFile
       
If List2.ListCount > 1000 Then

    List2.Clear
   
    Close #hFile
    hFile = FreeFile
   
    Open sErrorLogPath For Append As #hFile

---

You don't need to open and immediately close the file in order to create/ set up the file on the hard drive for the list count. Just do the Open sErrorLogPath For Append As #hFile when you need it. VB will create the file if it's not already there even though you specified Append.

Hey Martin,

sorry about that. The hhh variable will not be empty once the keyword is processed from the pop3 email. The code spins through all the emails in the inbox. Once it finds the keyword, the hhh will then contain the keyword.

If you run the whole project, it will give a demo.

Thanks. I've changed up the code to use append only.

Techsent

Quote:

---

Originally Posted by techsent

Hey Martin,

sorry about that. The hhh variable will not be empty once the keyword is processed from the pop3 email. The code spins through all the emails in the inbox. Once it finds the keyword, the hhh will then contain the keyword.

If you run the whole project, it will give a demo.

Thanks. I've changed up the code to use append only.

Techsent

---

Yes, it will, because you set it to vbNullString immediately after it is filled. And even if that is not the case, all the obr9 variables that I mentioned will have the same thing in them. Is that what you want?

I see what you're saying. when I originally created the main project, I copied the obr9 variables from it into the pop3 connect.

I could have used 1 variable and passed it to main (timer44, timer43).

Techsent

Do you agree about both things I'm saying?

I do indeed.

Techsent

Me again, nothing important to add at this time, but whilst we're eagerly awaiting the latest test results..........

I notice that you do not process the result of sending POP3_DELE. Also there's a couple of DoEvents in parseMSG, I don't think they're doing any harm as parseMSG is not interrupt driven.

Strictly speaking, in the DataArrival event you should not assume you have a complete response from the server when you issue the GetData. You are employing buffering on the RETR but not on any other response. The responses from POP3 are quite short so it's unlikely that they will split into two or more parts, however it is possible which could lead you to report errors when there weren't any, or the application exploding when you try to unblock the count of messages into AmtMessages. (I have, in the past, experienced a 10 byte message being split into two 'parts' by the underlying protocols. ie it took 2 DataArrival events for the complete 10 byte message to arrive)

I would append the data received into strData1 until a carriage return line feed pair had been received and then check for the "+". It's only at that point you know for sure you have a complete response from the server. If you do that you have to clear strData1 after processing the contents.

Perhaps things to put on your "To Do" list after the current problems are resolved.

I'm still worried about the number of Timers and the fact that you have more than one running at the same time.

This next part may be 'off the wall' but I'm still thinking about whether it's possible or not so don't take it too seriously .....

I'm wondering about the accuracy of the Timer control which I believe is about +/- 57mS. In the extreme, if, say, Timer3 is always triggering 'early' then I estimate that after 6 days it would be nearly 4 minutes out - I can't see if and where you stop Timer3. (After 6 days the Timer3 code proper has executed about 4050 times - interesting that it's not too far away from 4096, I wonder if there's a 4K limit to something in VB) If the other timer is running 'late', one may catch the other up.....

As I said, 'off the wall', could be absolute nonsense, but I'm still trying to get my head round it.

Is there any reason why you can't just start a timer, when 2 minutes, or whatever, have elapsed, stop the timer, execute the 'business' code, re-start the timer and go round the loop? That way any inaccuracy of the timer doesn't matter since there's only ever a maximum of 1 timed asynchronous event. You will also process the complete message queue in one hit. (At the moment you have a maximum of 2 minutes to process the queue then you close the socket whether you've finished or not)

Another 'off the wall' thought, if there's some sort of 'issue' with Winsock getting its buffers in a twist, I wonder whether using a dynamic Winsock instance and Unloading it when you've closed it (which should destroy it completely, freeing up internal buffers etc), then Loading a new instance before configuring it for connection, would eliminate any problems. You'd be starting with 'a clean sheet' (wrt Winsock) every time you connected to the server.

eg Define Winsock1 as an array, Load Winsock1(1), use Winsock1(1), Unload Winsock1(1) when you've finished, and repeat.

EDIT: By the way, don't know if it's been asked already but have you got VB SP6 installed? Amongst other things, that SP fixed a few Winsock issues including leaking memory.

The problem with this problem is that you will never know if it's fixed and if it is, how you did it !!! (LOL)

Hey Doogle,

Yes, I decided to not log the POP3_DELE result as its been extremely reliable.

I had to add the DoEvents because the email flagged for deletion wasn't getting deleted after logging out and back in.

Good point on the DataArrival event. I discovered that before using the msgbox command. It would hit many times in one session.

the timer computation conflict is interesting. I'll check into it.

I've been trying to implement your technique Load Winsock1(1), Unload Winsock1(1) but need some guidance. I have set the index properties of winsock1 to 0. Added (Index As Integer) to all winsock code headings. Next, I configed this.

Code:

---

Option Explicit

Public intwinsck As Integer

End Sub

---

During run time, the error hits and displays - error 360 object already loaded.

Code:

---

Private Sub Form_Load()

intwinsck = 0

Load Winsock1(intwinsck)

End Sub

---

Code:

---

Private Sub Timer3_Timer()

m_State = POP3_Connect

'Winsock1(intwinsck).Close
Winsock1(intwinsck).LocalPort = 0
Winsock1(intwinsck).Connect tstring, kevo

End Sub

---

When trying to unload winsock1, I get error 362 - can't unload controls created at design time. I tried the exe but same error.

Code:

---

Private Sub Timer31_Timer()

Unload Winsock1(intwinsck)
End Sub

---

Yes, thanks, I have sp6 installed.

LOL, yes, I was thinking that after implementing everyones suggestions.

Techsent

If at design-time you have Windsock(0) then you cannot load or unload it at runtime, you can just load and unload succeeding indexes eg. 1, 2, 3, etc.