Bare with me, my [u]VB6[/u] 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]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[/code]

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

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.

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.

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! ;)

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.

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

It 'pwns' now.

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.

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]If fso.FileExists(strPathFileName) = True Then
'do stuff with file
Else
'handle not having the file
End If[/code]

instead of

[code]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[/code]

Ok, thnx