Loading Access From A File And Splitting It

[rabbit]

rabbit, your code isn't much better. It just has error handlers which I mistakenly left out.

Your not checking if the file exists.
Your using "#1" which could cause errors if that number is already in use for file handling.
Your not checking the size of strParts() before parsing it. Incase of a corrupt user.txt file.
Your error handling debug printout is a fair overkill.

The line "If UserName <> vbNullString And IsNumeric(UserAccess) Then" is bad coding practise because it can cause problems at times where the compiler may misinterpret this as a binary comparison. A better/more efficient equivalent would be, "If (LenB(UserName) <> 0) And (IsNumeric(UserAccess) = True) Then".

You clearly suck.  IsNumeric() is BOOLEAN meaning it's either TRUE or FALSE.  Checking for true is the same as checking for = true, so it doesn't matter.  As for comparing the UserName variable to vbNullString, it's faster and just as safe as using LenB().  Also, I used #1 on purpose.  I always use HARD NUMBERS as opposed to variables.  I always and only use (say #1) for LoadUsers(), that way the user list isn't loaded multiple times consecutively or simultaneously, and I also know that any error thrown by opening a file #1 means that something I didn't intend to happen is happening, and easily traceable.

As for checking strParts(), it's done by Split, and if there's an error, the error handler will take care of it.

And as for the error handler, you clearly missed the part where I said

error handlers and such tailored to the program.

I used Debug.Print for the sake of display, since I'm not writing a whole program.  Do you honestly think I would use Debug.Print to handle errors in a release?  You're clearly retarded.

[UserLoser]

rabbit, your code isn't much better. It just has error handlers which I mistakenly left out.

Your not checking if the file exists.
Your using "#1" which could cause errors if that number is already in use for file handling.
Your not checking the size of strParts() before parsing it. Incase of a corrupt user.txt file.
Your error handling debug printout is a fair overkill.

The line "If UserName <> vbNullString And IsNumeric(UserAccess) Then" is bad coding practise because it can cause problems at times where the compiler may misinterpret this as a binary comparison. A better/more efficient equivalent would be, "If (LenB(UserName) <> 0) And (IsNumeric(UserAccess) = True) Then".

---
UL, the only comment on yours would be the naming convention ".ini" for something that isn't formatted correctly. Personally, I think it's best to stick to the .txt extension unless your specifically using .ini files to store data in there intended format.

Programmer sets naming convention, is constant for that purpose.  As for my self I don't use text files to store configuration settings--I always use the registry.

[FrOzeN]

You clearly suck.  IsNumeric() is BOOLEAN meaning it's either TRUE or FALSE.  Checking for true is the same as checking for = true, so it doesn't matter.  As for comparing the UserName variable to vbNullString, it's faster and just as safe as using LenB().

Ok, your line in particular isn't going to cause problems because intellisense (or whatever VB6 uses) interprets it fine. I was only saying it's bad coding practise because on other occasions there can be mix ups and it's clear to distinguish it into parts.

Also, "If someString = vbNullString" is slower than "If LenB(someString) = 0". Sure it makes pretty much makes no noticeable difference, but it's still faster.

http://www.aivosto.com/vbtips/stringopt.html
(See "The empty string")

As for checking strParts(), it's done by Split, and if there's an error, the error handler will take care of it.

Well with your code, if say someone has setup the users.txt and accidently input an entry at the start which is an incorrect format (without a space). Your program would get to it and then just cut out, missing out on all the others. The simply UBound() If-statement check would just ignore that entry and continue on. Essentially, if you want, you could just add an Else-statement and notify the user of the damaged entry(s).

And as for the error handler, you clearly missed the part where I said

error handlers and such tailored to the program.

I used Debug.Print for the sake of display, since I'm not writing a whole program.  Do you honestly think I would use Debug.Print to handle errors in a release?  You're clearly retarded.

