Possibly related to this: Previous post
When creating a listbrowser node with less column entries than the number of entries in ColumnInfo (the number of columns), your application crashes.
That is: You have created 3 columns and you try to add a listbrowser node with only 2 entries for LBNA_Column (0 and 1).
Can someone confirm this issue?
Not a "bug". The listbrowser just expects that nodes and columninfo should have the same amount of columns because the API and internal structures were not designed for dynamically adding and removing columns.
Kind of odd that a unit, that allows for dynamic adding and removal should be not designed to do so? Seems a bit counterintuitive. I would argue, that in that case it is an instance of bad design. But of course I could be unaware of certain details in the internal structure.
EDIT: In any case a crash at this point seems highly illegit and suggests, that the mentioned behavior has in fact just not been tested at all.
It's designed for dynamically adding and removing rows not columns.
In any given listbrowser all rows must have the same number of columns and this must match the number specified in the ColumnInfo structure.
The crash is not the result of lack of testing it's rather actually expected as the column number is fixed and if you pass node with the wrong number (at least if less than) then as the browser counts through the nodes it will inevtibaly read past the end of the array.
Could be remedied with a simple if statement? Also, it has not been specified, that columns be given in a specific order, so some kind of generic checking must be already present? I fail to see, why this crash is a necessary result of the algorithm.
See my comment about "error checking" on your other thread :-)
The thing I am trying to convey is, that the argument of "little overhead" in response to lack of parameter checking is not sound. There is no conceptual conflict in the creation of list nodes with less than maximum number of column entries. Nor is there any conceptual conflict in trying to create list nodes with any kind of arbitrary enumeration of the column entries defined. The result is, that there seems to be no conceptual standard applying to the functioning of the entities under concern. And that is a clear sign of bad coding design.
Bounds checking would need to be done every time a column is accessed in a LB node. It is a lot of work for little to no benefit.
Much better would be to change the columns array into a list so that columns can be added to and removed from LB nodes dynamically.