Another debugger for AutoIt

[Heron]

Heron,

I found recently your debugger and I think is a great tool!!

I hope you are still working on the project...

Just some questions:

1)

It's possible (in the next release) to delete the DBugScript file on exit?

2)

Wich is the best way to monitoring array value step by step (not using code tooltips)?

3)

Can you shortly explain the meaning of the "Save list", "Restore original list" buttons?

Thanks!!

Hi Polps!

Thanks for your kind words. Actually I'm not working on it anymore, partly because of the pale reactions on the forum. I just decided this weekend to create a Youtube info video as appetizer. Maybe more people will like it. I use it myself from time to time and it has never crashed (although there are odd issues ).

I'll try to post a link to the video now.

Bye

DBUG video

(Sorry for the bad quality, it's my first video ever!)

Edited September 25, 2010 by Heron

[Heron]

Oh, and about your questions:

1)

It's possible (in the next release) to delete the DBugScript file on exit?

-> yes, *if* there is a new release, this is not a big deal.

2)

Wich is the best way to monitoring array value step by step (not using code tooltips)?

-> not sure what you're asking for. For one value of the array you could add a variable to the list (ex: v_arr[1][2]). It will be shown every time you break in the same function. And after a restart of the script you can 'restore saved list' (if you saved it first ).

3)

Can you shortly explain the meaning of the "Save list", "Restore original list" buttons?

-> 'Save list' will store the (modified) variable list (and the command/result pane) for the particular function.

'Restore original list' will restore the list with all the variables of the current function (or global vars when outside a function).

Hope this helps.

[polps]

Heron, tanks for your replay.

First af all I want say you that I don't understand "the pale reactions on the forum" because I really think your tool is very useful.

I'm sorry for my english because is not my mother tongue; about the following request, they are only suggestion and is not a criticism review!

Regarding the array monitoring, I would be able to see all the array value.

At the moment, I'm using this method:

a write the array name in the <command> window

b click on the "execute command" button

c see the value on the <result> window (all the array value are correctly displayed)

But it seems to me that the <result> window is not automatically refreshed; if the array value is modified inside a loop, for each cycle I have to press the "execute command" button to see the refreshed value. Is it correct?

So, the question are the following:

Would be possible to add the array ( or variable) name in the <command> window by double click in the listwiev item? (instead writing the name)

Would be possible refresh the <command> window for each step? (instead pressing the "execute command" button)

I report two more points

1) How to exit from the loop used for the GUI? It seems to me that if I use the option "GUIOnEventMode" = 1 the event (eg. $GUI_EVENT_CLOSE) are not detected and the script fall in a never ending loop.

2) If I exit from the debugger the breakpoint (blue mark) and the cursor (white mark) are not correctly erased.

Thanks again!

Edited September 27, 2010 by polps

[Heron]

Heron, tanks for your replay.

First af all I want say you that I don't understand "the pale reactions on the forum" because I really think your tool is very useful.

I'm sorry for my english because is not my mother tongue; about the following request, they are only suggestion and is not a criticism review!

Regarding the array monitoring, I would be able to see all the array value.

At the moment, I'm using this method:

a write the array name in the <command> window

b click on the "execute command" button

c see the value on the <result> window (all the array value are correctly displayed)

But it seems to me that the <result> window is not automatically refreshed; if the array value is modified inside a loop, for each cycle I have to press the "execute command" button to see the refreshed value. Is it correct?

So, the question are the following:

Would be possible to add the array ( or variable) name in the <command> window by double click in the listwiev item? (instead writing the name)

Would be possible refresh the <command> window for each step? (instead pressing the "execute command" button)

I report two more points

1) How to exit from the loop used for the GUI? It seems to me that if I use the option "GUIOnEventMode" = 1 the event (eg. $GUI_EVENT_CLOSE) are not detected and the script fall in a never ending loop.

2) If I exit from the debugger the breakpoint (blue mark) and the cursor (white mark) are not correctly erased.

Thanks again!

Hi Polps,

your english is perfectly clear for me, no problem.

The command pane is not refreshed indeed. This is intended, there can be another or more statements in the command area, and you don't want them to execute each time automatically! But I admit that the array's values cannot be read easily from the variable list (only a few values at a time). I've been thinking about it before, when you click on the variable in the list and then the values are displayed in the result pane? Should that be an option?

Your other points:

1. Don't know what script you are testing. I have no problems with the events, can you send your script maybe?

2. The white dots are not removed indeed, this can be fixed with little effort I think. The blue breakpoints however are comfortable to remain between the debug sessions I think. Do you agree?

Thanks for your response, highly apprieciated!

Gr, Heron

Edited September 27, 2010 by Heron

[polps]

