[RESOLVED] Is there a VB6 compiler cache?

I've run into a perplexing problem. I have a program that runs fine in the debugger, but throws a subscript error when compiled. This is the procedure that errors:

Code:

---

Private Sub ConfigureHeaders()

    Dim lTemp As Long, lWidth As Long

    On Error GoTo ErrHand

    lstAudit.ListItems.Clear
    lstAudit.ColumnHeaders.Clear
    For lTemp = LBound(csCols) To UBound(csCols)
        lWidth = goOptions.GetAuditColumns(lTemp)
        If lWidth < 0 Then lWidth = DEFAULT_COL_WIDTH
        Call lstAudit.ColumnHeaders.Add(lTemp + 1, , csCols(lTemp), lWidth)
        If lTemp = NUM_AUDIT_COLS Then Exit For
    Next lTemp

ErrHand:
    If Err.Number <> 0 Then
        Call MsgBox("Error number " & Err.Number & vbCrLf & Err.Description & vbCrLf & _
                    "in routine ConfigureHeaders of AuditTray", vbExclamation, "TrialTrack Error")
    End If

End Sub

---

The error seems to happen when the UBound function is called, in fact, this code will hang the program when compiled (but strangely won't throw the subscript error).

Code:

---

Private Sub ConfigureHeaders()

    Dim lTemp As Long, lWidth As Long

    On Error GoTo ErrHand
    MsgBox (UBound(csCols))
    lstAudit.ListItems.Clear
    lstAudit.ColumnHeaders.Clear
    For lTemp = LBound(csCols) To UBound(csCols)
        lWidth = goOptions.GetAuditColumns(lTemp)
        If lWidth < 0 Then lWidth = DEFAULT_COL_WIDTH
        Call lstAudit.ColumnHeaders.Add(lTemp + 1, , csCols(lTemp), lWidth)
        If lTemp = NUM_AUDIT_COLS Then Exit For
    Next lTemp

ErrHand:
    If Err.Number <> 0 Then
        Call MsgBox("Error number " & Err.Number & vbCrLf & Err.Description & vbCrLf & _
                    "in routine ConfigureHeaders of AuditTray", vbExclamation, "TrialTrack Error")
    End If

End Sub

---

It seems almost like the array isn't getting initialized properly in the compiled version. As I've been playing around with this to try to get it to compile correctly, I've also noticed that the executable size always stays the same, even when I comment out huge swaths of code. That makes me suspect that the compiler is caching object files someplace and isn't updating them before linking. This is driving me absolutely batty. Anyone ever run into a similar problem or have an idea how to fix it? I've tried turning all the compiler optimizations off, renaming functions and variables (last time something like this happened it was an alias error in the compiler), deleting the .frx file for the form, removing the .frm file and rebuilding it, etc., etc.

Are you forgetting that VB6 is ZERO based?

Normally I use 0 to Ubound(x)-1 in loops

otherwise, move the code into a new folder and start again to see if something is crossed or not.

Quote:

---

Originally Posted by dglienna

Are you forgetting that VB6 is ZERO based?

Normally I use 0 to Ubound(x)-1 in loops

otherwise, move the code into a new folder and start again to see if something is crossed or not.

---

I use LBound out of habit. After sprinkling some MsgBoxes around, the problem seems to be in the order that the form is being built. I call it like this:

Code:

---

Private Sub ShowAuditorTray(dStart As Date, dEnd As Date, lUW As Long)

    Dim fAudit As AuditorTray
   
    On Error GoTo ErrHand

    Set fAudit = New AuditorTray
    fAudit.DateStart = dStart
    fAudit.DateEnd = dEnd
    fAudit.Underwriter = lUW
    fAudit.Show

ErrHand:
    If Err.Number <> 0 Then
        Call MsgBox("Error number " & Err.Number & vbCrLf & Err.Description & vbCrLf & _
                    "in routine ShowAuditorTray", vbExclamation, "TrialTrack Error")
    End If
   
    Set fAudit = Nothing
   
End Sub

---

In the debugger, the show in this order:

Code:

---

Form initializing
StartDate set
EndDate set
Underwriter set
Form Loading
Tray updating

---

Compiled, the exact same code runs in this order:

Code:

---

Form Loading
Tray updating
Form initializing
StartDate set
EndDate set
Underwriter set

---

The array is initialized and filled in the (drum roll please) Form_Initialize event. Strangely, the Form_Load event seems to be firing first... I didn't even think that was possible. I need to have multiple instances of the form open at the same time (as well as set it's properties), so it has to be assigned to a variable and called with that convention. Is this just some freaky compiler error or am I missing something obvious?

Are you initializing a control before it is activated on the screen? Using Form_Load or Form_Activate? Hard to see where your trace is coming from.

I use Form_Load. Here's the initialize event. All it does is fill an array and set the form's icon. I don't touch any of the controls until the Form_Load (some of them may move if the form resizes).

Code:

---