I'm not suggesting it was for release, it still doesn't mean you can't have overkill in your code whilst testing. There is no reason to be printing out the HelpFile/HelpContext as it's more than unlikely that you'll be referring to those files; ever.

[Warrior]

You clearly suck.  IsNumeric() is BOOLEAN meaning it's either TRUE or FALSE.  Checking for true is the same as checking for = true, so it doesn't matter.  As for comparing the UserName variable to vbNullString, it's faster and just as safe as using LenB().

Ok, your line in particular isn't going to cause problems because intellisense (or whatever VB6 uses) interprets it fine. I was only saying it's bad coding practise because on other occasions there can be mix ups and it's clear to distinguish it into parts.

You don't need to explicitly state what you expect the return of the object to be when you're dealing with booleans. It's interpreted by the language as being true if nothing conflicts with it. Honestly, in complex statements like his (Statements which contain more than one condition) it's better to remove clutter whenever you can.

Also, "If someString = vbNullString" is slower than "If LenB(someString) = 0". Sure it makes pretty much makes no noticeable difference, but it's still faster.

http://www.aivosto.com/vbtips/stringopt.html
(See "The empty string")

I really don't see how this would be a problem, even if it wasn't optimized then the difference would only be something less than a milisecond.

As for checking strParts(), it's done by Split, and if there's an error, the error handler will take care of it.

Well with your code, if say someone has setup the users.txt and accidently input an entry at the start which is an incorrect format (without a space). Your program would get to it and then just cut out, missing out on all the others. The simply UBound() If-statement check would just ignore that entry and continue on. Essentially, if you want, you could just add an Else-statement and notify the user of the damaged entry(s).

This is simply a difference in how to handle errors, rabbits method simply ignores the errors if they arn't function threatening, yours alerts the user of what happens. Regardless of what you or he thinks is better it isn't a very good argument to use against one's coding skill.

And as for the error handler, you clearly missed the part where I said

error handlers and such tailored to the program.

I used Debug.Print for the sake of display, since I'm not writing a whole program.  Do you honestly think I would use Debug.Print to handle errors in a release?  You're clearly retarded.

I'm not suggesting it was for release, it still doesn't mean you can't have overkill in your code whilst testing. There is no reason to be printing out the HelpFile/HelpContext as it's more than unlikely that you'll be referring to those files; ever.

Honestly, when you're testing I'd Debug.Print, if something hangs the execution of the program (To the point where it cant even redraw itself) then I'd much rather have Debug.Print showing me data instead of another method.

[FrOzeN]

Also, "If someString = vbNullString" is slower than "If LenB(someString) = 0". Sure it makes pretty much makes no noticeable difference, but it's still faster.

http://www.aivosto.com/vbtips/stringopt.html
(See "The empty string")

I really don't see how this would be a problem, even if it wasn't optimized then the difference would only be something less than a milisecond.

I just pointed that out as rabbit said it wasn't faster. Your right in that it's an unnecessary change.

Honestly, when you're testing I'd Debug.Print, if something hangs the execution of the program (To the point where it cant even redraw itself) then I'd much rather have Debug.Print showing me data instead of another method.

I wasn't implying not to use Debug.Print, just that the bottom 2 (of the 5 times) he used it are a bit excessive and arn't really needed.

[rabbit]

Also, "If someString = vbNullString" is slower than "If LenB(someString) = 0". Sure it makes pretty much makes no noticeable difference, but it's still faster.

http://www.aivosto.com/vbtips/stringopt.html
(See "The empty string")

I really don't see how this would be a problem, even if it wasn't optimized then the difference would only be something less than a milisecond.

I just pointed that out as rabbit said it wasn't faster. Your right in that it's an unnecessary change.

Honestly, when you're testing I'd Debug.Print, if something hangs the execution of the program (To the point where it cant even redraw itself) then I'd much rather have Debug.Print showing me data instead of another method.

I wasn't implying not to use Debug.Print, just that the bottom 2 (of the 5 times) he used it are a bit excessive and arn't really needed.

