AutoHotkey Community

[procyon]

I use OutputDebugString for most of my programming tasks, and I'm sure AutoHotkey would also benefit from this easy and convenient debugging feature.

[BoBo]

Btw. Welcome procyon. Nice to know that someone from the Baltics is arround.

[Chris]

[procyon]

I use a program called DebugView from Sysinternals - http://www.sysinternals.com/ntw2k/freeware/debugview.shtml that enables me to view debug output from my programs. By inserting OutputDebugString("some_explaining_text_and_values_of_variables") to key locations I can easily find out the cause of problem, if something went wrong.
I could of course use messageboxes or in this case breakpoints in scripts, but this would require my interaction while the script is running. With OutputDebugString I can let the script/program run as normal, and determine what went wrong afterwards. Of course I could also write a logfile to disk, but IMHO DebugView is so much more convenient.
And implementing this feature in AutoHotkey should be very easy.
A command called OutputDebugString with one string parameter, that would just call void OutputDebugString(LPCTSTR lpOutputString); with the same parameter.

Edit:
I tested ListVariables a bit, but it has some annoying side effects:
1) AutoHotkey window is activated every time
2) No history of values of variables, only most recent values

Edit2:
Just in case I was a bit unclear - void OutputDebugString(LPCTSTR lpOutputString); is a standard windows API call exported by kernel32.dll

[jonny]

[toralf]

I would use it. It's a great idea, although I would not put it on high priority. If Chris could put it on his to-do/wish list, it would be great.
_________________
Ciao
toralf

[jonny]

The nature of it restricts it's usage to those who have the appropriate debugging utilities, though. I imagine this is restricted to those who are heavy coders in a different language already, which, I'd guess, is a relatively small percentage of the AHK community.

[toralf]

As procyon posted: the tool is freeware. So no problem for anyone to get it. I assume that nearly every AHK user is already useing command line tools. So why not get that tool too if he wants to have a benifit from that comand?
_________________
Ciao
toralf

[jonny]

Because up 'till now, AHK has stayed distant from other software of any kind, and I think it helps it's image a lot. It would be kind of strange to include a link to a foreign debugger on the main page, and to find out that it is intimately integrated with AutoHotkey. Call it "purity," call it "cleanness," call it whatever you want, but I think AHK should stand alone.

Of course outside software helps; I couldn't imagine using AHK without Winspector Spy, PSPad, or the countless command line tools I have in PATH. But the point is that they are optional, and use AHK features that are unobtrusive and not specialized like this would be.

As a last note, the size of AHK scripts/executables already surprises some; we should try to avoid adding more commands "on-demand" or just as a novelty. Like I said, if it's just a few lines, recompile it yourself.

[Chris]

[Mats]

Not quite. OutputDebugString is a simple Windows-API function (takes only a string as parameter) and that's all. There is no need to buffer anything. Another program (like the one from sysinternals, but there are dozens of other tools that do this) can hook into windows to receive the string. If no such program is running, no one will ever see the messages. Otherwise you see the live output just like printing to a console window.

It is a great help for debugging scripts, because you can leave your debug messages in the production code and only start the DebugString-Viewer when you want to see what's going on. No need for debug-MsgBoxes anymore!

Again: There is no penalty for using OutputDebugString without a Viewer/Debugger. And OutputDebugString is no third party tool - it's part of windows!

[procyon]

This is how OutputDebugString API call works:
when a program calls it with some string as a parameter:
OutputDebugString("some text to output");
the windows kernel determines if there is a debugger attached to the process, if so the debugger gets the pointer to the string to do whatever it feels appropriate (DebugView adds it to its display, some debuggers pop-up a message box etc.) If no debuggers are present, then it does nothing.
An example:

[jonny]

Sorry. I was uncertain of the exact nature of it; I think this sounds great.

[JSLover]

[jonny]

I have debugging code I use with pclip to output errors to the familiar console; just my two cents.