Suggestion for improvement

[fishy]

On startig the debugger it cant communicate over the SOCKS 5 Proxy and then it shows a message:
"Unable to get update information" ( or something like this )

It would be great if you would tell me if this can be disabled by setting, or if you would put this
action onto the gui as a "update" button with proxy configuration possibility.

Is there any more information about to "communicate" or "remote" your debugger gui ?
I want to call the debugger with a file - ( think that is no problem ) and then want to tell the debugger 1-n breakpoints it shall put after load.

Please add a "hint" over the step into and step over buttons with information about the hotkey to use.
I found out F8 is step into.. is there a shortcut for step over ?
Also these information could be set into the documentation of the debugger.

Best Regards,
Fishy.

[thefoolonthehill]

On startig the debugger it cant communicate over the SOCKS 5 Proxy and then it shows a message:
"Unable to get update information" ( or something like this )

It would be great if you would tell me if this can be disabled by setting, or if you would put this
action onto the gui as a "update" button with proxy configuration possibility.

Easiest is probably to delete, or rename the file Update Program.exe in the install folder. I will get around to a GUI to disable from the program eventually.

Is there any more information about to "communicate" or "remote" your debugger gui ?
I want to call the debugger with a file - ( think that is no problem ) and then want to tell the debugger 1-n breakpoints it shall put after load.

The breakpoints are loaded from the scriptname.ini file in the \Debug folder in the folder with the script. You could update this file with the breakpoints you want before opening the debugger. Debug a file, add some breakpoints and examine the ini file. The format is pretty simple.
You cannot add breakpoints to the command line.

Please add a "hint" over the step into and step over buttons with information about the hotkey to use.
I found out F8 is step into.. is there a shortcut for step over ?
Also these information could be set into the documentation of the debugger.

It is hidden in the version history:
Added function keys to debug F5 - Run, F8 - Step Into, Shift+F8 - Step Over.
I will move to one of the other help file pages.

Thanks for the interest. Steve

[fishy]

Hey Steve,

it would be also a nice feature to debug included things like:

#include <xyz.au3>

_myXyzImplementedFunction( $this, $that )

the step into does not step into the xyz.au3's implementation of the function. It does a "step over".

maybe it's a true complex problem to solve - I can imagine this - because the current strategy is to put the script into
a debugger script ( wrapped for stepping )...

also there is a problem if you execute a debugger-script within the "Debug" Folder, then some files path's within the script you debug that are given relatively are not found anymore.

So when running a debugger script you need to put the script's working folder to the folder where the original script is located
( i think of the macro @scriptDir )

Nevertheless, I really wonder if there is no AutoIt - core support for doing a visual debugging ... i think in a "hooking" way.
or something... so the autoIt interpreter basically should support a stepping ( or trapping ) mode.

