Do not kill the debug window

[IdeasVacuum]

When Testing under debug, you might have to kill your app if 'things go wrong'. however, when you do, PB closes the debug window, which contains the debug info you have sent to help you solve the issue.........

[Dude]

+1

[Demivec]

You might be able to use the stand-alone debugger instead.

[Marc56us]

As Demivec said, use use the stand-alone debugger.

If you still want to use the internal debbugeur it is also possible:
Send debug output in error log window instead of debug output window

Preferences > Debugger > Individual Settings > [X] Display debug output in the error log

Sample crash code:

Code: Select all

Debug "Hello World!"

PokeS(123, "Write to protected memory error here!")

Log window with error log:

Code: Select all

Waiting for executable to start...
Executable type: Windows - x64  (64bit, Unicode)
Executable started.
[Debug] Hello World!
[ERROR] Debug_Save.pb (Line: 3)
[ERROR] Invalid memory access. (write error at address 123)
The Program was killed.

Another solution: use SaveDebugOutput() before dangerous action (but the last action will not be save)
Note for SaveDebugOutput()
- SaveDebugOutput() can be use as many times as you want (replace auto)
- Use little delay(100) before call it and exit prog.

[Dude]

It's less hassle just to keep the debug window open.

[IdeasVacuum]

Thanks for the tips guys.

Send debug output in error log window instead of debug output window

That's a good work-around, though when there is a lot of info it's a pita to copy. Also, in the worst case, the IDE could be locked-up or crashed, so keeping the debug window up is a life saver.

You might be able to use the stand-alone debugger instead.

I don't like the stand-alone debugger but you are absolutely right, it is currently the best answer, so I had better learn to like it when the unexpected happens

[Marc56us]

The problem is: I think that debug window is a child window of IDE, so if IDE freezes, crash, or close, debug output will do the same

PB should do as some others IDE: Automatically save debug output in a log file.

Additional advantage: it is possible to use powerful log file analysis tools (ie: have syntax highlighting)

[Dude]

debug window is a child window of IDE, so if IDE freezes, crash, or close, debug output will do the same

We're not talking about crashes, though. We mean when we purposely kill the running compiled exe. The IDE is still perfectly functional in such a case, and therefore it'd be nice if the Debug window stayed open.

PB should do as some others IDE: Automatically save debug output in a log file

That introduces slowdown though, if you're compiling from slow media (like I do at times).

Regardless, the Debug window stays open when a compiled exe ends normally, so it should also stay open if we choose to kill the exe instead.

[Marc56us]

We're not talking about crashes, though. [...]

[...] Also, in the worst case, the IDE could be locked-up or crashed [...]

That introduces slowdown though, if you're compiling from slow media (like I do at times).

Yes and no: Unless you work on floppy disk speed writing (in an opened file) is not an issue.
PB (and the host OS Windows/Linux/Mac) write a lot of files all the time. Write a file will not slow down.
(Anyway, the Debug outputs must be limited to useful information.)

I agree that the debug window should remain open, and I hope so too. But I think that if that is so, maybe it's because this is not possible.

[IdeasVacuum]

maybe it's because this is not possible

It is possible - in fact, it possibly already has it's own thread, so if the IDE fails, the debug window could stay on screen. It could also be launched as a seperate exe.

The point is, a debug window is there to help you fix your bugs, so it is important that the only thing that can close it is you.

[freak]

Why not just pause the program, do your debugging and then kill it?

The problem with keeping the window open is that then you will have to manually close it every time you kill your debug session to quickly get back to coding. This will get annoying very fast.

[IdeasVacuum]

Why not just pause the program, do your debugging and then kill it?

When that works - i.e, IDE is not locked-up, it is still a pita - you have to keep switching it on and off.

The problem with keeping the window open is that then you will have to manually close it every time you kill your debug session

A single click to close is no bother at all compared to losing the window when you most need it.

[Dude]

The problem with keeping the window open is that then you will have to manually close it every time you kill your debug session to quickly get back to coding. This will get annoying very fast.

Let your customers be the judge of what's annoying.

And besides, like I said, it already stays open when an app exits normally, so your argument is invalid.

[blueb]

Why not the best of both worlds... a checkbox "Don't Close Me" on the top of the Window?

Normally, the debug Window operates exactly as it does now.

When you're having problems, check "Don't Close Me" before you kill the program.
It stays open, and you'll have your information.

