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.
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.
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.
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.