CellTextAt is a Method?

The deprecated ListBox had a Property: CellValueAt.
As best I can tell, with the new DesktopListBox, this has been replaced with a Method: CellTextAt.

Var i As Integer
For i = 0 To Self.ControlCount - 1 // number of controls in window
  ListBox1.AddRow(Str(i)) // first column
  ListBox1.CellTextAt(Listbox1.LastAddedRowIndex, 1) = Control(i).Name // second column
Next

So we have this syntax:
ListBox1.CellTextAt(Listbox1.LastAddedRowIndex, 1) = someString

How is it that we are now assigning a value to the result of a Method?

Has this grammar been present in Xojo before?

To me that looks more like you are assigning a value to a multi dimensional array:

Such as a(1,1) = 10

I suspect that the listbox is just an array of cells…

TC

It’s a pair of method definitions that look like this:

DesktopListBox.CellTextAt(RowNumber as Integer, ColumnNumber as Integer = 0) As String
DesktopListBox.CellTextAt(RowNumber as Integer, ColumnNumber as Integer = 0, Assigns value as String)

This sort of thing has been possible in Xojo for quite a long time now. You can read more about Assigns for more information.

For an example of its usage in Desktop API 1.0 controls, you can take a look at ListBox.CellTagAt (and many others).

1 Like

I can understand that. But the Language Reference has ListBox1.CellTextAt as a Method.

a(1,1) is not a Method. In my mind, an array would be a Property.

I am puzzled why this entity (CellTextAt) has been moved from Property to Method with the migration from ListBox to DesktopListBox.

It is a method. And “1, 1” are the parameters.

If I had to guess, I’d say that it was a pair of method definitions before but was documented as a property. Could be wrong, though, as I don’t have access to the Xojo source or knowledge of how they documented things then versus now.

1 Like

I’m pretty sure that’s true.

And methods are preferable because, unlike properties, you can override them in a subclass.

2 Likes

Anthony, thanks for the example. I had never noticed/comprehended this. I guess it is just something to get used to.

My confusion started when I got the message that Listbox2.CellValueAt was an error in the world of the new DesktopListbox. My instinct was to look at the Properties of DesktopListbox for the replacement because Listbox2.CellValueAt was a Property.

It turns out that the replacement is under the Methods of DesktopListbox: CellTextAt.

Language Reference: ListBox.CellTagAt.
" Gets or sets a “hidden” identifier associated with the cell identified by its parameters. Row and Column are zero-based."

You are correct. Many years ago (10+), getter/setter methods were listed as properties in the docs. With API 2 stuff we are listing them as the methods they truly are so that people realize 1) they won’t be shown in the debugger and 2) that they can be overridden.

4 Likes

Thanks for confirming, Paul. Makes sense.