Custom Query (3931 matches)

In GuiListBox.au3, the Return Value description of the functions _GUICtrlListBox_AddFile, _GUICtrlListBox_FindString, _GUICtrlListBox_GetAnchorIndex and _GUICtrlListBox_GetText is the same:

Success      - Zero based index of the file that was added

But it is only relevant for _GUICtrlListBox_AddFile. Seems to be a forgotten copy & paste.

This probably affects the online documentation as well, as it seems to be built from the GuiListBox.au3 sources.

Under the "_WinAPI_SetWindowsHookEx" section (WinAPI Management) it lists "$WH_KEYBOARD_LL" as a "procedure that monitors low-level mouse input events." I think this should read that it monitors "low-level keyboard input events."

Memory re-allocation is an expensive operation and as such, should be avoided. For _FileListToArray to read a directory with N entries, it will need to perform N ReDim operations, and with each ReDim operation costing O(N) (assuming that ReDim is implemented efficiently), _FileListToArray will cost O(N²).

A very common way to mitigate this is to double the array size with each re-allocation instead of just incrementing it. Under such a system, you will greatly reduce the number of ReDim operations, down to log2(N), bringing the final asymptotic cost of the function down to O(NlogN), which is optimal.

I am attaching a patch that will fix this problem.

With large directories with about 300 files, implementing this simple change reduced the time spent by over half (from ~10s for 100 runs down to ~4.8s for 100 runs in my benchmark). Proportionally, the performance win will be even larger for directories with more entries.