Where does VB go in a crash? 2

[NeilFrank]

When my (MDI) App starts I open a random access file (RAF) that is designed to help nail down a problem in the event of a crash:

Open App.Path & "\AppFlowDebug.dat" For Output As #100

As my App runs I write out key data:

Print #100, "FOO"

Unfortunately, since I currently have in my

Close #100

statement in my MDIForm_Unload routine, when the App does crash the RAF is not properly closed and some of the data written to it is lost.

Does there exist a VB routine that ALWAYS gets called just before an App crashes? If so, I could simply insert the Close statement there.

Or do I need to write such a routine and explicitly call it via On Error/GoTo code added to each subroutine in my App?

 

[JoeAtWork]

The only way to keep VB going is to have an error handler. Bear in mind though that errors will "bubble-up" the call stack until it gets to a calling procedure that had an error handler.

So if A calls B and B calls C and there is an error in C, what happens is:

If C has an error handler
Error is handled in C
ElseIf B has an error handler
Error is handled in B
ElseIf A has an error handler
Error is handled in A
Else
No error handler, your EXE goes bye-bye

 

[Golom]

If you need to be sure that everything written to the RAF gets saved then

Open App.Path & "\AppFlowDebug.dat" For Output As #100
Close #100

when the program starts and then

Public Sub WriteRAF (DebugString As String)
    Open App.Path & "\AppFlowDebug.dat" For [red]Append[/red] As #100
    Print #100, DebugString  
    Close #100
End Sub

 

[MichaelRed]

unfortunatly, none of the above will catch ALL errors in dear ol Ms. A.

In particular, the "MS Access has encountered a problem and nmust close ... " dialog box will ALWAYS bypass the que created in this (and many/most/all) similar variations.

Having used this approach in the past, I would suggest that the 'call que' be written to a temporary recordset. This permits the recordset to be opened once (of course in needs to be declared Globally), thus minimizing the overhead of the successive open/close events. Further, you can include a flag to keep the call que, reset it or even ignore it, all in a seperate routiene.



MichaelRed

 

[JoeAtWork]

Michael - what you say about Access may be true, but I believe the OP has an MDI application written in VB6, and I have yet to see a VB app crash for any reason other than a bug in my own code (which is why I prefer the VB environment over Access VBA).

 

[harebrain]

When my (MDI) App starts I open a random access file (RAF) that is designed to help nail down a problem in the event of a crash:

This is nitpicking, but random? Surely you mean a sequential file. (The output device might be capable of random access, but this is a plain old log file.) And while I'm at it, do use the freefile function.

 

[NeilFrank]

Good question. I've always assumed that my Open statement

created a RAF. Do I have SAFs???

I agree that the freefile function makes sense, but I wrote this code several years ago when I was stupider.