Custom Query
Results (91 - 93 of 3833)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#571 | Fixed | Return value documentation is incorrectly copied in ListBox module | Gary | splintor@… |
Description |
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. |
|||
#595 | Fixed | Typo in help file. | Gary | ryantollefson |
Description |
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." |
|||
#599 | Completed | _FileListToArray costs O(N^2) instead of O(NlogN) | Gary | code65536 |
Description |
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(N2). 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. |