Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

Debugging


  • Please log in to reply
26 replies to this topic
Xander
  • Members
  • 140 posts
  • Last active: Nov 13 2007 08:31 PM
  • Joined: 23 Sep 2007
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.

olfen
  • Members
  • 115 posts
  • Last active: Dec 25 2012 09:48 AM
  • Joined: 04 Jun 2005

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.

Xander
  • Members
  • 140 posts
  • Last active: Nov 13 2007 08:31 PM
  • Joined: 23 Sep 2007

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:

Lexikos
  • Administrators
  • 9449 posts
  • Last active:
  • Joined: 17 Oct 2006
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...

thefunnyman
  • Members
  • 21 posts
  • Last active: Apr 16 2009 07:04 PM
  • Joined: 04 Aug 2007

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

Xander
  • Members
  • 140 posts
  • Last active: Nov 13 2007 08:31 PM
  • Joined: 23 Sep 2007

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.).

Xander
  • Members
  • 140 posts
  • Last active: Nov 13 2007 08:31 PM
  • Joined: 23 Sep 2007

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.

Lexikos
  • Administrators
  • 9449 posts
  • Last active:
  • Joined: 17 Oct 2006
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.

Xander
  • Members
  • 140 posts
  • Last active: Nov 13 2007 08:31 PM
  • Joined: 23 Sep 2007

Actually, Gui,Show has two no-activate

Thanks for posting this.

majkinetor
  • Moderators
  • 4512 posts
  • Last active: Oct 02 2013 02:33 PM
  • Joined: 24 May 2006
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..

Xander
  • Members
  • 140 posts
  • Last active: Nov 13 2007 08:31 PM
  • Joined: 23 Sep 2007

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 :O

majkinetor
  • Moderators
  • 4512 posts
  • Last active: Oct 02 2013 02:33 PM
  • Joined: 24 May 2006

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....

Xander
  • Members
  • 140 posts
  • Last active: Nov 13 2007 08:31 PM
  • Joined: 23 Sep 2007

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.

haichen
  • Members
  • 200 posts
  • Last active: Oct 20 2013 01:14 PM
  • Joined: 05 Feb 2007
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
}


Joy2DWorld
  • Members
  • 562 posts
  • Last active: Jun 30 2014 07:48 PM
  • Joined: 04 Dec 2006
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 ???