The command pane is not refreshed indeed. This is intended, there can be another or more statements in the command area, and you don't want them to execute each time automatically! But I admit that the array's values cannot be read easily from the variable list (only a few values at a time). I've been thinking about it before, when you click on the variable in the list and then the values are displayed in the result pane? Should that be an option?

Yes. Would be a good option.

1. Don't know what script you are testing. I have no problems with the events, can you send your script maybe?

Ok, see my attached script. It's only a little test.

If I run the script with the "resume" button I have no problem and I exit the loop with pressing X.

But, if I want run the script step by step It's impossible to break the loop even pressing X..

Test.au3

2. The white dots are not removed indeed, this can be fixed with little effort I think. The blue breakpoints however are comfortable to remain between the debug sessions I think. Do you agree?

Ok.

Bye

Polps

[Heron]

Yes. Would be a good option.

Ok, see my attached script. It's only a little test.

If I run the script with the "resume" button I have no problem and I exit the loop with pressing X.

But, if I want run the script step by step It's impossible to break the loop even pressing X..

Test.au3

Ok.

Bye

Polps

Hi Polps,

I see what you mean. You confuse the loop with the breakpoint. The script is in one of two modes: or it is executing normally, or it paused. When it is paused (when you check the variables, etc) then the loop is halted. The events, like closing the window, are not stored for when the loop is executed again and thus not detected. So yes, the only way is to resume (the script is running again) and then close the window.

What you can do however is to set a breakpoint in the GUIClose function, resume and close the window. The script is halted in the eventhandler then.

Greetz, Heron

[polps]

Hi Heron,

The events, like closing the window, are not stored for when the loop is executed again and thus not detected.

Using the stumpii debugger the events are detected even in step by step mode. So I was not sure if this behaviour, in your debugger, was a bug or a new requirement.

What you can do however is to set a breakpoint in the GUIClose function, resume and close the window. The script is halted in the eventhandler then.

Anyway, this is not really a big problem and your solution is ok.

Tanks again for your answers and kindness.

Regards

Pols.

[xbtsw]

Hi Heron,

Thanks for your great work!

I hope I find your post earlier, since this is the best pure AutoIt debugger I have seen so far (and still working with latest version of AutoIt and SciTe)

It does everything I'd expect for a debugger, stepping, (conditional)breakpoint,variable monitor(table/hovering)/modification and even a probe to execute code on the fly!

When I download it, at first it doesn't work for me because it tries to find "AutoIt3.exe" from registry, which not exist on my system. However, I think a better approach that guaranteed to work is to use @AutoItExe marco. So change the code in Dbug.au3, line 789-792 to

$AutoItDir = @AutoItExe
$run = StringFormat('%s DbugScript.au3 "%s" "%s" "%s" "%s"', $AutoItDir, @ScriptName, @ScriptDir, $DBGnotifyFun, $DBGcommandFun)

$res = Run($run, @ScriptDir, default, 0x4)  ;run the shadow script (with scriptname and -directory passed as arguments)

Then it works beautifully.

I think after polish it a little and add some features, it could become the official debugger for AutoIt. Do you got any plan to resume the project?

Bests,

xbtsw

Edited August 10, 2011 by xbtsw

[Rinzwind]

AutoIt really needs a official debugger... I was somewhat astonished to find out that AutoIt does not have one. I depend on it in other languages. VBScript does have VBSEdit. Great scripting editor/debugger. What do the AutoIt maintainers think about debuggers? Large scripts need decent debugging capability I guess... Well it makes life easier at least. I will try out your debugger!

[skin27]

You may also check the following AutoIT debugger: http://www.thefoolonthehill.net/drupal/AutoIt%20Debugger

At the end naming, modules, decent functions etc will make your life also a lot easier when debugging. Mostly some ConsoleWrite() statements will be enough then.

[BrewManNH]

AutoIt really needs a official debugger... I was somewhat astonished to find out that AutoIt does not have one. I depend on it in other languages.

We like to live on the wild side here, figuring out where our code goes wrong the old fashioned way.

VBScript does have VBSEdit. Great scripting editor/debugger. What do the AutoIt maintainers think about debuggers? Large scripts need decent debugging capability I guess... Well it makes life easier at least. I will try out your debugger!

The size of the script shouldn't matter as to whether a debugger is needed or not. Figuring out where you screwed up should be fairly painless if you're writing code that is easy to follow. You can have a 50 line script that takes you an hour to figure out why it only intermittently fails, and a 4000 line script that takes 2 minutes to see where you went wrong.

[Rinzwind]

A debugger just helps you get to the root cause of problems much quicker. It replaces tedious consolewrites and you can follow program flow easily and watch variable values. But you all know that already

