Wanted Feature - Tracing LogFile

[BackupUser]

Restored from previous forum. Originally posted by MrVainSCL.

Hi @ all
What do you think about a option in PureBasic to compile/run your source and creating a logfile on your hd, where you can see ANY COMMAND that was EXECCUTED (incl. raw number)... This would be very usefull for bug fixing... I think this feature is STRONGLY REUQIRED!



PIII450, 256MB Ram, 6GB HD, RivaTNT, DirectX8.1, SB AWE64, Win2000 + all Updates...

greetz
MrVainSCL! aka Thorsten

[BackupUser]

Restored from previous forum. Originally posted by tinman.

What do you think about a option in PureBasic to compile/run your source and creating a logfile on your hd, where you can see ANY COMMAND that was EXECCUTED (incl. raw number)... This would be very usefull for bug fixing... I think this feature is STRONGLY REUQIRED

What do you mean by "raw number" - line number? How many times the command was called?

Even if you print all the commands that were executed, it does not mean the logfile will be useful - what about in cases where the application does not crash (and therefore the error is inthe middle of the logfile) or something like a pointer gets set to null by mistake somewhere, which could cause a program to crash somewhere else.

I don't think Fred needs to waste his time on things which can fairly easily be done by the user (although, macros would be very handy in this case Fred

And see how kind I am:

Code: Select all

#DEBUG_LEVEL = 1        ; Set this to 0 for no debugging at all (and no debug code in the exe)
                        ; If this is set to anything above 0, it represents the debug level,
                        ; a level of 1 only outputs the most important debug statements (and
                        ; therefore less output) and 32767 represents outputting of all data
                        ; (and probably a load of useless rubbish too :)
                        

CompilerIf #DEBUG_LEVEL>0
DefType.l   DebugFH     ; Filehandle for debugging output
CompilerEndIf


; Name:         Debug_Initialise
; Parameters:   filename.s - String which contains the full filename of the file to save to
; Returns:      Word - 0 for failure (could not create file), or 1 for success (file ready)
; Globals:      DebugFH - the file handle to be used in all debugging procedures
; Description:  This procedure sets up the debug system. As such, it should be called before any other
;               debug procedures. You can safely ignore the return value from this procedure
;               if you want, it just means you will not get any debug output if it fails.
;
;               The created file overwrites anything that is there.
Procedure.w Debug_Initialise(filename.s)
    CompilerIf #DEBUG_LEVEL>0
    DefType.w   success         ; Flag to show whether starting the debug system was succssful or not
    Shared      DebugFH

    If DebugFH=0
        DebugFH = CreateFile_(@filename, #GENERIC_WRITE, 0, 0, #CREATE_ALWAYS, #FILE_ATTRIBUTE_NORMAL, 0)
        If DebugFH0
            success = 1
        EndIf
    Else
        success = 1
    EndIf
    
    ProcedureReturn success
    
    CompilerElse
    ProcedureReturn 1
    CompilerEndIf
EndProcedure


; Name:         Debug_OutputN
; Parameters:   level.w  - The debug level. This indicates the debug level for this string, and ultimately decides whether it will be printed. See the description of #DEBUG_LEVEL for more info.
;               string.s - The string which should be stored in the debug log file.
; Returns:      Nothing
; Globals:      DebugFH - the filehandle that all debug output will be sent to
; Description:  This procedure is used to write strings to the debug log file. The string to write is passed in the string.s parameter.
;               The level parameter (must be in the range 1 to 32767 inclusive) decides whether ths string is actually written or not.
;               If the level is less than or equal to the #DEBUG_LEVEL constant, then the string will be written.
;               The most important strings should have a value of 1 whereas the least important should have a
;               higher value (with the least important being 32767).
;
;               This procedure writes a newline (CR+LF) after the string.
Procedure Debug_OutputN(level.w, string.s)
    CompilerIf #DEBUG_LEVEL>0
    DefType.w   CRLF
    DefType.l   byteswritten
    Shared      DebugFH
    
    If DebugFH0
        If level0
    DefType.l   byteswritten
    Shared      DebugFH
    
    If DebugFH0
        If level0
    Shared      DebugFH
    
    If DebugFH0
        CloseHandle_(DebugFH)
        DebugFH = 0
    EndIf
    
    CompilerEndIf
EndProcedure

Now if we had macros, we could just stick loads of calls to Debug_Output all over the code. As it is now, the procedures stay in the source even when debugging is disabled, so you do not need to always add/remove the calls to the procedures.


--
It's not minimalist - I'm increasing efficiency by reducing input effort.
(Win98first ed. + SP1, PB3.20)

[BackupUser]

Restored from previous forum. Originally posted by tranquil.

I think this will be a good feature couse I have a code too where I cant see where it crashes. its very mysterious. cant use the debugger here.
I tried to find the point by using messagerequesters on some checkpoints in the source but if I include a messagerequester, the code works fine. If I remove it again, it crashes and I dont know why.

A logfile would be nice to see the last executed line or command which couses the crash.


Mike

Tranquilizer/ Secretly!
http://www.secretly.de
Registred PureBasic User

[BackupUser]

Restored from previous forum. Originally posted by PB.

> What do you think about a option in PureBasic to compile/run your source and
> creating a logfile on your hd, where you can see ANY COMMAND that was EXECCUTED
> (incl. raw number)... This would be very usefull for bug fixing...

Isn't that what the CallDebugger command, and clicking Step, is for? You put
that command near the problem routine and then step through each command until
your app crashes, and then you'll know which command caused it.

PB - Registered PureBasic Coder

[BackupUser]

Restored from previous forum. Originally posted by tranquil.

The Step-by-Step methode does not work couse the source is to huge and I have to start some Gadget events first before the application crashes.

Mike

Tranquilizer/ Secretly!
http://www.secretly.de
Registred PureBasic User

[BackupUser]

Restored from previous forum. Originally posted by tinman.

Isn't that what the CallDebugger command, and clicking Step, is for? You put

You can't use the debugger in callback procedures (not the one for dealing with Windows window events anyway).


--
It's not minimalist - I'm increasing efficiency by reducing input effort.
(Win98first ed. + SP1, PB3.20)

[BackupUser]

Restored from previous forum. Originally posted by PB.

> The Step-by-Step methode does not work couse the source is to huge and I have
> to start some Gadget events first before the application crashes.

But can't you put "CallDebugger" at the gadget event code and then step through
the code when the gadget event occurs? Like, put "CallDebugger" after your
"If EventType() = #PB_EventGadget" line and go from there?

PB - Registered PureBasic Coder

[BackupUser]

Restored from previous forum. Originally posted by fred.

You can't use the debugger in callback procedures (not the one for dealing with Windows window events anyway).

This was true for PB < 3.10. Have you got problems since ?

Fred - AlphaSND

[BackupUser]

Restored from previous forum. Originally posted by tinman.

You can't use the debugger in callback procedures (not the one for dealing with Windows window events anyway).

This was true for PB < 3.10. Have you got problems since ?

I did, but thinking about it, it may not have been due to the debugger. It was some time ago, but I could see if I can break it again

--
It's not minimalist - I'm increasing efficiency by reducing input effort.
(Win98first ed. + SP1, PB3.20)