SciTE4AutoHotkey v3.0.06.01 [Updated October 12 2014]

[kunkel321]

Yes, both of those!
------------
Hooray! It works! Thanks for hanging in there guys (especially Lexikos).
As it turns out, I had previously tried the portable version of SciTE, but quickly gave that up because it wasn't able to run the scripts.
I guess it *was* a permissions issue with the SciTE subfolder (?) I'm an administrator of the machine, and UAC is at its lowest setting... Still though, setting my user profile as the owner of the folder did seem to make a difference. Also, the copy of AutoHotkey.exe that needed to be at the same dir level as SciTE/ and ReadMe.txt wasn't there. Those two changes made the thing work. I had to tinker a bit with the registry to get SciTE to open upon double-clicking an ahk file... As you might guess, I set "C:\Program Files\AutoHotkey\SciTE4AHK300601_Portable\SciTE\SciTE.exe" (with quotes, but without "%1") as the Edit/Command and also as the Open/Command. This has the side effect that right-clicking an ahk file and choosing "Run" will open it in SciTE, rather than running the script... But that's okay! My scripts that get run on a regular basis usually get compiled to exes anyway. So as far as I'm concerned--I'm golden! As a side note, I went and saw Star Wars in 3D on the bog screen. It was good. Way better than the prequels. Thanks again.

EDIT: Upon my return, let me first belay your concerns: I haven't come back to change my assessment of the new Star Wars. It was still awesome.
However my registry hack might've been off a bit. I had removed the "%1" because every time SciTE opened (upon d-clicking an ahk file), the Open dialog box would also pop up. Removing %1 seemed to prevent that, but now the selected (i.e. clicked upon) ahk file is not sent to SciTE. It just opens whatever was last edited. Okay... So you guys knew that was going to happen even before you got to this "edit" part. LOL.

[Joe Glines]

I ran into the Registry issue so many times I wrote a script to update it. I never got around to making it interactive though (where you could navigate to find SciTE directory(or whatever editor of choice) thus I never shared it. Perhaps I should...

[kunkel321]

Only post it if it's safe for nOObs like me. Or maybe post and put a warning that it changes your registry. WHat does the ending registry key have on your system? Does it have the "%1" ? I suppose it does. I think that's actually somewhat standard for passing arguments via command line....

[Joe Glines]

This is what is in my registry:
"B:\Progs\AutoHotkey_L\Scite\SciTE.exe" "%1"

BTW- if you didn't know it, you can add a bookmark to specific keys. Makes it very convenient to get back to your frequently visited places

[kunkel321]

For the one just create a hotkey that exits the app. for instance

Code: Select all

esc::ExitApp ;escape key exits applications

For that matter, I like to have reload as a hotkey as well:

Code: Select all

RAlt::Reload ;Right alt will reload running script

Joe, did you mean that you have a separate script running that includes these and applies them to the script you're testing (I'm not even sure that would work), or do you mean that you routinely include these as part of the script that you are working on? If the latter, do you have it as part of your default script header?? I know the hotkeys would mess up the "auto-execute" section. But maybe it would be okay to have it set up like
;===========================
#NoEnv ; For security
#SingleInstance force
esc::ExitApp
;===========================

Thoughts?

[Joe Glines]

They are put in the script you are working on. One more convenient one is to put one for editing. If the below is in the script (and the script is running) hitting Control Alt E will open that script in your default editor


^!e:: Edit ; Control Alt E= edit this script

[hobboy]

I'm still quite new to ahk but today I've started running into this issue/error when debugging some scripts:

I can reproduce this by using the script below, setting a breakpoint at the last FileAppend command, clicking F7 to enter debugging mode then F5 to run to the breakpoint (error occurs before hitting breakpoint), and F5 to finish script if it didn't error. The error doesn't occur every time but if I do this process a number of times it seems to occur. I haven't had access to another computer to test this yet, but I've seen this kind of error message a number of times on this forum and the old one without solutions.

