Debugging

Not sure how OutputDebug is suppose to work. My first guess is there would be a debug screen like the variable and their content screen and the last script lines executed screen etc. (Maybe I am missing something).

Anyway I wrote a very simple script that shows an Edit box at the top right of the screen which debug messages can be sent to through either Print(str) or PrintLn(str) which attaches a line feed character.

Print(str) {
	static create = true, output
	if create {
		create =
		Gui, 99: -Caption
		Gui, 99:Margin, 0, 0
		Gui, 99:Add, Edit, w500 r5 voutput
		x := A_ScreenWidth - 500
		Gui, 99:Show, NoActivate x%x% y0
	} else
		GuiControlGet, output, 99:
	GuiControl, 99: , output, %output%%str%
	Gui, 99:Show, NoActivate
}
PrintLn(str) {
	Print(str . "`n")
}

Edit: Now shouldn't conflict with other Gui Windows.
Edit2: Added NoActivate.

Not sure how OutputDebug is suppose to work. My first guess is there would be a debug screen like the variable and their content screen and the last script lines executed screen etc. (Maybe I am missing something)

You are missing an utility like DebugView.

You are missing an utility like DebugView.

Yes, indeed I am missing that. I will continue to miss that as all I really want is a simple box where I can print messages, not some full blown application :shock:

I like to use StdOut, since PSPad, SciTE and other editors capture it (and display it in a tool window.) FileAppend,text,* seems to buffer output (making real-time debugging difficult), so I use DllCall.

#Persistent
#NoTrayIcon  ; closing the console leaves the tray icon stranded
DllCall("AllocConsole")
SetTimer, tick, 1000
return

tick:
StdOut(A_Now)
return

StdOut( text, term="`n" )
{
    static hStdOut=-1

    if (hStdOut = -1) {
        hStdOut := DllCall("GetStdHandle", "UInt", -11) ; -11=STD_OUTPUT_HANDLE
        if ErrorLevel
            return 0
    }

    ; for convenience:
    text .= term

    ret := DllCall("WriteFile"
        , "UInt", hStdOut       ; hFile
        , "UInt", &text         ; lpBuffer
        , "UInt", StrLen(text)  ; nNumberOfCharsToWrite
        , "UIntP", bytesWritten ; lpNumberOfCharsWritten
        , "UInt", 0)            ; lpOverlapped

    return bytesWritten
}

If run from PSPad, AllocConsole() does nothing, otherwise it shows a standard Windows console (as in command prompt.)

I've never used OutputDebug either...

I like to use StdOut, since PSPad, SciTE and other editors capture it (and display it in a tool window.) FileAppend,text,* seems to buffer output (making real-time debugging difficult), so I use DllCall.

#Persistent
#NoTrayIcon  ; closing the console leaves the tray icon stranded
DllCall("AllocConsole")
SetTimer, tick, 1000
return

tick:
StdOut(A_Now)
return

StdOut( text, term="`n" )
{
    static hStdOut=-1

    if (hStdOut = -1) {
        hStdOut := DllCall("GetStdHandle", "UInt", -11) ; -11=STD_OUTPUT_HANDLE
        if ErrorLevel
            return 0
    }

    ; for convenience:
    text .= term

    ret := DllCall("WriteFile"
        , "UInt", hStdOut       ; hFile
        , "UInt", &text         ; lpBuffer
        , "UInt", StrLen(text)  ; nNumberOfCharsToWrite
        , "UIntP", bytesWritten ; lpNumberOfCharsWritten
        , "UInt", 0)            ; lpOverlapped

    return bytesWritten
}

If run from PSPad, AllocConsole() does nothing, otherwise it shows a standard Windows console (as in command prompt.)

I've never used OutputDebug either...

I like your approach to debug output better, it doesn't take up a gui instance and there's not much to do as far as keeping it from stealing focus. My only question, how do I make closing the cmd prompt NOT kill my script?

Thanks

I like to use StdOut, since PSPad, SciTE and other editors capture it (and display it in a tool window.) FileAppend,text,* seems to buffer output (making real-time debugging difficult), so I use DllCall.

