Not Looping, or so I think

[CrAz3D]

Bare with me, my VB6[/u][/i] coding is sloppy.

For some reason this will not loop through & change the entire userlist when I use wildcard.  If I use specific username it will loop through, find the name & make the correct changes.

When using wildcard it only finds the FIRST username & changes it.

Code Select Expand

Dim strAcUs As String, CurAc As String, newFlag As String, DoneFlags As String, der As String, UserList As String, DoneUser As String, Olduser As String, OldFlags As String
   Case "setuser", "set"
   On Error GoTo err0r1
   Msg() = Split(pA(1), " ")
   der = Dir$(App.Path & "\database.txt")
           If der = "" Then
               Close #9
               Open (App.Path & "\database.txt") For Output As #9
               Close #9
           End If
           Open (App.Path & "\database.txt") For Input As #9
           Do Until EOF(9)
       On Error GoTo err0r1
               Input #9, CurAc
                   If CurAc <> "" Then UserList = UserList & vbCrLf & CurAc
               Loop
               Close #9
               
err0r1:
CurAc = ""
               Open (App.Path & "\database.txt") For Input As #9
           Do Until EOF(9)
               Input #9, CurAc
                   Re = Split(CurAc, " ")
                       If LCase(Re(0)) = LCase(Msg(0)) Or LCase(Re(0)) Like LCase(Msg(0)) Then
                           OldFlags = Re(1)
                           Olduser = Re(0) & " " & Re(1)
                           Call GetAccess(intAccess, Re(0))
                               newFlag = Right(Msg(1), Len(Msg(1)) - 1)
                               If Left(Msg(1), 1) = "+" Then
                                   DoneFlags = OldFlags & UCase(newFlag)
                                   DoneUser = Re(0) & " " & DoneFlags
                                   SendW Re(0) & " => " & DoneFlags, strAccount
                               Else
                                   If InStr(1, newFlag, OldFlags) = 0 Then
                                       DoneFlags = Replace(UCase(OldFlags), UCase(newFlag), vbNullString, , , vbTextCompare)
                                       DoneUser = Re(0) & " " & DoneFlags
                                       SendW Re(0) & " => " & DoneFlags, strAccount
                                   End If
                               End If
                   On Error GoTo err0r
                               UserList = Replace(UserList, Olduser, DoneUser, , , vbTextCompare)
                               While Left(UserList, 2) = vbCrLf
                                   UserList = Right(UserList, Len(UserList) - 2)
                               Wend
                               Close #9
                       
                               Open (App.Path & "\database.txt") For Output As #9
                               Print #9, UserList
                               Close #9
                               'Exit Sub
                       Else
                       End If
           Loop
       Close #9
   
err0r: 'AddChat vbRed, "Setuser Part II: " & Err.Description

pa(1) being the msg the bot received (ie *xl* +FLI)

[o.OV]

Extensive use of "On Error" CANNOT BE A GOOD THING.
Where did you get the GetAccess Sub from..
your example has no reference to intAccess.
And yes.. your coding is really sloppy

I STRONGLY SUGGEST THAT YOU STOP USING "On Error .." ~ !

you opened a file before a loop
you went into a loop
closed the file part way into the loop
then opened the file again from inside the loop
then you closed the file
and the loop returned it to the beginning
where it errored because you were refering to a file that was not open
and thanks to "On Error .."
It sent you to the very end
and you never knew what hit you.

[Grok]

I use On Error in multitudes of situations in my programs.  To say I use it extensively is an understatement.  Using the On Error statement provides control over where and how I want to handle situations.  For example, there are situations where you rely on subscript out of range errors, or file not found, or permission denied.  It is far easier to write VB code to trap permission denied than it is to detect whether a particular function has the required credentials, and that another process is not going to block your action.

It is not good to say On Error is always bad, or even mostly bad.  Like anything, if you misuse something, it can be bad.

[Adron]

I find On Error statements that regularly trap errors to be very annoying. Making code do that is what I hate the most about the VB Collection.

Good code shouldn't go throwing exceptions about non-exceptional events!

[Grok]

While I agree, it is what we have in VB6, and I believe in using the supported, available tool to accomplish my objectives.  I cannot deviate too far from retail VB6EE package, because I am not writing the code for myself, but for a company that places standards on what I write.  It has to be supportable by just about any other VB6 programmer they hire.

[CrAz3D]

My code was too sloppy, I re-wrote it all & using an interfacial DB.

It 'pwns' now.

[Adron]

Ah of course you should just regular language constructs. I just mean that you should strive to design code that avoids trapping errors all the time.

If you can check for a possible error condition before you do something, do so, instead of trying to do it and only trapping the error afterwards. You should obviously trap errors too, just not trap them always.

On example of annoying code is using "Kill" to kill a file that may not exist, handling the error if it doesn't exist instead of checking for existance first.

[Grok]

Again, agreed.  Now since a great portion of my programming is against shared databases on servers, error trapping is essential.  You simply don't write code to check if you're going to have an error before you actually do.  For one, you cannot know what triggers might do, what constraints might be on your data, and what state your tables are in.  Other users might have locks on your page, row, table, database, that might block you infinitely.  This could be one reason why I have extensive On Error usage, but there are other examples equally valid.

As you said, when you can check for a prerequisite condition instead of relying on an error, it is usually better.

Code Select Expand

If fso.FileExists(strPathFileName) = True Then
   'do stuff with file
Else
   'handle not having the file
End If

instead of

Code Select Expand

On Error Resume Next
fNum = FreeFile
Open strPathFileName For Input As #fNum
Select Case Err.Number
Case 0:  'Do stuff with the file existing
Case ERR_FILENOTFOUND:   'handle not having the file
End Select

[CrAz3D]

Ok, thnx