Jump to content

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

SciTE4AutoHotkey v3.0.04 [Updated Aug 14 2013]


  • This topic is locked This topic is locked
1137 replies to this topic

Poll: Looking good? (245 member(s) have cast votes)

Looking good?

  1. Voted Yes (379 votes [85.94%])

    Percentage of vote: 85.94%

  2. No (15 votes [3.40%])

    Percentage of vote: 3.40%

  3. File not found (47 votes [10.66%])

    Percentage of vote: 10.66%

Vote
fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009
I've gotten around to testing it, and I must say, nice job!

A few suggestions:

-Implement some sort of project file, which stores all included files and the main file, which is to be launched when a file included in the active project is currently open.

-It would be nice if it was possible to set breakpoints during editing, before clicking on debug button. Also removing them while editing would be good. Not sure if this is possible.

-Tooltips for variable contents in debugging. A feature similar to visual studio would be nice.

-Support for AHK_L objects, and binary view of variable contents would also help debugging.

-Option to remove the dialog asking if you want to list variables on larger scripts with many variables. I have a few hundred variables, and it lists quite fast for me, but the question on each step is really annoying.

-Go to function definition feature would be nice :). Probably in combination with project management.

-End script button. I've had to use task manager a few times during debugging, because of a breakpoint that would trigger again and again, so I wasn't able to get out of the script.

I know that these are a lot of points, but they would really increase the usability!

  • Guests
  • Last active:
  • Joined: --
KEYLOGGER DETECTED IN Kaspersky !!

after i installed ur software,
my Kaspersky says this

30-Jun-10 5:39:39 PM Detected: PDM.Keylogger kernel mode memory patch AutoHotkey_L



fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007
@Guest: The same old false positive due to UPX story again (toolbar/AutoHotkey/SciTE are UPXed to save space).

@fragman:

-Implement some sort of project file, which stores all included files and the main file, which is to be launched when a file included in the active project is currently open.

That's something I'm considering (it's possible).

-It would be nice if it was possible to set breakpoints during editing, before clicking on debug button. Also removing them while editing would be good. Not sure if this is possible.

I've blocked it, but I should check if AutoHotkey_L supports it.

-Tooltips for variable contents in debugging. A feature similar to visual studio would be nice.

Will be done.

-Support for AHK_L objects, and binary view of variable contents would also help debugging.

AutoHotkey_L doesn't support it.

-Option to remove the dialog asking if you want to list variables on larger scripts with many variables. I have a few hundred variables, and it lists quite fast for me, but the question on each step is really annoying.

Maybe.

-Go to function definition feature would be nice :). Probably in combination with project management.

Already there thanks to TillaGoto :D
Middle-click a function/label to go to the definition.

-End script button. I've had to use task manager a few times during debugging, because of a breakpoint that would trigger again and again, so I wasn't able to get out of the script.

A force option could be added.

SoLong&Thx4AllTheFish
  • Members
  • 4999 posts
  • Last active:
  • Joined: 27 May 2007

toolbar/AutoHotkey/SciTE are UPXed to save space

Just curious: how many bytes do you save and WHY :?: :wink:

fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007

toolbar/AutoHotkey/SciTE are UPXed to save space

Just curious: how many bytes do you save and WHY :?: :wink:

A lot. From ~700KB to 200KB per UPXed file.

fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009
Thanks for your reply.

Too bad AHK_L doesn't support inspecting objects. I don't know anything about the internal workings of the debugger, but seeing as there is support for enumerating object contents, I think it could be possible to implement it. Lexikos?

I tried using Middle mouse button, but not with much success. I believe it only works in the current file, which makes it somewhat useless for me. This is something that could see improvements with a project system.

fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009
One more thing I just thought of, Notepad++ allows to specify a help file that can be used to look up commands. So you just select a command/function/variable, press CTRL+F1, and it will open the help file with the command. Useful for quickly getting info :)

I also use a plugin in Notepad++ which allows to select a tab by typing its filename. This is also very useful if you have 3 rows of tabs open ;)

fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007
Place the caret in a command or function then press F1 to bring up the AutoHotkey help.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

I don't know anything about the internal workings of the debugger, but seeing as there is support for enumerating object contents, I think it could be possible to implement it.

