AutoHotkey Community

Great release, a for loop was needed to improve readability of enumerations

PD: Dev S4AHK already supports the new constructs.

EDIT: This code gives truncation warnings when compiling the x64 build, the highlighted text is a fix:

or even:


EDIT2: This too:

_________________
fincs
Highly recommended: AutoHotkey_L (see why) (all my code snippets require it)
Formal request to polyethene - I support the unity of the AutoHotkey community
Get SciTE4AutoHotkey v3.0.00 (Release Candidate)
[My project list]

Does L have auto-scrolling menus by any chance?

The menu command produces arrows at the top and bottom of the menu when it gets long. But it doesn't auto-scroll when the mouse is over the end sections or if the mouse left click is held down when over either arrow.

If L doesn't have this feature, what does the author think about adding it?




P.S.
Any chance the front page of this thread be kept up to date as most of the links there don't seem to work.

_________________
Stuart Halliday

Fantastic additions of loop functionality, Lex. Your work is sincerely appreciated.

_________________

Try Quick Search for Autohotkey or see the tutorial for newbies.

Thanks for pointing them out.
The author thinks this is not a Wish List thread. It can be done with MI_GetMenuHandle() and SetMenuInfo in any (32-bit?) build of AHK.
Not a chance in the world. Or maybe. Incidentally, eleven of the thirteen links were already working.

Sooooo gooood release.

Here is the usual for loop:



That is one of those things I wished I had around many times....

_________________

Note the list values don't need to be pre-calculated (though in this simple case pre-calculating might perform better):

+1

@majkinetor & Lexikos : Thank you guys for your examples!

Oh I don't know. Looks like the only place discussing L.

And those two links don't mean anything to me.
How does one use SetMenuInfo in AHK then?




I must have been unlucky then to have clicked on the 2 that didn't work.
Just seemed broken to me at first glance.

_________________
Stuart Halliday

One searches the forums, then one posts in Ask for Help if one can't figure it out for oneself.

Wow - amazing release! I'm beginning to run out of things I wish were implemented into AHK


Though it doesn't affect me much personally, I believe a simple array object would be more noobie-friendly. For instance, it could be restricted to positive, integer keys. Also, with the new For-loop, wouldn't it be more intuative for the user to write:... rather than: ... , especially since with a simple array, the index would already be stored in A_Index?

EDIT - I should prolly retract the previous statement since the following could still be pretty intuitive:

_________________

Recommended: AutoHotkey_L
Basic Webpage Controls

I don't see that being of much benefit to anyone.
That behaviour can be applied to temp01's Array library by adding "_NewEnum", "Array_NewEnum" to the ArrBase declaration and adding this to the script:
Alternatively, a function can be written using the same method as my previous example:
One could write an enumerator that returns array[1 .. array.MaxIndex()], including any in between which weren't set and therefore wouldn't normally be enumerated. I suppose that would be more intuitive for arrays.


I plan to add {key: value} and [value, value2, ...] syntax relatively soon and have been considering what to do with []. Some of the options are:

1. Make it pure shorthand for Object(1, value, 2, value2, ...).
2. As above, but set a common base object. This base object might implement the most basic behavioural changes needed to be intuitive, but could also be extended by script.
3. Implement a simpler, faster and more memory-efficient array object. It might be strictly one-based, or flexible (arbitrarily-based). An item's location in memory would be directly calculated from its index; i.e. no key lookups. Arrays might have a common base object as in #2, but it would be invoked only by method-calls such as arr.concat(arr2), not get/set. Unlike #2, reassigning the base as in arr.base:=x would either be disallowed or would affect all arrays.

Alternatively, you could allow key omittion:



Why using different syntax ?


Also, one could perhaps have advanced form of autonumbering:

This is problematic cuz of 3 but can be solved using some autonumbering metachar or somehing similar like 2{val1, val2, ... val3}.

Actually, you might want to see how it is defined in Lua if you already didn't: table initializers

About faster arrays, I think that is probably good thing to do altho I wouldn't give it high priority. Perhaps introducing special integrated base could serve for marking fast arrays (since you mentioned base might be read only after initialization).

_________________

That is bound to cause more confusion than it is worth, thanks to AutoHotkey's command syntax. Your example accidentally supports my argument:
It's missing a comma. Since it would need for ,, value in object, may as well just do for _, value in object.
Originally I had intended to use only [], leaving {} as invalid in an expression. After a lot of thinking over a substantial amount of time, I came to the conclusion that it will be far easier to implement if it is strictly key:value, key:value, etc. I think there's rarely a real need to mix numeric indices with other keys, and doing so often causes problems, particularly with enumeration.

Additionally, JSON has the advantage of familiarity; in that sense, the syntax you are proposing and the slightly different syntax I originally had in mind could be considered "different syntax".
What is the practical application of mixing numbered and named keys in that way?
Every key stored in an object must be associated with a value. Allowing "" to be omitted would mean a loss in error-detection with very little gain in convenience.
To support mixing of keys, I think the most feasible implementation would convert the syntax to a sequence of "instructions", like (pseudo-code):
...where @Set and @Append would perform the obvious action and return a reference to the target to allow chaining.
You seem to be condemning "different" syntax and suggesting new and/or unusual (i.e. "different") syntax in the same breath...
I had been considering initially making [a,b] shorthand for Object(1,a,2,b), with the warning that certain functionality might be removed or changed in future; i.e. when I change to a more efficient, more conventional array implementation. So it might just be "different syntax" at first, but later it would reflect the different functionality.
I don't understand what you're suggesting or how it relates to the following statement:
I said nothing to that effect in my previous post. I recall saying something like that about Object() a while back; i.e. Object("base",x,"y",z) could store z in .y without triggering the base object. Is that what you're talking about?

In my previous post, I said "it would be invoked only by method-calls"; in other words, arr.foo() would be equivalent to arr.base.foo(arr), but arr[n] would never trigger a meta-function regardless of what value n contains. In retrospect, arr[0]() should be allowed and should not trigger a meta-function, whereas arr.foo should trigger a meta-function since it cannot have any other purpose. It would've been better to suggest that any non-numeric key or name may trigger a meta-function and any numeric index may not.

No, I refer to your thoughts:




I am throwing some ideas. It doesn't mean I totally digested them. Its not very wise to involve substantial effort in precise semantics if you don't think the proposition has its merits. I can always do so if you seem interested in idea.


Fast Initialization of arrays obviously:


It could also be used for easier dynamic initialization of arrays based on some program input.

BTW, are you planning to support multidimensional initializers ?

_________________