You keep saying stuff about speed and originally used ListBoxes to hold your userlist.

[Ringo]

Eh, I had nothing to do, so I thought i would write a new/random style access class

Hot or not?

Useage:
    Add/Update users access:

Code Select Expand


Class.UserAccess("Ringo") = 100 (0 or lower access = removes user)

    Get Users access:

Code Select Expand


TmpAccess = Class.UserAccess("Ringo")  (0 would mean user not found)





Object Codeage:

Code Select Expand


Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (ByRef Destination As Any, ByRef Source As Any, ByVal numbytes As Long)

Private Type udt_UserAccess
    UserName        As String * 20
    UserHash        As Long
    UserAccess      As Long
End Type
Private m_User()    As udt_UserAccess
Private m_UserCount As Long

Private m_UserHash  As Long

Private Const SizeOfUserAccess As Byte = 28

Public Sub LoadAccessFile(ByVal FilePath As String)
    If Dir$(FilePath) = vbNullString Then Exit Sub
    Dim FF As Integer
    FF = FreeFile
    Open FilePath For Binary As #FF
        If LOF(FF) <= 0 Then Put #FF, 1, CLng(-1)
        Get #FF, 1, m_UserCount
        If m_UserCount >= 0 Then
            ReDim m_User(m_UserCount)
            Get #FF, 5, m_User()
        End If
    Close #FF
End Sub

Public Function SaveAccessFile(ByVal FilePath As String) As Boolean
    On Error GoTo Err_SaveAccess
    If Not Dir$(FilePath) = vbNullString Then Kill FilePath
    Dim FF As Integer
    If m_UserCount >= 0 Then
        FF = FreeFile
        Open FilePath For Binary As #FF
            Put #FF, 1, m_UserCount
            Put #FF, 5, m_User()
        Close #FF
        FF = 0
    End If
    SaveAccessFile = True
    Exit Function
Err_SaveAccess:
    SaveAccessFile = False
    If FF > 0 Then Close #FF
End Function


Public Property Get UserAccess(ByVal UserName As String) As Long
    If GetTrueUser(UserName) = False Then Exit Property
    Dim i As Long
    i = FindUser(UserName)
    If i >= 0 Then
        UserAccess = m_User(i).UserAccess
    End If
End Property

Public Property Let UserAccess(ByVal UserName As String, ByVal NewAccess As Long)
    If GetTrueUser(UserName) = False Then Exit Property
    Dim i As Long
    i = FindUser(UserName)
    If i >= 0 Then
        If NewAccess <= 0 Then   'remove the user
            Call RemoveUser(i)
        Else  'update the user
             m_User(i).UserAccess = NewAccess
        End If
    Else
        If NewAccess <= 0 Then Exit Property
        i = m_UserCount + 1
        ReDim Preserve m_User(i)
        With m_User(i)
            .UserName = Left$(UserName & String(20, 0), 20)
            .UserHash = m_UserHash
            .UserAccess = NewAccess
        End With
        m_UserCount = i
    End If
End Property


Private Sub Class_Initialize()
    m_UserCount = -1
End Sub

Private Function GetTrueUser(ByRef UserName As String) As Boolean
    Dim i As Long
    i = InStr(1, UserName, "#", vbTextCompare) - 1
    If i > 0 Then UserName = Left$(UserName, i)
    i = Len(UserName)
    If i > 20 Then UserName = Left$(UserName, 20)
    GetTrueUser = (i > 0)
End Function

Private Sub RemoveUser(ByRef Index As Long)
    If Index < 0 Or Index > m_UserCount Then Exit Sub
    Dim i As Long
    If Index < m_UserCount Then
        For i = Index To m_UserCount - 1
            Call CopyMemory(m_User(i), m_User(i + 1), SizeOfUserAccess)
        Next i
    End If
    m_UserCount = m_UserCount - 1
    If m_UserCount < 0 Then
        m_UserCount = -1
        Erase m_User()
    Else
        ReDim Preserve m_User(m_UserCount)
    End If
