AutoHotkey Community

Thanks for the update

Thx for static update. Its finally like it should be.

_________________

Awesome updates!

So, I can have N autorun sections:


Perhaps this could be added as extra keyword, for instance "autorun". This way the purpose is much more clear.

_________________

Wondering why the following two ways of setting value do not work the same?



This was a bit of a "trap" for me because you can get the value using the "dot syntax" but not set it. The later method apparently works because it creates the "sub-objects" as necessary while the first one does not. Am i wrong to assume that it would be more "newbie" friendly (like me) for the first method to work equal to the second?

If i'm sounding confused, it is because i am.

The function isn't running when the static initializer is evaluated. Static initializers are simply prepended to the auto-execute section (after variable references are resolved).
Auto-execution isn't the main reason for static initializers, but since it works, I'd rather not add any new syntax.

No.
I don't know what you call a "standard" script. For AHKControl, I see about 100KB higher Working Set size and roughly the same Private Working Set. I couldn't test my other "resident" scripts since they rely on AutoHotkey_L features. For a mostly empty script #including CLR.ahk and COM.ahk, the increase is 1MB / 600KB on the Unicode build and 300KB / 300KB on the ANSI build. Strings in the Unicode build necessarily take up twice as much memory; that's the cost of Unicode support. Also, it's my understanding that the Working Set is shared with other processes.

Note that whichever build you use, memory usage is slightly lower if you decompress AutoHotkey.exe (upx.exe -d AutoHotkey.exe), except for the x64 build, which can't be (easily) decompressed.
AutoHotkey_L is still mostly AutoHotkey, so there isn't much room for improvement. If I see any opportunities, I'll take them (within reason).

Maybe, but it's not feasible. Would it be more "newbie" friendly for neither one to do anything automatic? My reasoning was that x[y,z] looks like multi-dimensional array syntax, so should act like it. See Arrays of Arrays.

1.



2.
Any compiled script (from the last 3 versions): TR/Dropper.Gen
(I know this is the AntiVir problem, but even so...

OOPS!!
The correct one

Thank you !

Being automatic seems better as it is more obvious i think.

Is there other language(s) that have similar implementation of objects as you have done for AHK_L? If this is a dumb question, don't hesitate to say so.

Thanks!

AHK_L object model is inspired by Lua programming language (see tables and metatables). AHK_L Get is equivalent to Lua's index, Set equals to newindex and Call is in Lua named the same. AHK_L adopted only those basic metatable operators while Lua has many of them, for instance math operators that give object meaning in usual mathematical context.

I already proposed that AHKL should follow Lua completely in this manner, however, Lexikos doesn't seem interested for now. Altho I don't agree I can understand his choice due to the big difference between those langugages - Lua is general purpose scripting language while AHKL is domain specific one and its accent is not on the language sophistication but on automation and easy to use features. Also, AHKL must maintain AHK legacy for script compatibility and vanilla AHK is pretty much one of the worst languages around.

_________________

What do you expect me to do about it?

To let me hope that maybe that wouldn't be the case in a futur version of AutoHotkey_L (like before the last three versions); otherwise it doesn't make much sense for me to only script for myself!

File Object doesn't provide an immediate interface for inserting/deleting text in a file, so I did the following:



It works but the fact that File.Seek(540) must be used twice make me doubt this is optimal (?)