SciTE4AutoHotkey can only do what the AutoHotkey_L DBGP engine allows it to do. At least two parts are required:
[*:k7y4obru]Debugger engine support: property_get needs to enumerate the object's fields (manually, see below) and output XML in the correct format. The DBGP documentation isn't particularly clear, but values within the object should probably be returned as property elements nested in the main property element which represents the variable being queried.
[*:k7y4obru]Client support/user interface: SciTE4AutoHotkey needs to interpret the nested property elements correctly and display them appropriately to the user.Enumerators probably shouldn't be used since they may cause script to execute. The debugger engine code may access an object's fields directly, so it's not much of an issue.

There may be additional complications. For instance, property_get/set/value should probably be able to query/set a field within an object, where the "property long name" contains something like obj.x.y. When an object refers to another object, should the contents of the other object be returned as well (up to the maximum nesting depth)? If an object is used as a key, how should it appear in text/XML form? I'm sure more questions like this will crop up once development actually begins.

flyingDman
  • Spam Officer
  • 2186 posts
  • Last active: Nov 07 2015 08:15 AM
  • Joined: 27 Feb 2009
Impressive! I am using Notepad++ now and one of my favorites is the Ctrl- Shft up/down to move one or more lines. Would love to see it here !

Marine Corps Gen. Joseph Dunford told senators at his Joint Chiefs of Staff confirmation hearing : “If you want to talk about a nation that could pose an existential threat to the United States, I'd have to point to Russia. And if you look at their behavior, it's nothing short of alarming.”


Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
I missed some of the earlier posts...

-It would be nice if it was possible to set breakpoints during editing, before clicking on debug button. Also removing them while editing would be good. Not sure if this is possible.

I've blocked it, but I should check if AutoHotkey_L supports it.

AutoHotkey_L doesn't need to explicitly support maintaining breakpoints between debugging sessions. You can easily do that:
[*:2acov7aw]Allow breakpoint markers to be added/removed while the debugger isn't running/connected.
[*:2acov7aw]Don't remove breakpoint markers when the debugger stops.
[*:2acov7aw]When debugging begins, automatically call breakpoint_set for each breakpoint marker.I think that's more or less what XDebugClient does.

-Option to remove the dialog asking if you want to list variables

I agree that the dialog is very annoying. 100 is an unreasonably low limit.

fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007

[*:366sa58l]Allow breakpoint markers to be added/removed while the debugger isn't running/connected.
[*:366sa58l]Don't remove breakpoint markers when the debugger stops.
[*:366sa58l]When debugging begins, automatically call breakpoint_set for each breakpoint marker.

That's the problem. SciTEDebug.ahk is only running when there is a debugging session. Allowing breakpoints when not debugging would require a complete rewrite of the system.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
You can't get SciTE to simply toggle a marker in the breakpoint margin without SciTEDebug.ahk running? That's all it should take...

fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007
Yeah, and lots of processing by the Lua script to store/retrieve breakpoints in a "configuration" file, etc etc. Additionally SciTE adds its own markers when you double-click on error messages to complicate the situation.

If you're talking about not preserving the breakpoints when closing SciTE then matters are simplified a bit. There are still issues like breakpoint line correcting that cannot be handled by offline breakpoint placement (put a breakpoint at an empty line and AHK_L will automatically reposition it to the next non-empty executable line, adding new lines between breakpoints to have them misplaced, etc). What you say basically requires a /Debug instance of the script always running.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

Yeah, and lots of processing by the Lua script to store/retrieve breakpoints in a "configuration" file, etc etc.
...
If you're talking about not preserving the breakpoints when closing SciTE then matters are simplified a bit.

It should be clear from the rather specific and simple list in my previous post that I was only asking for breakpoints to remain between stopping and restarting the script, not restarting SciTE itself. Basically, the level of breakpoint persistence XDebugClient has is sufficient.

However, if you were to persist breakpoints, I would expect them to be saved in the session file along with bookmarks and folds (if "session.bookmarks" and "session.folds" are enabled).

Additionally SciTE adds its own markers when you double-click on error messages to complicate the situation.

Those markers no doubt have a different marker number, so I don't see how they'd cause any complication.

There are still issues like breakpoint line correcting that cannot be handled by offline breakpoint placement

So handle it when the debugger launches, as though each breakpoint was just added by the user. Similarly, Visual Studio doesn't correct breakpoint placement until you launch the debugger. Actually, it seems to put them back where they started when the debugger stops, but I think that isn't necessary.

adding new lines between breakpoints to have them misplaced

It shouldn't be too difficult to adjust the markers when a line is inserted/removed. Honestly, I expected Scintilla would do this automatically (but I see it doesn't).


Having breakpoints disappear when the script terminates really hurts usability.