Your Installation Specialist

 

 
Visual Basic 6 Coding Techniques

    What we have found is that many users do not know how to properly code certain procedures in vb that are neccessary for proper application operation. We will attempt to help with some of the most popular problems, of course we will offer a solution... One very important thing to remember NEVER I repeat NEVER us the END statement to terminate your app. It is the worst thing you can do. It leaves memory in a corrupted state when your program closes and that provides a memory leak. Close all of your forms, connection, files and objects before terminating your app. It will close and clean up the memory behind itself.
 
Closing VB Applications

To properly unload all forms and allow your program to terminate follow these simply rules (and code)

In a Module place this code:

Public Sub UnloadAll(Optional activefrm As Form)

Dim frm As Form
Dim ctl As Control

    On Error Resume Next
        For Each frm In Forms
    
        ' Don't unload active form or we will reload it when we return to it
        ' Allow active form to unload itself

        If frm.Name <> activefrm.Name Then

            ' This is extra protection and may not be needed

            For Each ctl In frm.Controls  
                Set ctl = Nothing
            Next
            
            ' This is needed

            Unload frm
            Set frm = Nothing

        End If

    Next

End Sub

If you start your program from a form, in your main form include this call in your Unload event (Not the Query_Unload Event).

UnloadAll Me

If you start your program from Sub Main just use this code at the end of your mainline code procedure.

UnloadAll


Instruction Timing

    Honestly, unless you are processing REAL-TIME apps that respond to very fast hardware or will be repeated over 10,000 times in quick succession you really need not care about if one instruction is a millisecond or two faster that the other.

    I have not seen one app in VB that it would make much of a difference and if you are making such an app, you probably shouldn't be using VB in the first place.

    If you really care how much time something takes use the GetTickCount API and time it. You will then know just how much time it takes to execute the instruction and even then it depends then actual compiled code not the IDE interpeted code. Depending on how you compiled the code Native, PCode etc.. it could even then be different. So the best way is to use GetTickCount before and after the instruction in question and compile it. You will then know just how long it takes.

Error Handling

    One of the biggest problems people have is debugging their programs. Here are a few examples of error routines that will aid you in finding where in your code the actual problem arises when you have unexpected errors.


Public Function YourFunction(...)

Dim ...

    On Error GoTo YourFunctionErrRtn
    ...
    Exit Function

YourFunctionErrRtn:

    Stop
    Resume Next

End YourFunction

    This type of error function will allow you to enter the ide debug mode on an error and then you can step through (F8) to the next line in your function directly after the line that caused the error. Now you know exactly where the error occurred. You can use tools such as RSTools to add this type of code (as well as trace your function calls) to every function in your program or you may only want to add it to some function of your app if you know the problem areas.

    When you have expected errors you can handle the error in this fashion:

Public Function YourFunction (...)

Dim ...

    On Error Resume Next    ' Disable error handling

    Err.Clear
    a = a/0            ' This can be any instruction that may cause an error

    If Err.Number <> 0 then    ' Handle the error here
        ' Handle Error
    End If

    On Error GoTo 0

End YourFunction