Well... this debugging itself is another problem...
I love your debugger, and it helped out me so much times the last 2 days I used it...
Maybe you can write to the AutoIt developers - and ask them if there's no Debugging exe or a remote debugger or a debug-script engine planned... they really need a JIT-Debugger =)
maybe your visual debugger project would become much smaller - if you just use such a debugger than building up a debugging script ( I would have no other idea instead - so you're the first programmer just doing it instad of just thinking about it ! <thumbsup> )

Ok .. anther (small) suggestion is to add something like a variable "watch" or a "filter" to the variable output.
If I look for a special variable in a very big variable-list, it's a bit heavy to find.
Something very nice is that you put a red color on manipulated variables - but there are some cases at a beginning state where a lot of "red" variables are there.

It's really fascinating you done that so far - I know autoIt for some years, now - but debugging was a real problem up to now.

Congrats, good luck - keep on the good job,
and regards,

fishy.

[thefoolonthehill]

Hey Steve,

it would be also a nice feature to debug included things like:

#include <xyz.au3>

_myXyzImplementedFunction( $this, $that )

the step into does not step into the xyz.au3's implementation of the function. It does a "step over".

maybe it's a true complex problem to solve - I can imagine this - because the current strategy is to put the script into
a debugger script ( wrapped for stepping )...

The program handles #include files and should automatically debug them, unless they are built in AutoIt ones. Try debugging the 'Test Script 9 - Include.au3' in the Test Scripts subfolder.

also there is a problem if you execute a debugger-script within the "Debug" Folder, then some files path's within the script you debug that are given relatively are not found anymore.

So when running a debugger script you need to put the script's working folder to the folder where the original script is located
( i think of the macro @scriptDir )

Don't mess with anything in the debug folder. It is hidden for that reason. The debug script is written such that it thinks that is in the parent folder. Running it manually, or debugging the debug file will just cause problems.

Nevertheless, I really wonder if there is no AutoIt - core support for doing a visual debugging ... i think in a "hooking" way.
or something... so the autoIt interpreter basically should support a stepping ( or trapping ) mode.

Well... this debugging itself is another problem...
I love your debugger, and it helped out me so much times the last 2 days I used it...
Maybe you can write to the AutoIt developers - and ask them if there's no Debugging exe or a remote debugger or a debug-script engine planned... they really need a JIT-Debugger =)
maybe your visual debugger project would become much smaller - if you just use such a debugger than building up a debugging script ( I would have no other idea instead - so you're the first programmer just doing it instad of just thinking about it ! <thumbsup> )

Glad the debugger has helped you out! If you, and anyone else that wants to debug, requested the AutoIt developers to add these features, there would be more chance of the adding it in.

Ok .. anther (small) suggestion is to add something like a variable "watch" or a "filter" to the variable output.
If I look for a special variable in a very big variable-list, it's a bit heavy to find.
Something very nice is that you put a red color on manipulated variables - but there are some cases at a beginning state where a lot of "red" variables are there.

Yes, they turn red when they change value, so sometimes, allot of variables change.
I will look at some filtering/selection of variables.

Thanks for the comments!

Steve

[fishy]

Hello,

Is it possible to add an mouse-over tooltip - so when the mouse-pointer is over a variable it shows its value in a tooltip ?

This would speed up the debugging session enormously.

More Improvements:

- Variables: Filter / Ignore ( maybe contextmenu )
- Scroll last changed variable into view
- "Watch" variable
- Context menu that allows to Copy a variable's value into the clipboard ( can also be done by double clicking the value or something)
- Split up of locals and globals ( maybe also a part or special window for all the standard autoit macros @xxx )
- Breakpoint list with all breakpoints. There you can enable/disable them and don't loose the breakpoint position when just disabling the breakpoint.
- Special "step into" command that allows to jump into an autoit include folder's implementation.
(mainly this may not be wanted, but for UDF development it might be very helpful)
- How to debug Array-Contents ? ( e.g.: _ArrayDisplay on doubleclicking an array variable )
- Shortcut key that executes an Explorer.exe on the File's directory to just open the folder of the file.
( I added this to the SciTE's Tool section and it's really usefull )

Please continue your fantastic work !

[thefoolonthehill]

Hello,

Is it possible to add an mouse-over tooltip - so when the mouse-pointer is over a variable it shows its value in a tooltip ?

This would speed up the debugging session enormously.

I will take a look at this. It would be useful.

More Improvements:

- Variables: Filter / Ignore ( maybe contextmenu )

Don't understand this. Variables can be watched through the context menu.

- Scroll last changed variable into view

Should be possible.

- "Watch" variable

Don't understand this. Variables can be watched at the moment.

- Context menu that allows to Copy a variable's value into the clipboard ( can also be done by double clicking the value or something)

Should be possible.

- Split up of locals and globals ( maybe also a part or special window for all the standard autoit macros @xxx )

Not possible because of the way the debug code is created and there being no way of determining if the variable is local or not.

- Breakpoint list with all breakpoints. There you can enable/disable them and don't loose the breakpoint position when just disabling the breakpoint.

Should be possible. Advanced breakpoints is on the future improvements list.

- Special "step into" command that allows to jump into an autoit include folder's implementation.

Have you looked at the 'debug files in the autoit folder ' checkbox in the options? When checked you can step into the built in AutoIt includes. Other wise they are stepped over.

(mainly this may not be wanted, but for UDF development it might be very helpful)
- How to debug Array-Contents ? ( e.g.: _ArrayDisplay on doubleclicking an array variable )

This is a bug introduced when changing the variable operation. You can get around it by manually adding a variable with the array value to be read (i.e. $MyArray[1] instead of $MyArray. I will look at fixing in the next release.

- Shortcut key that executes an Explorer.exe on the File's directory to just open the folder of the file.
( I added this to the SciTE's Tool section and it's really usefull )

Should be possible.

Please continue your fantastic work !

Thanks! Steve

[fishy]

- Variables: Filter / Ignore ( maybe contextmenu )
- "Watch" variable

Don't understand this. Variables can be watched through the context menu.

Ok. In the newer version is now a watch.

The "old" flat variable-view is removed ? I didn't found any window or switch for it.

I have a problem by adding variables "a posteriori". If I add a variable from some lines above the current execution line, the watch shows up "not declared". On a debug-step the watched variables should be updated ( all ). Maybe an "update" or "re-evaluate" button within the "Watch-toolbar" would do it. ( variable's contextmenu->re-evaluate could also be a solution for this )

Also some variables may contain some special chars, like \r \n \t \0 ... any idea to debug them in strings? Currently there are just boxes like: "line1[][]line2[][]line3". I could imagine something like: "line1\r\nline2\0\0line3".

- Split up of locals and globals ( maybe also a part or special window for all the standard autoit macros @xxx )

Not possible because of the way the debug code is created and there being no way of determining if the variable is local or not.

You "wrap" the original lines - so you have no interpretation possibility...? Don't you read out the original code line ?
If you want to add such a feature, I could also imagine using AutoIt's "IsDeclared". With this you get the result of -1 for locals and 1 for global defined variable.

[samshu]

Hi,
debugger is a great application!!!

But I need a little feature. Is it possible to save the complete trace expanded to a file? Or can I save the trace window with some expanded lines with markall, copy and paste to a text editor window? (ex: CTRL-A to mark, CTRL-C to copy, CTRL-V to paste). If the program work correct, the trace window is clean. Only on an error the trace is in the window.


Thanks for your great work!
Best regards
samshu

[thefoolonthehill]

Added to my to do list.

Steve