Plugin array to a Xojo array bridging leads to compiler ambiguity?

Given

REALarray BassClass_Files(REALobject instance)
{
    ClassData(BasClass, instance, BasData, data);
    REALLockObject((REALobject)data->files);
    return data->files;
}

and the method definition

{ (REALproc) BassClass_Files, REALnoImplementation, "Files as FolderItem()", REALconsoleSafe }

In Xojo you can’t do

for i as integer = 0 to UBound(Basic1.Files)
  FileList.AddFolder(Basic1.Files(i).Name)
next

because the compiler says “Too many arguments, got 2, expected 0” for “Basic1.Files(i).Name”. You need to do the following:

for i as integer = 0 to UBound(Basic1.Files)
  dim ff() as FolderItem = Basic1.Files
  FileList.AddFolder(ff(i).Name)
next

Why? How can you make it happen that the compiler is not getting confused? A different method definition, or add a setter like

    { (REALproc) BassClass_Files, REALnoImplementation, "Files as FolderItem()", REALconsoleSafe },
    { (REALproc) BassClass_SetFiles, REALnoImplementation, "Files(assigns f() as FolderItem", REALconsoleSafe },

?
That does not cut it because Xojo has difficulty to choose which of the two is meant:

FileList.AddFolder(Basic1.Files(i).Name)

“There is more than one item with this name and it’s not clear to which this refers”. Btw, FileList is a Listbox.

We have this problems since we got array support.

I often fix it by putting my own method there taking index and returning one object from array.

Nobody filed this as a bug?

not as far as I know, please do yourself.

<https://xojo.com/issue/47593>

Been there, done that. Given up trying to use arrays in my custom plugin. I’ve instead moved on to use Dictionaries instead…they’re a little more work but I’m having none of the problems noted here, and they’re more versatile, and I can use them as a property, not a method.

Cheers
Grant

A sample plugin that demonstrates this would let me look at the plugin bridging side of things quickly to see what gets generated

For the sake of completeness, Norman figured that this behavior can be reproduced without a plugin. So it has nothing to do with the introduction of the REALarray in the plugin SDK. See the updated Feedback case for the details.

Would be great if they can fix the compiler to see that there is a property/method not taking the parameter and returns an array which can take the parameter as index.