Private Sub Form_Initialize()

    On Error GoTo ErrHand
    MsgBox "Form initializing"
    If Not geDevMode Then
        Call SetIcon(Me.hWnd, INTRAY_ICON, False)
    End If
   
    csCols = Split("Trial Number|Client Name|Product Type|Offer Date|Face Amount|Broker|Contractor", "|")

ErrHand:
    If Err.Number <> 0 Then
        Call MsgBox("Error number " & Err.Number & vbCrLf & Err.Description & vbCrLf & _
                    "in routine Form_Initialize of AuditTray", vbExclamation, "TrialTrack Error")
    End If
 
End Sub

---

... and the Load event. goOptions is a global object that gets loaded when the program starts.

Code:

---

Private Sub Form_Load()

    On Error GoTo ErrHand
    MsgBox "Form loading"
    If goOptions.AuditLeft <> 0 Then
        If goOptions.AuditLeft < HostForm.Width Then
            Me.Left = goOptions.AuditLeft
        End If
    End If
    If goOptions.AuditTop <> 0 Then
        If goOptions.AuditTop < HostForm.Height Then
            Me.Top = goOptions.AuditTop
        End If
    End If

    If goOptions.AuditHeight <> 0 Then
        Me.Height = goOptions.AuditHeight
    Else
        Me.Height = MIN_FORM_HEIGHT
    End If
    If goOptions.AuditWidth <> 0 Then
        Me.Width = goOptions.AuditWidth
    Else
        Me.Width = MIN_FORM_WIDTH
    End If
    lstAudit.View = goOptions.AuditView
   
    Call ToggleAlignment(lstAudit.View <> lvwReport)

    Call ConfigureButtons
    Call UpdateTray

ErrHand:
    If Err.Number <> 0 Then
        Call MsgBox("Error number " & Err.Number & vbCrLf & Err.Description & vbCrLf & _
                    "in routine Form_Load of AuditTray", vbExclamation, "TrialTrack Error")
    End If
   
End Sub

---

The subscript error from the first post is happening because the Initialize event doesn't fire before the Load event(and doesn't fill the array). It is called from the UpdateTray sub at the bottom of the load event. The rest of the traces come from setting custom form properties -- all of those are trivial procedures.

Code:

---

Public Property Let Underwriter(lID As Long)

    clUnderwriter = lID
    MsgBox "Underwriter set"
End Property

---

I hacked around it to get a good compile to demo today, but am still kind of perplexed -- I had assumed that I could rely on Initialize always firing before Load.

Quote:

---

Originally Posted by dglienna

Are you forgetting that VB6 is ZERO based?

Normally I use 0 to Ubound(x)-1 in loops

---

David, if you do that normally, you would ALWAYS miss the last element in your loops, BECAUSE of the zero based counting.
If you Dim X(2), UBound(x) delivers 2, not 3. ;)

@Comintern: I played around with forms, loading before showing, assigning to variables, too. I never got the Load() firing before Initialize().
You'd have to reveal more of that loading to comprehend what's happening there.

If you use X(2) there are 3 elements. I only use the first two. 0,1

Does Initialize take too long to process? It always fires first. Glad it complied though

I've had similar strange things happen, and in a pinch what has worked most times it to open the form in the IDE before compiling. This seems to get around having it happen during compilation.

Still, it hasn't happened enough for me to recall what the issue was or if I found a way to solve it via code.

Are you starting in Sub Main()?

Quote:

---

Originally Posted by dglienna

Are you starting in Sub Main()?

---

Who? As for me, no. I think it has something to do with the controls being used, as they would obviously all have to load and draw themselves, etc.

@David: Well, I always dim an array with all elements I want to use, because UBound should deliver the last used element. :)
But nevertheless, I can't find any circumstance under which Load() would fire before Initialize().
If you create a form like:

Code:

---

Dim F as Form
Set F = New Form1
F.show

---

The sequence of events remains the same. Initialize() comes before Load()
How do you manage to fire the events other ways. Do tell the code.

Nothing fires before F.Show, so you can load anything before that. Then, if you actually show the form this way, it gets displayed instantly.

PUBLIC variables in the module work...

Quote:

---

Originally Posted by WoF

David, if you do that normally, you would ALWAYS miss the last element in your loops, BECAUSE of the zero based counting.
If you Dim X(2), UBound(x) delivers 2, not 3. ;)

@Comintern: I played around with forms, loading before showing, assigning to variables, too. I never got the Load() firing before Initialize().
You'd have to reveal more of that loading to comprehend what's happening there.

---

I think this was a compiler error (2nd on this project). It resolved after I commented out a Debug.Assert call elsewhere in the code. Totally unrelated to the form handling, and shouldn't be compiling anyway. Probably time to pull all my IDE mode code out. Thanks to all for the suggestions.

Weird. :rolleyes:

Quote:

---

Originally Posted by WoF

Weird. :rolleyes:

---

Yeah, I think a reinstall might be in order. :) Could be related to a code profiling add-in that I was trying out.