-
March 24th, 2008, 10:20 PM
#1
[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.
Last edited by Comintern; March 24th, 2008 at 10:24 PM.
-
March 24th, 2008, 11:09 PM
#2
Re: Is there a VB6 compiler cache?
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.
Last edited by dglienna; March 24th, 2008 at 11:12 PM.
-
March 24th, 2008, 11:33 PM
#3
Re: Is there a VB6 compiler cache?
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?
-
March 25th, 2008, 12:07 AM
#4
Re: Is there a VB6 compiler cache?
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.
-
March 25th, 2008, 07:22 AM
#5
Re: Is there a VB6 compiler cache?
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.
Last edited by Comintern; March 25th, 2008 at 07:26 AM.
-
March 25th, 2008, 08:50 AM
#6
Re: Is there a VB6 compiler cache?
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.
-
March 25th, 2008, 11:11 AM
#7
Re: Is there a VB6 compiler cache?
If you use X(2) there are 3 elements. I only use the first two. 0,1
-
March 25th, 2008, 11:13 AM
#8
Re: Is there a VB6 compiler cache?
Does Initialize take too long to process? It always fires first. Glad it complied though
-
March 25th, 2008, 01:02 PM
#9
Re: Is there a VB6 compiler cache?
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.
Please remember to rate the posts and threads that you find useful.
How can something be both new and improved at the same time?
-
March 25th, 2008, 01:06 PM
#10
Re: Is there a VB6 compiler cache?
Are you starting in Sub Main()?
-
March 25th, 2008, 01:12 PM
#11
Re: Is there a VB6 compiler cache?
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.
Please remember to rate the posts and threads that you find useful.
How can something be both new and improved at the same time?
-
March 25th, 2008, 08:41 PM
#12
Re: Is there a VB6 compiler cache?
@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.
-
March 25th, 2008, 09:14 PM
#13
Re: Is there a VB6 compiler cache?
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...
Last edited by dglienna; March 25th, 2008 at 09:16 PM.
-
March 26th, 2008, 04:54 PM
#14
Re: Is there a VB6 compiler cache?
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.
-
March 26th, 2008, 07:00 PM
#15
Re: [RESOLVED] Is there a VB6 compiler cache?
Weird.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|