AutoHotkey Community

FYI, my latest release includes some of the beta changes, but not the latest lot.

bug... with the latest exe and bin, ahk2exe /nodecompile not working any more, it would create invalid exe file.

OK, I downloaded it. Thanks.

Thanks; I've fixed that. You can re-download it from the same link: www.autohotkey.com/misc/AutoHotkey-Pre- ... N-new4.zip (240 KB)

Now in beta4 appears 2 green lines (another one at the top)

I still see one green line at the top and one in the middle. This area has not changed since the previous beta, so the explanation and workarounds I mentioned still apply.

I'm not sure what the workarounds were; maybe they're the same as the following:

Add the following red line beneath the SetFormat line:This is caused by the converse of the following change: When SetFormat, Integer, Hex is in effect, assigning a literal decimal integer to a variable also converts it to hex. Usually this is only a display issue.

I've revised it to read: When SetFormat Integer is in effect, assigning a literal integer to a variable (or passing a literal integer to a function) immediately converts the integer to the current format (decimal or hex). Usually this is only a display issue.

Hi Chris,

I am unsure where to post it. But since this is closely linke dto this beta, I thought it would be ok to post it here.

In the Manual about the SetFormat it is said:It took me a while to understand what was meant by this sentence. Until I realized that otherwise the numbers would be cached as strings (Am I right, or totally mistaken?). If I'm right, I would like to suggest to change the documentation to give a more direct hint.

Thanks; I've clarified it to read:
The fast mode preserves the ability of variables to cache integers and floating point numbers, which can substantially accelerate numerically-intensive operations. (By contrast, the slow mode forces all numeric results to be immediately converted and stored as strings.)

Since backward compatibility is important, the following behaviors have been changed back to the way they were in non-beta versions:
Since there is little performance impact to keep this backward compatibility, it seemed best to do so. It also makes hexadecimal behavior more consistent

Here is the new AutoHotkey.exe. If you wish, you can rename or move your original AutoHotkey.exe and put this one in its place: www.autohotkey.com/misc/AutoHotkey-Pre-1.0.48-new4.exe (238 KB)

For those who would like to compile scripts with this release, unzip the following file in your \Program Files\AutoHotkey\Compiler folder: www.autohotkey.com/misc/AutoHotkey-Pre- ... N-new4.zip (240 KB)

I am not sure if it is new to the AHK beta. The following little script keeps on increasing its memory use, until it eventually crashes.The dll call sends messages to the joystick driver about calibration data changes. After that we acquire the name of the joystick driver (checked if it becomes empty in the full script). In the timer subroutine none of the commands alone causes memory leak.

I can see that the memory does increase gradually. When run overnight with the older, non-beta version of AutoHotkey, Task Manager's "mem usage" increased from 3976 to 4320 (I also changed the SetTimer line to use a period of 1 instead of unspecified).

When run in the compiler's debugger, the call stack doesn't appear to be growing larger; so it doesn't appear to be a problem such as unwanted recursion.

Also, the script's VM size doesn't increase, which I think means that the program is not allocating additional memory from the heap as time goes on. This is further supported by the fact that in debug mode, breakpoints on the most likely memory allocations are never reached.

Also, it doesn't appear to be an issue with DllCall's LoadLibrary() because that call is never reached (WinMM.dll is already loaded).

I also tested it with a loop containing "Sleep 1" instead of SetTimer, and the same thing seems to happen. Strangely, removing the Sleep and allowing it to run very fast doesn't seem to increase the rate of memory growth.

The fact that "mem usage" increases but not "VM size", may imply that some kind of shared OS resource is increasing its memory utilization. This is further supported by the fact that Process Explorer reports that the working set "private" is not increasing, but the working set "shareable" and "shared" seem to be increasing. Therefore it's tempting to write this off as some kind of OS bug. However I won't rule out the possibility that it's a bug in the program, perhaps something involving GetKeyState() [though I did review that code and there don't seem to be any untested memory allocations in it].

I'm near the end of what my debugging skills can do; I'm not sure what more should be checked.

Comments or further testing are welcome from anyone.

Sysinternal just released a new memory tool vmmap - maybe it can shed light on the incresed memory usage.

_________________
RegEx Powered Dynamic Hotstrings
COM
AutoHotkey 2

Some more info about the joystick monitor's memory use:
- If there is no joystick connected (unplugged), the memory increase stops. Reconnecting the joystick restarts the memory increase.
- In my Vista PC, SetTimer...,1 increased the memory use to 200MB in just 10 minutes. At 330MB the PC slows down, and some disk activity occurs (maybe swapping something to disk?).
- Fixing this issue was important, because joystick using applications need to know if a joystick gets unplugged. GetKeyState alone does not help, because it returns the last valid data, long after the joystick was removed, so the application appears to be frozen. If there is a bug in winmm.dll\joyConfigChanged, another method would be badly needed. Any idea where to look?

Thanks. I tried it and I think that's a good way to proceed. However, since the issue is not clearly defined on my system (I don't have a joystick hooked up), it might be best if someone with a joystick tries it.

VMMap requires no installation. Just unzip it, run the file, and select a process: http://download.sysinternals.com/files/vmmap.zip

Hopefully it will reveal a more precise location of the memory usage.

Offhand I don't; it's been a long time since I reviewed the Windows joystick functions.