_ArrayDisplay not able to display all elements of an array

[BrewManNH]

There appears to be an undocumented change to _ArrayDisplay since at least 3.3.8.0, either the wrong version was put into the Array.au3 file or it was changed since 3.3.6.1 without being mentioned. The version in the latest release (and the 3.3.9.0 beta) will not display all of the elements in an array if the array has more than 65,530 elements.

The older version didn't have this limitation because this code:

; Fill listview
Local $aItem
For $i = 0 To $iUBound
	If GUICtrlCreateListViewItem($avArrayText[$i], $hListView) = 0 Then
		; use GUICtrlSendMsg() to overcome AutoIt limitation
		$aItem = StringSplit($avArrayText[$i], $sSeparator)
		DllStructSetData($tBuffer, "Text", $aItem[1])
			; Add listview item
		DllStructSetData($tItem, "Item", $i)
		DllStructSetData($tItem, "SubItem", 0)
		DllStructSetData($tItem, "Mask", $iAddMask)
		GUICtrlSendMsg($hListView, $_ARRAYCONSTANT_LVM_INSERTITEMW, 0, $pItem)
			; Set listview subitem text
		DllStructSetData($tItem, "Mask", $_ARRAYCONSTANT_LVIF_TEXT)
		For $j = 2 To $aItem[0]
			DllStructSetData($tBuffer, "Text", $aItem[$j])
			DllStructSetData($tItem, "SubItem", $j - 1)
			GUICtrlSendMsg($hListView, $_ARRAYCONSTANT_LVM_SETITEMW, 0, $pItem)
		Next
	EndIf
Next

Has been replaced by this code:

; Fill listview
For $i = 0 To $iUBound
	GUICtrlCreateListViewItem($avArrayText[$i], $hListView)
Next

Which, as you can see, uses the native function to create the LV items, which is limited by the number of Control IDs available to do so.

Just wondering if this is as intended or if there is a problem to report.

[Beege]

I going to guess this was indeed intended because of the large performance advantage GUICtrlCreateListViewItem brings, but I do find it strange how it was never documented. Perhaps that section of code can be used only if the amount of elements exceeds 65530, or just add a remark to _arraydisplay() doc informing the user of the limitation.

[guinness]

It was changed in Revision:5963 due to this bug report >> ​https://www.autoitscript.com/trac/autoit/ticket/1833

[BrewManNH]

It might be a good idea to document the change and let others know. I will probably never run into the problem as I rarely if ever have an array with more than 65,000 rows in it. There's no mention in any of the changelogs that _ArrayDisplay was changed to fix the >4094 character limit.

[Valik]

This change would not normally be documented because using native or API methods to create the items should be an irrelevant implementation detail. However, in this case, it turns out it's not an irrelevant detail. Just one more reason for me to hate the built-in version, I guess.

I suggest making a note in the documentation that there is a limit. The note in the changelog can reflect the closing of this ticket. It's a bit late but it's better than nothing I guess.

[guinness]

Added by revision [6775] in version: 3.3.9.1

[BrewManNH]

Rather than just updating the documentation, may I make a suggestion to change _ArrayDisplay back to the way it was but with the modification JPM put into the function to prevent long strings from becoming blank as reported in ​http://www.autoitscript.com/trac/autoit/ticket/1833? The only thing that was changed other than the creation of the listview using only the native function, was to limit the actual amount of text allowed per string.

The $iBuffer variable was changed to 4094 in line 344, and the code below:

	; Add to text array
	$vTmp = StringReplace($vTmp, $sSeparator, $sReplace, 0, 1)
	; Set max buffer size
	If StringLen($vTmp) > $iBuffer Then $vTmp = StringLeft($vTmp, $iBuffer)
	$avArrayText[$i] &= $sSeparator & $vTmp

from lines 396 to 402 replaced the lines below (from Array.au3 UDF vers. 3.3.6.1):

	; Add to text array
	$vTmp = StringReplace($vTmp, $sSeparator, $sReplace, 0, 1)
	$avArrayText[$i] &= $sSeparator & $vTmp
	; Set max buffer size
	$vTmp = StringLen($vTmp)
	If $vTmp > $iBuffer Then $iBuffer = $vTmp

If you change these lines in the original (from 3.3.6.1) _ArrayDisplay, you eliminate both problems at the same time. The part where the listview is created in 3.3.6.1 didn't need to be touched to prevent the problem reported in ticket 1833, just limiting the size of the string needed the change.

[Jpm]

Do you really need to display more than 65635 lines?
Can you tell how to manage to view/search what you are looking for?

I think the update of the Doc is OK for such debugging finction.

[BrewManNH]

Replying to Jpm:

Do you really need to display more than 65635 lines?
Can you tell how to manage to view/search what you are looking for?

I think the update of the Doc is OK for such debugging finction.

Personally, I don't think I'd ever run into the problem, but I thought that others might find it a problem.
Considering the change back to the way the listview was created pre-3.3.7.0 wouldn't affect any changes made to limiting the string size to prevent blank lines that was implemented.

Because it's just a debugging function I can live with it working as is, but then again I'm not every other user. It was just a suggestion to "fix" the function.

[BrewManNH]

As a follow up to the above, if _ArrayDisplay is used with a Listview that's fed with a very large array, and you wanted to display that array with _ArrayDisplay, then the function could end up displaying nothing because you've used up all of the control id's available in the GUIs ListView and there aren't any (or very few) control IDs left for _ArrayDisplay because a change was made that did not need to be made.