Jump to content

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

OutputDebugString implementation


  • Please log in to reply
51 replies to this topic
BoBo
  • Guests
  • Last active:
  • Joined: --

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

Kinda information hiding! :shock: Where is that debuging code, huh! Hail the Forum, let's shout out loud: "Give us that code little Joe, give us that code little Joe, Ole Ole Ole Oleeee" (heard last sunday at the English football premier league)

C'mon shy guy ...

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

OutputDebugString is a simple Windows-API function (takes only a string as parameter) and that's all. There is no need to buffer anything. ... 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.

That helps a lot. Thanks for explaining it.

No need for debug-MsgBoxes anymore!

I'm warming up to the idea :)

...not many people besides programmers know about debugging etc. So my suggestion would be - a command similar to ListVariables, but - it should let user specify some text to output, and the output would be shown on one of the windows accessible from "View" menu of AHK.

That would take up memory, so I guess it could be limited to a 32 KB buffer containing only the most recent messages.

if you implement my WinAPI command, this would automatically be implemented too.

I want to add DllCall sometime but I've looked into it and it's not exactly simple. Here is an article that explains one approach: http://www.developer...icle.php/636741

I recommend both, the OutputDebugString command & the AHK DebugView. Perhaps a separate .exe that hooks into all existing & newly run AHK processes & adds that menu item, so each script isn't operating as it's own DebugView. One .exe would catch the debug messages & send it to any AHK windows that request it & thus be off while the other .exe isn't running. My 1st idea was for the new .exe to add the menu item, but it could exist & start the program if it's not running, any AHK could start it, but it would only run once & work for all AHK's. Perhaps while running tho, it would add a menu item "Close Debugger" to stop that process.

Those are great ideas but I think they're getting too elaborate for the expected number of people who would actually use such a feature.

How about a quick and dirty solution such as:
FileAppend, Some debug text.`n, **Debug ; Calls OutputDebugString().

Mats
  • Guests
  • Last active:
  • Joined: --

How about a quick and dirty solution such as:
FileAppend, Some debug text.`n, **Debug ; Calls OutputDebugString().

Personally, i think this is all you need. Although i would prefer a new command like "DebugPrint, Some debug text", because it's not exactly a file that OutputDebugString appends to. This would at least be perfectly "undirty" (and maybe even quick/easy enough to implement!?).

procyon
  • Members
  • 14 posts
  • Last active: May 16 2005 02:41 PM
  • Joined: 10 Feb 2005
I spent some time with AHK source, and compiled my version with OutputDebugString support

I added:
1) to script.h enum
ACT_ODS
2) to globaldata.cpp
{"OutputDebugString", 1, 1, NULL}
3) to script.cpp in Line::Perform
case ACT_ODS:
OutputDebugString(ARG1);
return OK;


Compiled result with test script is available from here
Edit: link removed

jonny
  • Members
  • 2951 posts
  • Last active: Feb 24 2008 04:22 AM
  • Joined: 13 Nov 2004
Well, it seems to be working OK, but where can we get a proggie that can read the output? :?

Btw, this is the first time I can remember that someone's actually recompiled it and saved Chris some work (even though it seemed to be pretty easy). I'd love to do some of that myself, but I'm still a newb in C++.

Edit: Ok, sorry, I'm just airheaded. I'll follow the link you gave to DebugView.

jonny
  • Members
  • 2951 posts
  • Last active: Feb 24 2008 04:22 AM
  • Joined: 13 Nov 2004
:shock: :shock: :shock: :shock: :shock: :shock: :shock:

PERFECT! Woot!

Dude, I love ya. This will make things so much easier. Just tested it now. But maybe the keyword could be shortened a bit? There's currently no other "debug" commands, so maybe it could just be "Debug".

*shock and awe* *now a total convert from the cynical critic*

P.S. BoBo, do you still want that code? It's really just a one-liner injection.

Rajat
  • Members
  • 1904 posts
  • Last active: Jul 17 2015 07:45 AM
  • Joined: 28 Mar 2004
this is cool!

Chris, probably u've already decided in its favour, but i feel its a nice addition with practically no extra cost.

There's currently no other "debug" commands, so maybe it could just be "Debug".

yeah that'd help!

MIA

CleanNews.in : Bite sized latest news headlines from India with zero bloat


Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
Nice.

The reason I wanted to "bury" OutputDebug in with FileAppend is because I try to avoiding adding new commands that will go unused by 95% or more of users. This is because adding more commands makes the program seem more complex than it really is. I've tried to compensate a little for this by putting the most commonly used commands in a large font in the command list.

I was thinking that the FileAppend method would be like this:
FileAppend, Text, **
... and perhaps it could be made so that in this mode, commas don't need to be escaped within "Text".

However, I see the merit of OutputDebugString or Debug too. And using one of them would avoid "dirtying" FileAppend with a weird exception mode. So which of these seems best?

Mats
  • Guests
  • Last active:
  • Joined: --

This is because adding more commands makes the program seem more complex than it really is.

I disagree on this. Introducing special modes and exceptions adds way more complexity to a language than a larger amount of commands.

I've tried to compensate a little for this by putting the most commonly used commands in a large font in the command list.

My proposal is this:
Add one more command for all debugging "modes" that will/may come and let the actual debugging function be the first parameter (just like in the "control" command).

So there could be:
debug, print, Some debug text (our OutputDebugString)
debug, log, Some debug text (maybe someday there'll be a logfile!?)
debug, break, Some debug text (I've read about plans for a line debugger...)
Just my 2 cents...

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004
I see your point, and those are good suggestions too. Anyone else have a preference?

ranomore
  • Members
  • 171 posts
  • Last active: Mar 01 2013 01:41 PM
  • Joined: 06 Nov 2004

Introducing special modes and exceptions adds way more complexity to a language than a larger amount of commands.


I usually try to read through the entire help file for a command before using it. Everything will make sense until I read about that special mode... :?

Rajat
  • Members
  • 1904 posts
  • Last active: Jul 17 2015 07:45 AM
  • Joined: 28 Mar 2004
my general opinion : if a proposed cmd has more merits than costs (for example file size shooting up considerably), it should be added without considering the number of commands ahk already has.

MIA

CleanNews.in : Bite sized latest news headlines from India with zero bloat


jonny
  • Members
  • 2951 posts
  • Last active: Feb 24 2008 04:22 AM
  • Joined: 13 Nov 2004

Debug

Outputs a string for a standard debugging program to display.

Debug, FutureUse, Text


:p 8)

BoBo
  • Guests
  • Last active:
  • Joined: --

Outputs a string for a standard debugging program to display.

I love standards and interfaces :D

Chris
  • Administrators
  • 10727 posts
  • Last active:
  • Joined: 02 Mar 2004

Debug, FutureUse, Text

Having a FutureUse parameter has often been a difficult decision for me. Lately, I've been leaning toward avoiding them because maximum usability in the present seems more important than usages in the future that might never materialize.

With that in mind, I think the new command should be called either:
OutputDebug: The advantage being that it's easy to remember for most of its users because these users tend to know about the OutputDebugString() API function.

DebugOutput: The advantage being that if future debug commands are added, they will all be grouped together. However, I'm having trouble envisioning other debug *commands* because the debugging will probably be more a "mode" that you select via the script's main menu. In other words, there might never be any other debug commands per se.

So if it seems okay to most, I will call it OutputDebug and use Procyon's code above.