AutoHotkey Community

I suppose so, with EVENT_SYSTEM_SOUND (:0x1), at least if the sound is among the system ones.
However, I can't test it as all my frequently used apps don't make a sound.

Wouldn't be AHKs SoundBeep exactly such an event (for testing)?

What do you all think, should fast-mode be the default for RegisterCallback? Perhaps the answer depends on how often callbacks will be used for subclassing controls/windows and other situations that are triggered by incoming messages.

If revised the docs to read, "the fast mode inherits global settings from whichever thread happens to be running at the time the function is called. Furthermore, any changes the function makes to global settings (including ErrorLevel and the last-found window) will go into effect for the current thread. Consequently, the fast mode should be used only when it is known exactly which thread(s) the function will be called from."

I would advise that the safe, conservative behaviour (slow) be the default, the existing syntax also implies this.

Consider the following:

hook:=RegisterCallback("somefunction","Fast")
hHook1:= SetWinEventHook(0x8000, 0x800D, hook)

...

FileCopy x, y

if ErrorLevel
blah...

If the hook is triggered between the FileCopy, and if ErrorLevel lines (a possibility, which cannot be ignored), then ErrorLevel may be changed by the function, and weird logic errors will result...
Realistically, Fast mode can only be used if the callback is called within the context of a single dllcall/function/small block of code.
As some people will inevitably miss this subtle point when writing code, having a default option which produces unpredictable thread interruption issues in many cases, seems a bad idea.
These sorts of in-between-line thread collisions are the type that cause rare seemingly random crashes in many multithreaded programs...

This is unless callback functions are changed in such a way that they save and restore certain variables automatically (such as ErrorLevel), which seems more work than it is worth...

JGR

I agree with making the slow mode the default.

The beta version does not seem to support negative time values in SetTimer. Is it intentional?

It does.

(sorry, it was a negative timer typo in my script)

The release delay would be true only to that release versions (say from 1.0.46.15 to 1.0.47) where are many big changes which should definitely tested out, not only by the author. Thats the meaning of open source (at least to me).

Is it not safer to delay a critical release? That day when introduced RegEx, some problems could be catched earlier and not after public release.

No, I prefer to avoid beta releases. There are many advantages and disadvantages to it, but I think the good outweighs the harm. Also, whenever a release is considered high-risk for production environments, it is explicitly marked as such so that those who are concerned can wait a few weeks or months before adopting it.

Maybe it's the wrong decision, but it's worked pretty well so far. It also encourages a high level of quality assurance prior to each release.

Another successful test: High resolution timer II passed with flying colors. The callback mechanism seems to be rock solid!

I don't mind bugs in AutoHotkey. They are often minor, because Chris usually do lot of testing before a release. And Chris is very reactive on bug fixing.
Another way of looking at it is to say that AHK is always in beta state, like Google softwares: rock solid, but hey!

_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

What about non-standard data sizes, could Type accept a number for that?

_________________
GitHub • Scripts • IronAHK • Contact by email not private message.

I was wondering that too.

I think it would be too rarely used to have built into NumGet/NumPut. Currently, the only sizes supported are 1, 2, 4, and 8; but those seem to be enough to support 99.99% of cases.

I doubt it would be hard to implement or bloat the code. So why the heck not implement it? Well i just guess you don't like the idea and that's why. See for me personally its easier to specify the size of a type then to remember what the Type was called that's is 8 or 4 or 2 bytes long plus its less to type. Further what if you got a buffer(from a file with an exotic format) and need to change an arbitrary block of it by replacing it with another buffer(a struct consisting of a long and a byte). This would require the Number param of NumSet() to behave similar to the VarOrAddress param (blank varname = copy a number, expression = copy buffer pointed by). But this shouldn't be a big problem to code.