[v1] Bug or limitation in associative arrays?

Get help with using AutoHotkey and its commands and hotkeys
User avatar
Drugwash
Posts: 842
Joined: 29 May 2014, 21:07
GitHub: Drugwash2
Location: Ploieşti, Romania

[v1] Bug or limitation in associative arrays?

28 Mar 2018, 08:05

Today I tried to improve some code so I bit the bullet and took on arrays. Needed an associative array so I built one that has 131 pairs, all strings, most on the value side empty.
Launching the script I got an error "expression too long" on the array object.
The array is defined using curly brackets in the form:
Arr := {item1:"", item2:"", item3:"val3",… item131:""}
(actually it's split vertically item by item for easier code viewing)

Trimming the array to only 127 item pairs cleared the error. Sounds like a bug in some internal variable that limits the number of items to 0x7F but maybe it's by design. Same thing happens in AHK_H 1.x since it uses the same codebase. Thought I should ask.

Oh and almost forgot: is it possible to disable alphabetical enumeration of items in arrays or at least make it logical?
When doing For i, j in Arr it always enumerates items alphabetically instead of using the order they were added in when creating the array, and the user may not (always) want that. Then, when listing the enumeration, items containing numbers will appear disssociated, such as:

Code: Select all

item1
item10
item11
item12
item2
item3
item4
…
item9
It is not always possible/feasible/wanted to store the list and sort it before usage, such as in writing values to an ini file one by one, for example.
Part of my AHK work can be found here.
Helgef
Posts: 4663
Joined: 17 Jul 2016, 01:02
Contact:

Re: [v1] Bug or limitation in associative arrays?

28 Mar 2018, 08:52

Neither bug nor limitation of arrays, but as the message says, the expression is too long, use a loop.

The order of the enumeration isn't documented, if you have special needs you should use a custom object.

Cheers.
just me
Posts: 8522
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: [v1] Bug or limitation in associative arrays?

28 Mar 2018, 08:58

It's a known limitation of AHK's expression parser, but afaik still not documented.
User avatar
Drugwash
Posts: 842
Joined: 29 May 2014, 21:07
GitHub: Drugwash2
Location: Ploieşti, Romania

Re: [v1] Bug or limitation in associative arrays?

28 Mar 2018, 09:27

Helgef wrote:Neither bug nor limitation of arrays, but as the message says, the expression is too long, use a loop.

The order of the enumeration isn't documented, if you have special needs you should use a custom object.

Cheers.
just me wrote:It's a known limitation of AHK's expression parser, but afaik still not documented.
Thanks for replying. At least I found out it's not my fault. I'm trying to do things as simple as possible but apparently even simple is sometimes too complicated. :roll:

I only have a bunch of variables that I need to initialize or delete, nothing special or fancy, and they sometimes can have different names when read from ini or written to than the names actually used in the script, so I thought such array would be the best candidate: get key name from array and replace with value (if existing, otherwise use key name). What could be more simple than that? What it one needs an array of 2000 pairs? :(
For now I'll just split the pairs string. Unfortunately AHK dissapoints me more and more everyday, especially in the "new" features that suposedly should be superior to old ones. Oh well, no use in ranting, I'll go back to my toys.

Thank you both.
Part of my AHK work can be found here.
User avatar
nnnik
Posts: 4497
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: [v1] Bug or limitation in associative arrays?

28 Mar 2018, 09:35

You are using Objects for something they are not good at.
Seeing that you have a need for this points at bad coding habits.
Recommends AHK Studio
User avatar
Drugwash
Posts: 842
Joined: 29 May 2014, 21:07
GitHub: Drugwash2
Location: Ploieşti, Romania

Re: [v1] Bug or limitation in associative arrays?

28 Mar 2018, 10:05

I'm using what is suggested in the Help manual, since being an AHK Basic user at core I don't have intimate knowledge of arrays, objects, classes and so on.
Could you please elaborate and maybe offer an alternative, simple and easy solution?
What would be those bad habits?
The code is not mine (except for small parts) so I can't make huge changes to it.
Part of my AHK work can be found here.
User avatar
nnnik
Posts: 4497
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: [v1] Bug or limitation in associative arrays?

28 Mar 2018, 10:13

Yeah generally everything that is not considered "Clean Coding".
That however is a topic large enough for several books so I don't quite have the time to completely lay it out.
I would probably read the data from a file and then read it into an array at load time rather than hard coding it.
Recommends AHK Studio
User avatar
Drugwash
Posts: 842
Joined: 29 May 2014, 21:07
GitHub: Drugwash2
Location: Ploieşti, Romania

Re: [v1] Bug or limitation in associative arrays?

28 Mar 2018, 10:39

We're trying to keep additional files to a minimum and it's already complicated, since we're using AHK_H with additional threads which are unavailable when running under AHK_L.
The variables have undergone a few changes for a few times and we - mostly I, actually - have been trying to avoid forcing the users to personalize their setup after each update by simply ignoring their current settings from the ini file, but in order to avoid that we need to know what settings to read, how to interpret them and what can be deleted. Additionally, values need to be checked for valid ranges and corrected, in case the user messed directly with the ini. The solution found seemed optimal, hardcoding variable names (not their values) shouldn't be a problem and having them all in a single place at read/write should simplify their manipulation and the understanding of the code, in my opinion.

Reading from an external file would mean forcing the user to download additional files from the server or embedding/extracting at run time when script is compiled, both of which being much more complicated than reading a built-in array.

Thank you for your input (was about to say "thank you for your candor" but I'm too divergent :lol: )
Part of my AHK work can be found here.
User avatar
nnnik
Posts: 4497
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: [v1] Bug or limitation in associative arrays?

28 Mar 2018, 10:46

Well parsing a hard coded string is a valid option too.
e.g. a JSON string
Of course all the best practices won't help with a project that has already been delivered. They only really work if you had them when you started writing the project.
Recommends AHK Studio
User avatar
Drugwash
Posts: 842
Joined: 29 May 2014, 21:07
GitHub: Drugwash2
Location: Ploieşti, Romania

Re: [v1] Bug or limitation in associative arrays?

28 Mar 2018, 11:05

The way I see it, what we have is already a string, it just comes in a particular form. I don't get it why internally AHK can't parse such CSV string regardless of its length and then do whatever mumbo-jumbo needed to make it an array.
If it wasn't for the alternative variable names it would've been a simple CSV string, of course. And doing it the old way - Loop, Parse, string, CSV and then StringSplit on A_LoopField - kinda makes me wonder what use do those arrays have anymore.

It's actually funny: when I do things the old-fashioned way people ask why not use the new methods/functions/etc, and when I try that supercalifragilistic stuff (and fail - just my luck) they tell me to do it the old-fasioned way. Isn't that confusing…

The project is KeypressOSD, the version taken over by robodesign, which I kinda joined much later with advices and small pieces of code. It's now grown, being mostly targeted to visually impaired people, and massive changes are hard to make unless absolutely necessary.
Part of my AHK work can be found here.
User avatar
nnnik
Posts: 4497
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: [v1] Bug or limitation in associative arrays?

28 Mar 2018, 11:50

Arrays are faster than string delimited lists and not by a little but rather a whole level faster.
What you have is a project that you started writing using the old style you can't just add in new style suddenly - thats inconsistent and will probably lead to issues.
You also can't insert old style stuff into new style scripts. Also you can pass CSVs in a single line - inis too.
Recommends AHK Studio
User avatar
Drugwash
Posts: 842
Joined: 29 May 2014, 21:07
GitHub: Drugwash2
Location: Ploieşti, Romania

Re: [v1] Bug or limitation in associative arrays?

28 Mar 2018, 12:24

The mixture of styles is not (entirely) my (un)doing within that project. But the style doesn't bother us (me, at least) a single bit as long as the outcome fits the vision, the goals. Styles may change in time, pieces can and probably will be optimized, improved. Keyword here is speed of reaction and heck, isn't it a pity not to be able to use arrays' speed because of this bug/limitation we stumbled upon?

The script in its public form contains a lot of very long lines that are very inefficient when it comes to checking for bugs or need modifications. I've modified that to allow for a more legible aspect of the code. Haven't checked whether that has any significant impact on speed.
Anyway, I'd refrain from pasting such long lines of code, be it CSV or anything else. Vertically stacking items is preferrable for legibility.
Here's the string of names that should be made an array, to be parsed later on; at the bottom a second object was created only to overcome the 127 item limitation. There is also a need for a precise parsing order for certain items which again cannot be ensured by this automatic alphabetical enumeration of items. How would you go about this?

Code: Select all

OldVars := {"":"" ; this is here only for aesthetic reasons
, AlternateTypingMode:""
, AlternativeJumps:""
, AltHook2keysUser:""
, AudioAlerts:""
, AudioDissapointment:""
, BeepFiringKeys:""
, BeepSentry:""
, BeepsVolume:""
, CapsColorHighlight:""
, CapslockBeeper:""
, CaretHaloAlpha:""
, CaretHaloColor:""
, CaretHaloFlash:""
, CaretHaloRadius:""
, ClickScaleUser:""
, ClipMonitor:""
, DeadKeyBeeper:""
, DifferModifiers:""
, DisableTypingMode:""
, DisplayMode:""
, DisplayTimeTypingUser:""
, DisplayTimeUser:""
, DoNotBindAltGrDeadKeys:""
, DoNotBindDeadKeys:""
, DragOSDmode:""
, DTMFbeepers:""
, EnableAltGr:""
, EnableClipManager:""
, EnableTypingHistory:""
, EnforceSluggishSynch:""
, EnterErasesLine:""
, ExpandWords:""
, FlashIdleMouse:""
, FontFilter:""
, FontName:""
, FontQuality:""
, FontSize:""
, GlobalKBDhotkeys:"KeyboardShortcuts"
, GUIposition:""
, GuiWidth:""
, GuiXa:""
, GuiXb:""
, GuiXc:""
, GuiYa:""
, GuiYb:""
, GuiYc:""
, HideAnnoyingKeys:""
, HostCaretHighlight:""
, JumpHover:""
, KBDaltTypeMode:""
, KBDCapText:""
, KBDclippyMenu:""
, KBDidLangNow:""
, KBDpasteOSDcnt1:""
, KBDpasteOSDcnt2:""
, KBDReload:""
, KBDsuspend:""
, KBDsynchApp1:""
, KBDsynchApp2:""
, KBDTglNeverOSD:""
, KBDTglPosition:""
, KBDTglSilence:""
, KeyBeeper:""
, KeyboardShortcuts:""
, MaxGuiWidth:""
, MaximumTextClips:""
, MediateNavKeys:""
, ModBeeper:""
, MouseBeeper:""
, MouseClickRipples:""
, MouseHaloAlpha:""
, MouseHaloColor:""
, MouseHaloRadius:""
, MouseIdleAfter:""
, MouseIdleAlpha:"IdleMouseAlpha"
, MouseIdleColor:""
, MouseIdleFlash:""
, MouseIdleRadius:""
, MouseOSDbehavior:""
, MouseRippleMaxSize:""
, MouseRippleThick:"MouseRippleThickness"
, MouseRippleThickness:""
, MouseVclickAlpha:""
, MouseVclickColor:""
, MouseVclickScaleUser:"ClickScaleUser"
, NeverDisplayOSD:""
, OnlyTypingMode:""
, OSDalignment1:""
, OSDalignment2:""
, OSDautosize:""
, OSDbgrColor:""
, OSDborder:""
, OSDshowLEDs:""
, OSDautosizeFactor:""
, OSDautosizeFactory:""
, OSDsizingFactor:"OSDautosizeFactory"
, OSDtextColor:""
, OutputOSDtoToolTip:""
, PasteOnClick:""
, PasteOSDcontent:""
, PgUDasHE:""
, PrioritizeBeepers:""
, ReturnToTypingUser:""
, SendJumpKeys:""
, SendKeysRealTime:""
, ShiftDisableCaps:""
, ShowCaretHalo:"HostCaretHighlight"
, ShowDeadKeys:""
, ShowKeyCount:""
, ShowKeyCountFired:""
, ShowMouseButton:""
, ShowMouseHalo:""
, ShowMouseIdle:"FlashIdleMouse"
, ShowMouseRipples:"MouseClickRipples"
, ShowMouseVclick:"VisualMouseClicks"
, ShowPreview:""
, ShowPrevKey:""
, ShowPrevKeyDelay:""
, ShowSingleKey:""
, ShowSingleModifierKey:""
, SilentMode:""
, SynchronizeMode:""
, ToggleKeysBeeper:""
, TypingBeepers:""
, TypingColorHighlight:""
, TypingDelaysScaleUser:""}

OldVars2 := {"":""
, UpDownAsHE:""
, UpDownAsLR:""
, VisualMouseClicks:""}

For i, j in OldVars
		If i
			%i% := %functionName%("r", (j ? j : i), "SavedSettings")
Part of my AHK work can be found here.
User avatar
nnnik
Posts: 4497
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: [v1] Bug or limitation in associative arrays?

28 Mar 2018, 12:36

I would probably create a settings class which collects the data from several sources automatically on startup and add all the neccessary features.
Recommends AHK Studio
User avatar
Drugwash
Posts: 842
Joined: 29 May 2014, 21:07
GitHub: Drugwash2
Location: Ploieşti, Romania

Re: [v1] Bug or limitation in associative arrays?

28 Mar 2018, 12:54

Besides the fact that I/we have no idea how to work with classes, wouldn't that be overkill for something already designed to be discarded after a few versions or at least kept dormant until other changes - if any - would require it?

The thing above basically has to read settings from an ini file, that may have been saved by various older versions of the main script under different names, in a certain order, store the most recent valid values in current variables and on exit delete old obsolete entries from the ini before writing the new names and their corresponding values. Obviously the above is not the entire code, there are other parts that automatically check for keys in different ini sections and read/write accordingly, those will stay and should be as quick as possible at script start and exit. That part is similar and it works well so far.
Part of my AHK work can be found here.
User avatar
nnnik
Posts: 4497
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: [v1] Bug or limitation in associative arrays?

28 Mar 2018, 13:03

A class is generally something I write in less than a few minutes - I actually take longer for functions since I'm not used to them.
Also classes are reusable meaning that when you face the same problem again you could use the same fix with little to no adjustments.
Recommends AHK Studio
User avatar
Drugwash
Posts: 842
Joined: 29 May 2014, 21:07
GitHub: Drugwash2
Location: Ploieşti, Romania

Re: [v1] Bug or limitation in associative arrays?

28 Mar 2018, 13:26

You may be right, in certain situations when it fits it fits. I'm not sure here though, and learning how to create and use classes might be too much now for an old dog like me. :)
Anyway, danke schön for the help and ideas.
Part of my AHK work can be found here.
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: [v1] Bug or limitation in associative arrays?

28 Mar 2018, 15:56

- Limits that I listed here:
jeeswg's documentation extension tutorial - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=7&t=33596
[LIMIT] Array: when defining an object via [] or Array(), it can have at most 255 keys (more keys can be added later) (StrSplit could be used instead)
[LIMIT] Object: when defining an object via {} or Object(), it can have at most 127 keys (more keys can be added later)
Classic maximum numbers that are approximately 2 to the power of something.

- AFAICS you're using objects precisely for their intended purpose, to store key=value information, or as an alternative to a massive number of variables, so I'm unsure of what the earlier criticism was in reference to.
- If the data never changes, it's fine to hardcode it, otherwise, it's good to read it from a separate file.
- In general, the comments made in this thread have made the very simple sound unnecessarily complex.
- Classes were mentioned, although this seems like overkill. [EDIT:] Oh you also used the exact word 'overkill'.

- To retrieve the item keys in the correct order, you can do this:

Code: Select all

Arr := {item1:"", item2:"", item3:"val3"}
Loop, 3
	MsgBox, % Arr["item" A_Index]
- If each key is called 'item', I would suggest creating a linear array with key names 1-131, instead of an associative array with key names item1-item131:

Code: Select all

oItem := ["", "", "val3"]
Loop, 3
	MsgBox, % oItem[A_Index]
- To parse an array in a custom order you can do this:

Code: Select all

Arr := {item1:"", item2:"", item3:"val3"}
List := "item1,item2,item3"
Loop, Parse, List, % ","
	MsgBox, % Arr[A_LoopField]
- You can create an array like so:

Code: Select all

vText := "
(
item1=a
item2=b
item3=c
)"
oArray := Object(StrSplit(vText, ["=", "`n"])*)
MsgBox, % oArray["item3"]
- You can also create an array by doing this:

Code: Select all

vText := "
(
item1=a
item2=b
item3=c
)"
oArray := {}
Loop, Parse, vText, `n, `r
{
	oTemp := StrSplit(A_LoopField, "=")
	oArray[oTemp.1] := oTemp.2
}
MsgBox, % oArray["item3"]
Note: if the list is already in alphabetical order, creating the array will be faster.

- [EDIT:] I've updated my tutorial here:
jeeswg's objects tutorial - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=7&t=29232
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
nnnik
Posts: 4497
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: [v1] Bug or limitation in associative arrays?

28 Mar 2018, 16:34

I would reccomend you to completely ignore ignore jeeswgs programming style when it's about good coding practices.
Arrays and objects are meant to store data which dynamically changes or to represent abstract structures.
Hardcoding them into the source is not what they are meant for. Thats why you hit limits there.
Arrays and objects are not meant to store variables. Thats a misconception.
Recommends AHK Studio
User avatar
jeeswg
Posts: 6902
Joined: 19 Dec 2016, 01:58
Location: UK

Re: [v1] Bug or limitation in associative arrays?

28 Mar 2018, 16:51

- @nnnik: Your style of coding, like that of other people, is esoteric, and your wish list suggestions are the most esoteric of any. What I'm saying is that your posts have an air of 'I am the ideal programmer, I always code in the ideal way', I neither agree nor disagree with this. What I question is, by what basis have you established this 'fact', where are your sources for ideal programming.
- You demonstrate a definite flair for discussing the theory of programming, I wish you would combine your instinct for perfect programming with an instinct for the simple, the straightforward.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
nnnik
Posts: 4497
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: [v1] Bug or limitation in associative arrays?

28 Mar 2018, 17:22

Classes only seem impractical to you because you don't use them in practice - once you do get used to them they are very practical.
I'm far from ideal and I agree that I do have a tendency to overthink things. However practically speaking using a string ( from a file if you want to ) to define you settings and writing a piece of code that reads those
settings and making all your scripts access those settings shouldn't be too difficult.

My sources among other things come from experience and studying it at my university.
There is a massive difference between people that studied the subject or spend their days actually working as a developer and those that are pure self taught.
Thats probably the difference that you notice.
Recommends AHK Studio

Return to “Ask For Help”

Who is online

Users browsing this forum: arczi_87, geoffh, Green Astronaut, HiSoKa, hitman, mikeyww, samyo2323, XMCQCX and 56 guests