Maybe you can encourage projects like these. The author is somewhat disappointed in the response he gets, but it is a sincerely missed feature by programmers (I think). Of course we can program without, but it helps a lot. AutoIt debugging automated you know...

I tried the AutoItDebugger (that with some additions would be a nice code editor also). But it is a hacked and slow way to do it (program executes very slow).

[bluebearr]

I like this debugger too. I find it to be more stable than the GUI debugger.

One issue I ran into with this debugger is that I cannot do tests based on @error. It might be possible to work around this issue to have @error and @extended copied to custom variables in DbugScript.au3 and instances of @error and @extended replaced with these custom variables, but I haven't worked with it yet. Still, very handy, easy to use script. I like that I can make it portable and run it from a network share on my test machines.

[pandel]

Just for the record, as I think this should be mentioned here, too: I did some small modifications to this wonderful debugger (translation, sortable variable list and such) and the developer of >ISN AutoIt Studio was so kind to transparently integrate it into its AutoIt IDE. Many thanks for that!

[Bluesmaster]

Please do not stop developing it.

- Its lightweight

- it has a console ( the most important thing in a scripting language imo)

- it has instant tooltips

that increases my productivity enormous.

 

Just a small question: what happens to the command line-parameters? When I put some to the script (SHIFT + F8  in Scite) the an error occurs:

Dbug.au3 (32) : ==> Array variable has incorrect number of subscripts or subscript dimension range exceeded.

regards

Bluesmaster

[valdemar1977]

Hi all!

After long time of silence in this topic I'm put my customized version of original Herons DBUG. 

Added:

- sorting in variables list by any column and drag in any order.

- by default 1D and 2D arrays showing in list (1D as [1 2 3 4 5 ... N] 2D as ["row1:column1 value" "row1:column2 value" "row1:column3 value" ... "row1:columnN value"]...[rowN:columnN value ], 3D and more dimensional arrays not showing 

- extended information toggle button [..] (useful for variables with type arrays, dllstruct or object) 

Changed:

- DBUG window now has a minimal size, you cannot change it vertical and horizontal size to zero.

- previously when you edit variable name or insert new one in edit mode when you click with mouse out of edit field name changed on name where you click (sorry for my english), use Enter (or Esc) for complete editing and Ctrl+Z for Undo. Use arrows button for scrolling left or right in edit mode.

- clear and execute command buttons now docking around of appropriate edit field 

- command result window is now disable for input

All modifications has a ; valdemar1977 comment at the end of line.

How to use DBUG

- put Dbug.au3 to Autoit include directory or user include directory (setup user include in SciTe settings - "Tools"->"SciTe Config"->"General 1"->"User Include Folder")

- put IMAGES folder in Autoit home (location of AutoIt3.exe file)

- add #include <Dbug.au3> in your code (or #include "FULL_PATH_TO_FILE\Dbug.au3" if you put it anywhere)

- use ;STOP DBUG for excluding some part of you code from debugging, ;START DBUG will resume debug.

Thank you Heron again!

Dbug.zip

Edited April 27, 2015 by valdemar1977

[polps]

Hi Valdemar.

before all, I want to tanks you for your work..

After that, I tried to used your version (with a very simple script) but it seems not working.

The "shadow" script (dbugscript.au3) was created but nothing appears on the screen.

No errors appears in the Scite Console.

Simply, the script run and exit without do anything.

Can you help me to find the problem?

Thanks again

Gianluca.

 

 

 

[valdemar1977]

Hi Valdemar.

before all, I want to tanks you for your work..

After that, I tried to used your version (with a very simple script) but it seems not working.

The "shadow" script (dbugscript.au3) was created but nothing appears on the screen.

No errors appears in the Scite Console.

Simply, the script run and exit without do anything.

Can you help me to find the problem?

Thanks again

Gianluca.

 

 

 

​

​Hi, Gianluca.

Can you send me your script for analyzing?

Does it work with original dbug.au3?

[polps]

Hi Valdemar..

yes, good idea!  I tried just now and also original DBUG did not work.

So, your script is not the guilty!!! 

Now, I have to investigate...

Thanks a lot

 

[valdemar1977]

Hi Valdemar..

yes, good idea!  I tried just now and also original DBUG did not work.

So, your script is not the guilty!!! 

Now, I have to investigate...

Thanks a lot

 

​Hi, Gianluca.

Please double check that you code doesn't contain ;STOP DBUG string in the start.

Also check that you have a #AutoIt3Wrapper_UseX64=n directive at the start of the script. DBUG won't work with 64-bit wrapper.

Also try to use ;STOP DBUG for excluding some part of you code from debugging, for understanding what part of you code generate a problem in DBUG. Do not forget to add ;START DBUG string in part when you need to continue debug.

Good luck

Edited May 6, 2015 by valdemar1977