Build error: "There is more than 1 method with this name

This has me totally stumped as to where to look for the underlying cause… any other ideas welcome. I’m in the throes of converting a large desktop app from API1 to API2 (Xojo 2021 build 3.1), and I had over 16,000 errors to start with.

In the process of fixing these I’m finding I often see a build fail with the message “There is more than 1 method with this name, but this does not match any of the available signatures.”

I already know the cause of these is not the class/method/object that was pinged by the IDE. So far I have established two causes are either:

  • a mismatched “if… end if”, in a completely unrelated method to the one the IDE pinged as faulty, or
  • a method with an input parameter belong to an API1 class (since the class names changed in API2).

Out of sheer desperation, its possible to delete the offending method or even the class pinged by the IDE, though this just generates another slew of (unhelpful) errors. It’s like searching for a needle in a haystack as this project is over 30MB and the IDE provides no clue as to the real error, nor where it occurred…

After 4 weeks at this I am experimenting with an alternative - ditch the whole idea of converting to API2, and instead subclass the API2 stuff with new subclasses that implement the API1 methods properties and events, a deliberate subversion of API2 back to API1. Because this is less work than converting my app.

Sorry Xojo but API2 is definitely a FAIL as far as I’m concerned.


I’m definitely with you !!!

You started the conversion process, so go ahead.

If you have large enough monitor (or two monitors), place a second Workspace and enlarge the bottom area (error / debugger area).

Then remove each and every If … Then errors, and all other errors and try to “skip mentally“ these errors until it is time to resolve them (if they are still there).

Or: you may by coincidence (bad luck) used already existent (but invisibles to us) Xojo method. So, add an underscore inside the duplicate name to set it unique and run…

Also, avoid non ASCII characters in Method, Functions, Variables names as a precaution. US software usually do not like them.

Now what are thinking people who already made project translation to API2 ?

The title of this thread is wrong. It should be “Problems with API1 to API2 conversion”.

Also see:

The API1 to API2 conversion only changes the classes. It doesn’t fix the methods/events/properties, for example the listbox.cellTag(row, col) becomes desktoplistbox.cellTagAt(row, col) in API2.

Instead of hunting for thousands of errors it is actually a LOT quicker to subclass the API2 classes and add methods etc implementing the old API1 syntax, and use these classes.

What really grates is that most of the syntax changes made in API2 seem to be change for no real reason.


While that would help (but kind of defeats the point of API 2 for Xojo Inc - though some [many?, Most?] long time users would argue it was mostly pointless anyway), the bigger issue (because it’s more subtle) in converting code IMO is the change in indexes, which has to be done carefully manually.


1 Like

Reminding everyone again… you don’t have to go through your projects and do this if you don’t want to. API 1 is going to be around for a very long time as the IDE is written entirely in it.


My brain can retain only one set of instructions. Additionally, it’s awful to write code without autocomplete.


Maybe you need other plugins :wink:

Beatrix is not alone in this sionking boat: I too have problems.

Worst: it also tooks far more time to use API2 / to do something in API2; the LR pages is starting to be unreadable (I read them too often).

There is a reason, and I suspect it is the same kine of reason the file format was chganged (in part).

Who cannot understand .Add and .Insert ?

“Add” is a mathematical operation. “Append” was exactly the correct word.


It is perfectly valid to “add to a list”, which is nothing to do with mathematics.

Of course it is, but the keyword is not “AddToAList”. “Add” is ambiguous, and “AddRow” is silly because one-dimensional arrays don’t have rows imo. “Append” was perfect and concise (imo), but apparently Xojo has a low opinion of its users’ vocabularies, or maybe people just feel compelled to change things because it makes them feel useful.


Add to a list does not specify the location in the list…On paper one could "add’ to the top or the bottom of an existing list (or even between lines if there is space) and in all cases you would be adding.

Append specifically means add to the end of the list.

My first thought when I saw some of the API 2 changes was that Xojo inc thinks their (potential?) users understanding of language was at the 3rd grade level!



Typically adding to a paper list, for example, can only be a the end. As for needing an AddToAList it is already there:

TypeOfItem.Add tells you exactly what you are adding to. Making a generic Add provides consistency across all the things it could add to. .Add and .AddAt provide a reasonable set of options and just as valid as Append and Insert. Neither really is any better than the other.

To be totally correct AddRow is wrong for any type of array. You may or may not be using a two dimensional array to represent Rows and Columns but you could be representing any other concept.

I would agree with usually, but not only, as that is simply and demonstrably not true.

I have added to grocery lists many times to the top, between lines as well as to the side in no particular order many times…



To be clear Add does not specify order or imply an ordered list.

Append does imply an ordered list and specifies adding to the end of it.



You obviously space your writing far wider than I do. I would never be able to add between things.

Which is all fine. But that’s what it is going be and it is hardly an imposition. I know so many computer lanugages that switching between them (or API 1 and API 2) is no real problem. Obviously, YMMV. After 33+ years and countless languages I just deal with what is provided and get the job done.