Looks interesting, I'll have to look into the next time I am writing something in AHK. Preferably I would like to setup eclipse to recieve the output. (free at eclipse.org - don't take as endorsement, this is not your average code writing software!! It is almost exclusively geared towards Java for instance.. and is a resource hog ... real-time compile error checking etc.).

there's not much to do as far as keeping it from stealing focus.

It steals focus? I was not aware of that. However I think I've only used it to test the TableLayout script while resizing another GUI so it obviously wouldn't have been able to steal focus there.

Actually, Gui,Show has two no-activate options.

NoActivate: Unminimizes or unmaximizes the window, if necessary. The window is also shown without activating it.

NA: Shows the window without activating it.

My only question, how do I make closing the cmd prompt NOT kill my script?

The close event can be intercepted by using SetConsoleCtrlHandler(), but it seems while that allows the script to clean up properly, the process is always terminated after some system-defined timeout.

The following script demonstrates two things:[*:2q7rsgxs]Using a mouse hotkey and WM_NCHITTEST to prevent the script from exiting when the user presses the close button.
[*:2q7rsgxs]Using SetConsoleCtrlHandler() to clean up properly (i.e. remove the tray icon) when the console is closed some other way (i.e. sysmenu->Close.)

#NoEnv

DllCall("AllocConsole")

if (hwnd := DllCall("GetConsoleWindow"))
    GroupAdd, MyConsole, ahk_id %hwnd%

DllCall("SetConsoleCtrlHandler", "uint", RegisterCallback("HandlerRoutine"), "int", 1)

return


HandlerRoutine(dwCtrlType)
{
    if dwCtrlType = 2  ; CTRL_CLOSE_EVENT
        ExitApp  ; clean up properly
    return false
}


#IfWinActive ahk_group MyConsole

LButton::Click Down
LButton Up::
    CoordMode, Mouse, Screen
    MouseGetPos, x, y
    SendMessage, 0x84,, (x & 0xFFFF) | (y & 0xFFFF) << 16  ; WM_NCHITTEST

    if (ErrorLevel = 20) ; close button
        DllCall("FreeConsole")

    Click Up
return

Unfortunately (for me), WM_NCHITTEST doesn't work accurately with Windows Vista's Aero interface: It returns HTMAXBUTTON, HTTOPRIGHT, HTTOP or HTCLOSEBUTTON depending on where in the close button the mouse cursor is.

Actually, Gui,Show has two no-activate

Thanks for posting this.

You can't really compare DbgView with this - it has filters, history, time, doesn't influence your app anyway (contrary to that, gui num 99 is often used), colors, IS online when your script crashes, can monitor multiple scritps, etc..

You can't really compare DbgView with this - it has filters, history, time, doesn't influence your app anyway

This was not meant to be a robust solution. It's purpose is purely simplicity. If you are experiencing so many problems with code you write, you may want to adopt better practices! I haven't had any need for complex debugging in ages

This was not meant to be a robust solution. It's purpose is purely simplicity. If you are experiencing so many problems with code you write, you may want to adopt better practices! I haven't had any need for complex debugging in ages

Dude, chillout, smoke something....

Dude, chillout, smoke something....

Sorry if it read as defensive, just wanted to point out that it is not meant to be a replacement for DebugView, just a simple alternative.

I made me this little function which can be put in the library:

RunDebugView()
var := "hallo"
outputdebug, Line%A_LineNumber% var=%var%


return

RunDebugView(){
debuggerpath .= "c:\programme\autohotkey\DebugView\Dbgview.exe"
debuggerTitel := "DebugView on \\" . A_ComputerName . " (local)"
IfExist, %debuggerpath%
 ifwinNotexist, %debuggerTitel%
    Run, %debuggerpath%
sleep, 1000
}

maybe its just for simple minded folks like me, but I like the idea...

small suggests like:

why not call it DEBUG() ?

maybe include an optional Debug(text = "", pause = 0) {

option so that if pause // msgbox or pause ??

and... maybe
a global DEBUGon? var...

to if !DebugON // Return... ?



and... anyone know...

is there an alternate to actual `n to designate end of line ???