[skywalk]

I prefer the debug/variables/memory windows stay open as they do when my app terminates normally.
When there is too much clutter, I run this as a tool(Windows only) to close all non-ide windows.

Code: Select all

EnableExplicit
Structure winINFO
  hW.i      ; handle
  left.i
  top.i
  right.i
  bottom.i
  Wd.i
  Ht.i
  wT$       ; window title
EndStructure
Global NewList wil.winINFO()  ; Window Info list
#COLON2$ = "::"
#MB_USERICON = $80        ; Disable system Beep -> MessageRequester("","", | #MB_USERICON)
Macro PB_CP
  ProgramFilename() + #COLON2$ + #PB_Compiler_Procedure
EndMacro
Macro MRE(txt, NoBeep=0)    ; MessageBox x Error = #MB_ICONHAND | #MB_ICONSTOP | #MB_ICONERROR
  MessageRequester(PB_CP, txt, #MB_ICONERROR | (#MB_USERICON * NoBeep))
EndMacro
Procedure RestoreX(DataLabel.i)
  CompilerSelect #PB_Compiler_Processor
  CompilerCase #PB_Processor_x86
    !MOV eax, [p.v_DataLabel]   ; instead of -> !MOV eax, [esp+8]
    !MOV [PB_DataPointer], eax
  CompilerCase #PB_Processor_x64
    !MOV rax, [p.v_DataLabel]   ; instead of -> !MOV rax, [rsp+64]
    !MOV [PB_DataPointer], rax
  CompilerDefault
    MRE("Error: Unknown Processor.")
  CompilerEndSelect
EndProcedure
Procedure.i win_GetInfo_CB(hW.i, lp.i)
  Protected$ wt$ = Space(#MAX_PATH)
  Protected wp.WINDOWPLACEMENT
  If hW
    AddElement(wil())
    wil()\hW = hW
    If IsWindowVisible_(hW)
      GetWindowText_(hW, @wt$, #MAX_PATH)
      If wt$
        wil()\wT$ = wt$
        Debug wt$
        GetWindowPlacement_(hW, @wp)
        wil()\left = wp\rcNormalPosition\left
        wil()\top = wp\rcNormalPosition\top
        wil()\right = wp\rcNormalPosition\right
        wil()\bottom = wp\rcNormalPosition\bottom
        wil()\Wd = wil()\right - wil()\left
        wil()\Ht = wil()\bottom - wil()\top
      EndIf
    EndIf
    ProcedureReturn 1   ; Continue search
  Else
    ProcedureReturn 0   ; Done
  EndIf
EndProcedure
Procedure.i ct_CloseExtraPBWin(DataLabel.i)
  ; Create list of existing windows + handles.
  ; Then cycle through and close them.
  ; Attempts to close via callback fails for some windows.
  ; CRITICAL: Delay() cmd after SendMessage_() for settling time.
  Protected.i ri
  Protected$ winToClose$
  ClearList(wil())
  EnumWindows_(@win_GetInfo_CB(), 0)
  ; Cycle through retrieved window list and close PB window types.
  ResetList(wil())
  ForEach wil()
    RestoreX(DataLabel)
    Repeat      ; Enumerate all PB Window types
      Read$ winToClose$
      If FindString(wil()\wT$, winToClose$)
        ;ri = SendMessage_(wil()\hW, #WM_CLOSE, 0, 0) ; This fails in some cases
        ri = SendMessage_(wil()\hW, #WM_SYSCOMMAND, #SC_CLOSE, 0)
        Delay(50)
        If ri = #S_OK
          ri = 1
        Else
          MRE("Unable to close -> " + wil()\wT$)
          ri = -1
        EndIf
        Break
      EndIf
    Until winToClose$ = "Q"
  Next
  ClearList(wil())
  ProcedureReturn ri
EndProcedure
ct_CloseExtraPBWin(?ds_PBWindowNames)
;-{ DATASECTION
DataSection
  ds_PBWindowNames:
  Data$ "Asm Debugger", "Data Breakpoints", "Debug Output", "Library Viewer", "Memory Viewer"
  Data$ "Procedure Callstack", "Profiler Settings", "Profiler", "Purifier Settings", "Structure Viewer"
  Data$ "Variable Viewer", "Watch List", "HTML Help", "Find in files", "Platform SDK Collection"
  Data$ "Q"  ; Quit
EndDataSection
;-} DATASECTION