AutoHotkey_L v1.1.02.03
#1
Posted 06 August 2011 - 12:46 PM
Added TV_SetImageList(), for flexibility and consistency with LV_SetImageList().
Characters which require non-standard shift states 16 and 32 now use a fallback method instead of producing the wrong keystrokes. Specifically, the Neo2 keyboard layout should now work correctly. See this post for more details.
Handling of dead keys has been revised to solve problems which occur when multiple scripts with hotstrings are active. Although I have tested thoroughly, I don't ordinarily use dead keys, so I may have missed something. If you use dead keys and hotstrings or the Input command, please test your scripts before and after updating.
1.1.02.01 - August 13, 2011
Changed A_PriorKey to exclude key-up events.
Fixed process name/path retrieval in certain cases, including:
[*:bgvgyrzq]Retrieving name/path of a 64-bit process from a 32-bit script.
[*:bgvgyrzq]Retrieving name/path of an elevated process from a non-elevated process (UAC).1.1.02.02 - August 20, 2011
Fixed: Variable capacity was capped at 2GB on x64 builds.
Fixed: Last Found Window not set by #if WinExist(T).
1.1.02.03 - August 21, 2011
Fixed (Debugger): numchildren attribute did not include Object.Base.
(This caused problems in Notepad++ and XDebugClient in certain cases.)
Downloads (etc.)
#2
Posted 06 August 2011 - 01:38 PM
#3
Posted 06 August 2011 - 02:49 PM
EDIT: It appears that the new installer, even though it installs all the SC binaries, it doesn't install the new version of Ahk2Exe (if you planned to include it in this release, that is). The updater script, on top of that, doesn't install the additional SC binaries.
EDIT2: AutoHotkey_L_Install.exe still pulls v1.1.01 :\ Perhaps it's just the cache anyway...
#4
Posted 07 August 2011 - 12:39 AM
I did intend to include your Ahk2Exe script, and I actually copied it to the installer include directory. Then I run my release script, which automatically rebuilt Ahk2Exe.vcproj and "updated" it for me.
If I look in my Temporary Internet Files folder, I see AutoHotkey110200.zip, associated with http://.../v/AutoHotkey110200.zip. This file typically won't change, so it doesn't matter much if it's cached. However, my experimentation with DeleteUrlCacheEntry indicated that there is a separate cache entry for http://.../AutoHotkey_Lw.zip. I suppose this means the redirect is cached. Since the first call to DeleteUrlCacheEntry succeeds and subsequent calls fail, I presume it successfully removes the cache entry, which should help.
I will update the update script soon.
EDIT: I've been testing with a frequently changing redirect (via .htaccess) and a bunch of timestamp files.
[*:26a35vcl]With the function as it was, I pretty much always get the old/wrong file.
[*:26a35vcl]With the URLDownloadToFile command, I always get the right file and nothing gets written to the cache.
[*:26a35vcl]With DeleteUrlCacheEntry, the updated redirect is seen but the target file is still pulled from cache. Both the redirect and target file are written to the cache.
[*:26a35vcl]With URLDownloadToCacheFile, everything is downloaded fresh, but the redirect and target file are still written to the cache. This seems to be the case even if I use FileMove vs FileCopy.EDIT2: Using FileMove instead of FileCopy seems to be a bad idea; sometimes it fails as the file is still in use.
EDIT3: I've updated the updater to work around the cache problems and also update the additional bin files used by the new Ahk2Exe. Running the old update script should be sufficient to let it auto-update. I've also updated my release script to pull the latest Ahk2Exe source from github, run it over itself with the the latest Unicode 32-bit bin, then compress and upload it. All three bin files are now included in Ahk2Exe_L.zip instead of the other three zips (a/w/w64).
#5
Posted 07 August 2011 - 03:01 PM
PS: Wouldn't it be a good idea to have a Release branch in the Ahk2Exe repo? I might be in the middle of implementing something when you decide to release a new AutoHotkey_L version.
EDIT: I've just created it.
#6
Posted 07 August 2011 - 09:43 PM
#7
Posted 08 August 2011 - 09:43 PM
#8
Posted 08 August 2011 - 11:21 PM
#9
Posted 09 August 2011 - 04:14 AM
#include same ahk file multiple times, the source ahk could run properly, but not the compiled exe file... there will be error
#11
Posted 09 August 2011 - 09:05 AM
#12
Posted 09 August 2011 - 12:54 PM
#13
Posted 09 August 2011 - 05:50 PM
class Car
{
var Data
DoSomething(){
MsgBox % "I'm a Car and the data is: " this.Data
}
__new(dat){
this.Data := dat
}
}
****\Desktop\EventHandler.ahk (6) : ==> Expected assignment or class/method definition.
Specifically: var Data
:?:
The new "static" descriptor seems to work.
#14
Posted 09 August 2011 - 05:53 PM
#15
Posted 09 August 2011 - 05:56 PM
var is now static
Huh?
Which means that var is now for Instance Fields (which is not implemented yet), and static for Static Fields.Use of the var keyword in class definitions to declare static class variables should be avoided, as a future version (probably the next release) will repurpose it for declaring instance variables. There are some cases where behaviour won't be adversely affected; in other cases, scripts should be updated to use the static keyword.
:?:
Can't see any announcement who points out that var is obsolete now :?
Edit:
I've decided to remove the "var" keyword entirely in the next release. Instance variables will be declared/initialized by simply writing Name := Expression in the class definition, outside any method definitions. However, note that Name is the only context in which you will be able to refer to an instance variable without specifying the object (like this.Name). Expression can refer to this, but any other variable reference will be global.
Well then. Why is this breaking change info not in the change log itself?




