Jump to content

7 Screenshots

About This File

Dbug is graphical debugger for AutoIt.

Project started by @Heron in 2009 and now supported by @asdf8 and @valdemar1977.

Features

  • Debug the complete script or just parts of it
  • Display run status (line number of currently executed function)
  • GUI default always-on-top in the upper right corner for comfortable debugging
  • WM_NOTIFY and WM_COMMAND hook to prevent interference with possible message handlers
  • Display scope, type and value of variables, expressions, macro's and constants (global AND function local)
  • Execute commands in an immediate window. Can be expressions, functions and assignments
  • Detailed display of array, struct and object variables
  • Dynamic display of variable value in the source code (under cursor)
  • Array table viewer with ability to view the sub-arrays, the correct handling of macro @Error, @Extended and other changes
  • OEM and ANSI console output
  • Conditional breakpoints
  • Saving settings and debugging state
  • and much more...

How to use

  • Extract from downloaded archive _Dbug.au3 to your Autoit include dir
  • Add #include <_Dbug.au3> in to your code and run code
  • Before compile or buid comment or remove #include <_Dbug.au3> from your code

What's New in Version 2018.05.24

Released

Changelog:

2018.05.24 - Fixed icon id's

2018.05.17 - Fixed problem with icl  (problem with wrong Dbug icon on the taskbar). Delete dbug.icl from your %TEMP% folder before start a new version. 

Thank you @asdf8 for collaboration.

2018.04.25 - Fixed missed #Include <WinAPISysWin.au3>




User Feedback

You may only provide a review once you have downloaded the file.