Code: Select all

#NoEnv
#SingleInstance

FileAppend, asdf,*
FileAppend, asdf,*
FileAppend, asdf,*

I'm running Win 7 Pro x64 SP1 as a non-admin, with the latest version of ahk (x64 1.1.22.09 portable) and an up to date SciTE4AutoHotkey v3.0.06.01 Portable Edition. To my untrained eyes it looks like Stream Viewer window doesn't seem to be closing properly (or the program thinks it has closed when it hasn't), any idea what might be going wrong?

[kunkel321]

I had the same error with a gui variable I was using. It ended up being because the gui was getting "recreated" without getting "destroyed" first. Putting Gui, Destroy at the top of the gui stuff fixed it... I'm also new to ahk though. So I'm not sure if that will work for you or not.

[TAC109]

I'm still quite new to ahk but today I've started running into this issue/error when debugging some scripts:
....

This is a long standing problem when debugging using this editor. If you move this window to one side, you will usually see that there is a 'warn' window behind which shows the actual bug in your code.

[hobboy]

This is a long standing problem when debugging using this editor. If you move this window to one side, you will usually see that there is a 'warn' window behind which shows the actual bug in your code.

Although with the simple example there doesn't appear to be an problem (even with warn on), it certainly made me look more closely at my script and find some issues! Do you know of a work around? I only use these messages for debugging, but I can reduce their frequency. Possibly increasing the time between the FileAppend calls might work, I'll give that a go.

[lexikos]

If you move this window to one side, you will usually see that there is a 'warn' window behind which shows the actual bug in your code.

It is not caused (solely) by a bug in the users code. It is a bug in the debugger, hence the error message coming from SciTEDebug.ahk. I have received the same error sometimes when using a hotkey to start debugging and immediately "step in". I have not seen the problem recur since adding delays to my hotkey.

Warnings don't necessarily indicate a bug in your code, otherwise they would be treated as errors. Anyway, nothing your script does should cause the debugger to throw up error messages - this is a debugger after all.

[TAC109]

Although with the simple example there doesn't appear to be an problem (even with warn on), it certainly made me look more closely at my script and find some issues! Do you know of a work around? I only use these messages for debugging, but I can reduce their frequency. Possibly increasing the time between the FileAppend calls might work, I'll give that a go.

Yes, the problem is related to the stream viewer window created by SciTE. Your file append code is writing to stdout which is being shown in the stream viewer window. SciTE also shows #Warn messages in a stream viewer window, which is where I have seen this problem.

[offpath]

Code: Select all

Is there a way to force SCite4 Version 3.0.06.01 to follow a definition of F12 in the ahk file loaded at boot? 
SCite4  doesn't do so automatically, currently, although you can manually force SCite4 to do so, once it's running.

My load-at-boot ahk file contains the definition
#IfWinActive, ahk_class SciTEWindow
....
; to SAVE AND reload
f12::
{
SendInput {esc}!Fs
;MsgBox ,you lose
sleep 300
Reload
return
}
;sciTE
#IfWinActive

On my Win 7 Pro x64 computer, when F12 is pressed for the first time in a newly opened SCite4 Version 3.0.06.01 window, SciTE4 does
>>> NOT follow the F12 definition in the load-at-boot ahk file (although all other programs do follow all their definitions from this boot ahk file).

Instead, under SCite4 Version 3.0.06.01, F12 pulls up Tillagoto -- as though the ahk file did not exist. 
The F12 definition is the ONLY one SCite4 Version 3.0.06.01 does not follow (I use a bunch of others). If however, you manually RELOAD the (unchanged) boot ahk script, while SCite4 Version 3.0.06.01 is running, SCite4 Version 3.0.06.01 suddenly DOES follow the definition of F12 as defined in the boot script. 

On a Win 7 Home computer SciTE4AutoHotkey 64-bit Edition Version 3.0 DOES ALWAYS follow the boot ahk definition of F12.

[lexikos]

You can disable TillaGoto. It apparently overrides that hotkey (if it has loaded more recently than your script).

[kunkel321]

Hi Guys, I'm back again, but with a different question a feature request:
I've identified a few pretty cool scripts that I can use in the process I writing my own scripts. I was pleased to see that SciTE already incorporates several of these, such as scriptlets, the commenter tool thing, and the dialog box maker. A couple of others that I like are Robert Ryan's RegEx Tester, and this TidyScript one. I wasn't able to get the TidyScript that the original author made, because so many of the old link are broken I was able to find code here https://autohotkey.com/board/topic/4151 ... nt%C2%B4d/ though.

Anyhow, I not going to attempt to hack these into my SciTE, because I don't want to break it again. Maybe they could be added to the toolbar in some future version though (?) Just an idea... Thanks for considering this

[lexikos]

@kunkel321: Just right click on the AutoHotkey portion of the toolbar, click "Edit User toolbar properties" and read the instructions in the file.

[kunkel321]

Hey it worked!

Code: Select all

; Place here your tools
=RegEx Tester|%LOCALAHK% tools\RegExTester.ahk ||%ICONRES%,13

Thanks Lexikos!

[kunkel321]

Hey Lexikos (or other),
Is it possible to change those toolbar icons?
I tried changing the icon number (like %ICONRES%,13 as above). That works, but things like:
=Scriptlet: My Header|%LOCALAHK% tools\SUtility.ahk /insert "My Header"||%LOCALAHK% tools\106-ntshrui.ico
or
=Scriptlet: My Header|%LOCALAHK% tools\SUtility.ahk /insert "My Header"||%LOCALAHK% tools\SHELL32b.icl, 106
don't work (even though the appropriate resource files were put in the tools folder).

Any ideas?

[lexikos]

I'm still quite new to ahk but today I've started running into this issue/error when debugging some scripts:

This is a long standing problem when debugging using this editor. If you move this window to one side, you will usually see that there is a 'warn' window behind which shows the actual bug in your code.

I have some clues as to the cause of this error.

The following script shows the error multiple times, and most of the output is lost:

Code: Select all

Loop 20
	OutputDebug The quick brown fox jumps over the lazy dog #%A_Index%`n
MsgBox

Shorter output gives a lower chance of the error occurring.

The following script does not show the error:

Code: Select all

OutputDebug Init!
Sleep 100
Loop 20
	OutputDebug The quick brown fox jumps over the lazy dog #%A_Index%`n
MsgBox

However, the output usually has one item out of order; for instance, #10 might display after #20, with the rest in the proper order. Again, shorter output gives a lower chance of the problem occurring.

So I would say that the message notifying SciTEDebug.ahk that network data is available is being received and processed recursively; i.e. it hasn't finished processing the previous network message, and is interrupted to process the next one. I suppose that a solution might be to perform only critical processing in the thread which receives the network message, and do not allow that thread to be interrupted. For instance, when a network message is identified as a stream packet, immediately put it in a queue, set a timer and return. Perform all the GUI work in the timer thread.

Of course, I could be wrong. I haven't debugged the debugger.

[MilesAhead]

I am running Windows 8.0 x64. I notice that ahk scripts dropped on the open Scite4ahk(latest version) do not open in the editor. I get the plus sign when dragging onto the main toolbar. But when I release the mouse the plus sign disappears but nothing happens.

Seems I get this now and then but I forgot the work-around. I tried a Take Ownership on the entire Autohotkey folder but that did not help. I just tried running Scite As Administrator. Same thing. The plus sign disappears and no action is taken.

Edit: Also I see no way to set defaults for the program. If I do an Open With and drill down to the scite exe in the AutoHotkey folder all the .ahk files have the AutoIt3 icon. I have Sicte4AutoIt3 also installed. I seem to get these clashes when they are both based on the same Scite release. Once the version numbers of the underlying scites are different they seem to act normally again.