End Sub

Private Function FindUser(ByRef StrUser As String) As Integer
    Dim i As Long
    Call HashString(StrUser)
    For i = 0 To m_UserCount
        If m_User(i).UserHash = m_UserHash Then
            If StrComp(Replace(m_User(i).UserName, vbNullChar, ""), StrUser, vbTextCompare) = 0 Then
                FindUser = i
                Exit Function
            End If
        End If
    Next i
    FindUser = -1
End Function

Private Sub HashString(ByRef Name As String)
    Dim Key() As Byte, StrLen&, StrHash$, valHold&, i%
    StrHash = LCase(Name)
    StrLen = Len(StrHash)
    If (StrLen Mod 4) Then
        StrHash = StrHash & Left$(String(4, &H20), 4 - (StrLen Mod 4))
        StrLen = Len(StrHash)
    End If
    ReDim Key(StrLen - 1)
    Call CopyMemory(Key(0), ByVal StrHash, StrLen)
    m_UserHash = 0
    For i = 0 To (StrLen - 1) Step 4
        valHold = (((Key(i) * 256& + Key(i + 1)) * 256& + Key(i + 2)) * 256& + Key(i + 3))
        m_UserHash = m_UserHash Xor valHold
    Next i
    Erase Key()
End Sub


[FrOzeN]

You keep saying stuff about speed and originally used ListBoxes to hold your userlist.

The title reads "Loading Access From A File And Splitting It", mentioning nothing about storing the info. I was just demonstrating a more appropriate way to open the file, and read from it. I just used ListUser/ListAccess as that's how he had it. If I were to create my own storage for the userlist I would build a class module.

[topaz]

Shut up.

[Cat Food]

In my opinion anyone that uses listboxes for reasons not nessicary should be shot.
And ratio you're bad so just keep your code to yourself. I'm only flaming you because it's true and you do the same to others.

Try storing access in a string, not an array/listbox. It's not that hard.

Edited for example below. ----v
--Don't give me this, it could error bull because theres no reason to not check for which file #s you're using--

Code Select Expand



Public sFileAccess As String
'somewhere perhaps ^

Dim sUserAccess As String
'tmp variable

Open TheFile For Input As #1
Do Until EOF(1)
Line Input #1, sUserAccess
  If InstrB(2,sUserAccess,chrW$(32)) Then  sFileAccess = sFileAccess & sUserAccess & ChrW$(0)
  'since name must be before space, and have space so we can parse correctly.
Loop
Close #1

'Yes if access file is tampered with may return invalid results, to read...

Public Function GetAccess(sName As String) As Integer

  'you could format it to lcase when storing, all up to you
  If InstrB(1,LCase$(sFileAccess), LCase$(sName)) Then
   
    Dim sTemp As String
    sTemp = Mid$(sFileAccess,Instr(LCase$(sFileAccess), LCase$(sName))+1)
    'gets name --->
    sTemp = Mid$(sTemp, InStr(1, sTemp, ChrW$(32)) + 1)
    sTemp = Left$(sTemp, InStr(1, sTemp, ChrW$(0)) - 1)
    'gets access -->

    'if you are always storing in 3 digits set (which I suggest to make things easier,
    'you could cut the above two lines and just use
    'sTemp = Mid$(sTemp, InStr(1, sTemp, ChrW$(32)) + 1, 3)   

    GetAccess = Val#(sTemp)
    'done
   
  End If

End Function

'storing isn't much harder either...and you can remove access using a similar method as above. No listbox, no loops, just one simple string.

[Mystical]

Shame on you for reviving old topic, Shame on me for even talkin..

[Cat Food]

Shame on you for reviving old topic, Shame on me for even talkin..

Oh I didn't even notice the dates. Yeah shame on me

It wasn't too far down in the list so I just assumed...

[HardCoded.]

lol my coding has improved by alot since this topic began