see AddRowAt? - #4 by Paul_Lefebvre - General - Xojo Programming Forum
It doesn’t work because AddRow() and AddRowAt() have different method signatures. AddRow() allows you to supply a ParamArray with values for each column. AddRowAt() does not use a ParamArray so you can only add the first column. Add subsequent columns using CellValueAt like Scott showed (except I would also use LastAddedRowIndex):
ListBox1.AddRowAt(0, "red")
ListBox1.CellValueAt(ListBox1.LastAddedRowIndex, 1) = "green"
ListBox1.CellValueAt(ListBox1.LastAddedRowIndex, 2) = "blue"
I’m scratching my head about why AddRowAt can’t use a ParamArray too …? After all, the code for dealing with a ParamArray already exists in AddRow …
And jurg has already pointed out that we can do it for ourselves
but really we should not have to
And, here’s the kicker, when they DO decide to add that all your extensions will now cause compilation errors
YAY !!!
You then can remove your own extension - and beg that Xojo has implemented it without bugs 
No, as long as you’re then only using the latest Xojo Version, it’s not that big of an issue… Delete own method - all good again.
But… what about code being used in various projects with various (also older) Xojo Versions…?
We share quite some Modules with “helpers” across all our projects… And I don’t think you can exclude a Method conditionally depending on the XojoVersion…
But why? I try to understand the logic behind it.
That MapLocation is very badly implemented is explained in the next xDev, but there you could argue Xojo isn’t familiar with it - you can’t do that with the Listbox …
That’s why you should give your own solutions a prefix or postfix … (like MBS does)
Ah, right - this now reminds me that we’ve done that all way long in “real life” 
Just didn’t think of that right now when trying this quickly for fun.
btw - Postfix also helps with AutoComplete - whenever I write myFolderItem.Exi <tab> I get reminded to use our own Method (ending with a Postfix), as we’ve worked around the bugs in Xojo’s method 
sort of
flip compat flags on the methods & modules when you move back and forth between versions
see Maintaining backwards compatibility in 2019r2 – Writings from the sticks
Mind explaining the problems and sharing the code? Might make a good tutorial too …
About Jürg’s extension method at AddRowAt? - #5 by Jürg_Otter - General - Xojo Programming Forum
Be aware that the addRowAt method will append the row at the end if the given row number does not exist - so you can’t assume that the “inserted” row has the row number you think - and as trying to remove a non-existing row will get you into hot water, the ReplaceRowAt extension method should be
Public Sub ReplaceRowAt(Extends lb As Listbox, RowNumber As Integer, ParamArray Items() As String)
// this allows you to replace multiple values in a row like this:
//
// Listbox1.ReplaceRowAt(0, "red", "green", "blue")
If RowNumber > lb.LastRowIndex Then
MsgBox "The row you try to replace does not exist - the row number you gave is higher than the row number of the last row!"
// do some damage limitation here:
Else
lb.RemoveRowAt( RowNumber )
lb.AddRowAt( RowNumber, Join(Items, ",") )
End If
End Sub
If the row is out of bounds then maybe an out of bounds exception should be raised - same as the listbox would do ?
That can be part of the damage limitation
I like to know about such errors, so I trap the errors and give the user a chance to report it with one simple click.
That’s not an issue since…
If you try to delete a Row which doesn’t exist, RemoveRowAt will raise an OutOfBoundsException.
However, this is an issue in your Method:
Join(Items, ",")
This will insert all Column-values joined together comma-separated into the first column
The most tricky part seems to be trying to call a Method with a ParamArray from another Method that has a ParamArray…
If I just add this one:
Public Sub ReplaceRowAt(Extends l As Listbox, RowNumber As Integer, ParamArray Items() As String)
l.RemoveRowAt(RowNumber)
l.AddRowAt(RowNumber, Items)
End Sub
Then the original extension method will not get called because of a compilation error - Items is not a ParamArray that you can hand over to the other method like this. I don’t know if it is possible to “create a ParamArray in code”?
So I’d probably do the adding method like this:
Public Sub AddRowAt(Extends l As Listbox, RowNumber As Integer, Items() As String)
If (Items.LastIndex < 0) Then
l.AddRowAt(RowNumber, "")
Return
End If
l.AddRowAt(RowNumber, Items(0))
If (Items.LastIndex < 1) Then Return
For i As Integer = 1 To Items.LastIndex
l.CellValueAt(l.LastAddedRowIndex, i) = Items(i)
Next
End Sub
And to still have the originally intended AddRowAt:
Public Sub AddRowAt(Extends l As Listbox, RowNumber As Integer, ParamArray Items() As String)
l.AddRowAt(RowNumber, Items)
End Sub
its not
As you did you need two different extensions (or a private method or something else)
1 that gets a paramarray, one that just takes an array
Then the paramarray one can call the array based one
as a reaction 