There are no reviews to display.

  • Similar Content

    • By TheAutomator
      Hi everyone!

      I'm using AutoIt for several years now and I really get the hang of it!
      I'm quite the curious OCD perfectionist kind of guy, so I can't help wondering..
      what would be the best way to program stuff for the compiler / interpreter / scripting engine?
      We're talking about the inner workings of the AutoIt's core here, and how to give it as less friction as possible but also take care of the machine running the script.
      For example,
      Imagine a script where we would constantly have to assign a Boolean value to a variable:
      ; A: local $bool = false $bool = true $bool = true $bool = false ; B: local $bool = false check(true) check(true) check(false) func check($b) if $bool = $b then return $bool = $b endfunc In this case, would it be better to just overwrite (A) the variable or first check if we really need to (B)?
      What would be best for the computers memory if it had to do this for a year non stop?
      Another example, imagine you're writing a function with an if statement.
      If you would look under the hood of AutoIt, what would be the best way to give your computer as less work / code nesting stack filling as possible:
      ; A: func decide($b_Input) if $b_Input then ;do something else ;do something else endif endfunc ; B: func decide($b_Input) if $b_Input then ;do something return endif ;do something else endfunc Last one for now:
      ; A: while 1 ; do stuff wend ; B: while true ; do stuff wend Isn't AutoIt taking an extra step in converting 1 to a Boolean in example (A)?
      Or is it the other way around and does the (B) way make AutoIt first convert a keyword (true or false) to a numerical value (0 or 1).
      I think this kinda detail stuff is quite interesting, makes me wonder how AutoIt converts and runs our code.
      What are your opinions on this topic?
      Any coders who know more about the inner workings of AutoIt?
      Any people like me who ask themselves similar questions (with examples)?

      Let me know! 😉
    • By Pickpocketz88
      First I would just like to say HELLO! to anyone reading. It has been a while since I've posted to the Forums but I'm always crawling around.
      Now to the matter at hand. I have been looking high and low for a simplistic answer my burned out brain can find but to no avail. I've only recently upped my AutoIt skill and only by a little bit such as ordering my script neatly with my own UDFs and using Global/Dim more often to make my GUI creation understandable and easy to keep things orderly. My current problem however is figuring out how to make my newest endeavor work which is my own "Debugger". I've made a GUI with an Edit Control to display what my Variables are holding and other information from a concurrently running Script. I have access to all of the scripts I'm attempting to connect but I'm dumbfounded on how I would separately read variable information from one running script into another. I'll provide my "Debugger" script that I want to read variables into and a "Meta Script" I'd want to pass info from.
      #Region Include Files #include <AutoItConstants.au3> #include <GUIConstantsEx.au3> #include <WindowsConstants.au3> #include <ColorConstantS.au3> #EndRegion #Region AutoIt Options ;Opt("TrayAutoPause", 0) ;Opt("TrayMenuMode", 3) #EndRegion #Region Hotkeys HotKeySet("{ESC}", "ExitProgram") HotKeySet("{PGDN}", "PauseProgram") HotKeySet("!1", "Snippet_1") HotKeySet("!2", "Snippet_2") HotKeySet("!3", "Snippet_3") HotKeySet("!4", "Snippet_4") HotKeySet("!5", "Snippet_5") HotKeySet("!6", "Snippet_6") HotKeySet("!7", "Snippet_7") HotKeySet("!8", "Snippet_8") HotKeySet("!9", "Snippet_9") #EndRegion #Region Global Variables #Region Globals Global $gMain, $ctrlEdit ;, $gParent #EndRegion #Region $gMain Params Dim $gMainW = @DesktopWidth / 2 Dim $gMainH = @DesktopHeight / 2 Dim $gMainX = (@DesktopWidth / 2) - ($gMainW / 2) Dim $gMainY = (@DesktopHeight / 2) - ($gMainH / 2) Dim $gMainStyle = $WS_POPUP Dim $gMainStyleEx = -1 ;Dim $gMainParent = $gParent #EndRegion #Region $ctrlEdit Params Dim $ctrlEditW = Round($gMainW * 0.98) Dim $ctrlEditH = Round($gMainH * 0.98) Dim $ctrlEditX = ($gMainW - $ctrlEditW) / 2 Dim $ctrlEditY = ($gMainH - $ctrlEditH) / 2 Dim $ctrlEditStyle = -1 Dim $ctrlEditStyleEx = -1 #EndRegion #EndRegion #Region GUI Initialization ;$gParent = GUICreate("", -1, -1, -1, -1, -1, $WS_EX_TOOLWINDOW) $gMain = GUICreate("", $gMainW, $gMainH, $gMainX, $gMainY, $gMainStyle, $gMainStyleEx) GUISetBkColor($COLOR_BLACK, $gMain) $ctrlEdit = GUICtrlCreateEdit("MainW: " & $gMainW & @CRLF & "MainH: " & $gMainH & @CRLF & "EditW: " & $ctrlEditW & @CRLF & "EditH: " & $ctrlEditH, $ctrlEditX, $ctrlEditY, $ctrlEditW, $ctrlEditH, $ctrlEditStyle, $ctrlEditStyleEx) GUISetState(@SW_SHOW, $gMain) #EndRegion MainFunction() #Region Main Function (GUI) Func MainFunction() While 1 $msg = GUIGetMsg() If $msg = $GUI_EVENT_CLOSE Then Exit EndIf WEnd EndFunc #EndRegion #Region Functions Func Functions() EndFunc #EndRegion #Region Program 1 Func Snippet_1() EndFunc #EndRegion #Region Program 2 Func Snippet_2() EndFunc #EndRegion #Region Program 3 Func Snippet_3() EndFunc #EndRegion #Region Program 4 Func Snippet_4() EndFunc #EndRegion #Region Program 5 Func Snippet_5() EndFunc #EndRegion #Region Program 6 Func Snippet_6() EndFunc #EndRegion #Region Program 7 Func Snippet_7() EndFunc #EndRegion #Region Program 8 Func Snippet_8() EndFunc #EndRegion #Region Program 9 Func Snippet_9() EndFunc #EndRegion #Region Pause/Exit Functions Func PauseProgram() While 1 Sleep(1000) WEnd EndFunc Func ExitProgram() Exit EndFunc #EndRegion Pause/Exit Functions #Region Snippets #CS #CE #EndRegion #Region Other Information #CS #CE #EndRegion That's the Debugger script. Please forgive anything ignorant but point it out if you will, I'll take any pointers to get better! (I usually use a Select to get $GUI_EVENT_CLOSE but this is early on)
      Now if I made another script with a basic GUI similar to this and wanted to read say the GUI Width ($gMainW) into the Debugger Edit Control could I do it? If so, could I do it for every variable I have in a script? I read something about the Run function and adding the variables as an option parameter I believe which I think I could do with an array to keep it from being super long and ugly but would that be the only way to do this? Any information is going to be appreciated and thank you in advance for your time!
       
      Edit: Sadly it just dawned on me that I could make a UDF that will create a child window that will do this instead of having a separate script trying to invade another... I'll still be keeping an eye on this for any comments but I apologize if I wasted your time!
    • By jchd
      Here's a new version of my Dump.au3 file (dirty). I've recently added support to dissect (dump) as a treeview-like view any string in the variable conforming to a strict JSON grammar, whereever said string is: as a standalone string variable or in an array or a map. AFAICT the only relaxed constraint not implemented here is that numbers in parsed JSON may have leading zeroes, although leading zeroes are forbidden in pure JSON specifications. If required it wouldn't be hard to add this constraint.
      @c.haslam (among others) may find it useful. Use freely.
      Dump.au3
    • By c.haslam
      cDebug.au3 includes four main debugging UDFs: _GuiDebug(), _ConsDebug(), _ClipDebug() and _FormatValsForDebug(). They all dump the values of all AutoIt subtypes and expressions, in a structured manner, including nested arrays (up to 3 dimensions) and slices of them, and even DLL structs and maps. It is an alternative to a graphical debugger, offering GUI output.
      The format for calling the UDFs has been designed to make coding a call as convenient and fast as possible, minimizing coding effort and the chances of errors: the $name argument is often the same as the variables arguments, enclosed in quote marks.
      For DLL structures, if you specify a tag, cDebug checks for differences between it and what it detects. If you only specify a structure variable, it can report the structure it detects, with the values of elements.
      It does much more than MsgBox(), ConsoleWrite() and _ArrayDisplay(), in a definitely user-friendly manner, and does its best to avoid hiding your code in SciTE.
      #include cDebug no maps.au3 or cDebug.au3 at the top of your script. If you #include cDebug.au3 (the version with maps)  #include #AutoIt3Wrapper_Version=B before #include cDebug.au3
      It is fully documented in    .  During debugging and development of new features, the current version is used to debug the upcoming version, so there is much testing, even so  bugs are always possible, particularly in new features, such as reporting elements of maps whose keys match a regular expression. Bug reports and suggestions are welcome.
      These UDFs have been in regular use for some years.
      Because when cDebug was developed, maps were a use at your own risk feature, there are two streams of cDebug:
      cDebug.au3 reports maps, so to use it you must be running a version of AutoIt that supports maps, e.g. 3.3.15.0, and #include cDebug.au3 cDebug no maps.au3 does not report maps, so you can be running any recent version of AutoIt, e.g. 3.3.14.5, and #include cDebug no maps.au3 The only difference between the two streams is that map-reporting code is commented out in cDebug no maps.au3 .
      These functions are documented in cDebug.pdf
      A teaser
      This script:
      #AutoIt3Wrapper_Version=B ; beta 3.3.15.0 or greater is mandatory for cDebug.au3 #include "cDebug.au3" Local $seasons[] $seasons.summer = 'May to September' $seasons.spring = 'April' $seasons.fall = 'October to November' $seasons.winter = 'December to March' Local $aCats[3][3] = [['jack','black',3],['suki','grey',4],[$seasons,'','']] Local $i = 1 Local $tStruct = DllStructCreate('uint') DllStructSetData($tStruct,1,2018) _GuiDebug('At line '&@ScriptLineNumber,'$cats,jack is,$cats[..][$i],$i,hex,structure{uint}', _ $aCats,$aCats[0][2],$aCats,$i,Hex(-$i),$tstruct) produces:

       
      Acknowledgements
      Melba23, Kafu, ProgAndy, jchd
×
×
  • Create New...