I long ago gave up on Xojo fixing this bug and made a Keyboard Maestro macro to fix it. Basically, my macro is triggered by typing Shift-9 the ( character and executes three keystrokes in succession: Shift-9, left arrow, right arrow. It executes so quickly it’s impossible to even tell it happened but it causes Xojo to show the syntax help.
The syntax help tips werent themselves very help ful because of the way params used to be named
Everything was “index”
I changed a bunch to say “zeroBasedIndex” so that one little thing would twig that it was a zero based call
And where they were 1 based they said “oneBasedIndex”
Xojo 2019 R2, I mean API 2.0, Review
"The fact is if I use API 2.0 it won’t improve my software and at the end of the day that is what creates Xojo renewals. Did my software just get a little bit better because I upgraded Xojo? Sadly, when it comes to R2, it does not. "
I would encourage the Xojo team to read all the blogs been written about R2, conduct a substantive discussion about R2 internally and reconsider the next steps to be taken in order to accommodate us.
To quote one sentence from Phillip’s blog:
"When you create a project, it should ask you “API v1 or API v2” and that’s it. "
Such a “per Project API Switch” has been suggested again and again during the Betas… and it always got turned down.
Let’s hope Xojo will at least listen to to “public comments/reviews” about their product… they could have prevented much of this public noise since we all have mentioned these (productivity and other) issues during the long Beta…
[quote=458175:@Jürg Otter]Such a “per Project API Switch” has been suggested again and again during the Betas… and it always got turned down.
Let’s hope Xojo will at least listen to to “public comments/reviews” about their product… they could have prevented much of this public noise since we all have mentioned these (productivity and other) issues during the long Beta…[/quote]
This might not be option for them, I am guessing the design is far off from being able to separate frameworks so you can choose.
Here in NL we have a saying which is translated to English something like this: “better half turned than completely wandered”
Its not much different from “do you want to build a desktop app, web app, console app or iOS app” which also use different frameworks
I suggest we launch a referendum and the result is what needs to be done.
I vote: YES
That means: someone needs to add a new Feature Request for such an “API 1 | 2 | 1+2” per Project Switch/Option (or is there already an “official/public one”?).
If it goes into the Top 20/10, Xojo will have to to at least reconsider in more detail the user’s needs.
I’d certainly add points to it…
Edit: Here you are: <https://xojo.com/issue/57885>
I have no idea what the internals would require, but I’ll point out that you cannot switch, for example, a desktop app to a web app, or a console app to a desktop app.
Here you are: <https://xojo.com/issue/57885> A per project setting: API 2 | 2+1 | 1
Please add your thought on what is needed/important to you…
The manifests are obviously different
Thats one big impediment
Compatibility flags could be used to take care of much of the rest
Tim Dietrich also wrote about Xojo 2019r2: Xojo in 2019: An Update
Again, a sad story. We may lose a genius, which Tim really is.
@Bob Keeney Thank you for that review. As I am not part of beta-develoment, I had no idea about what API 2.0 was. Now I do and I hate it already! It is so unnecessary when hundreds of important bugs have been ignored by Xojo for YEARS !
It is really beyond my understanding!
Appreciate the effort the team put into R2. I am flexible enough to adapt.
I’m guessing you don’t have a million lines of API 1.0-based code to manage…
I have a suggestion that will address some of this:
So do I.
Most likely, we do.
And while I appreciate the start and idea of API 2, I consider this just a start. And hope Xojo will provide us further improvements to continue working with an existing codebase. On the one hand to continue with API 1 only (and get less “fuss” about what’s not intended to use right now), on the other hand to better get an overview (improve Analyze Output) and provide safe migration helpers (e.g. select a whole “issue-block” such as
Label.Value, which will replace all at once as long as it’s safe - that’s what a global search&replace can’t guarantee).
Feature Requests for all that are in place… let’s see how much more productivity (and also “code safety”) the next release will bring for those with existing codebases.
Currently, it’s all nice and good for new projects or newly created code. So a good start. But having more productive ways for existing customers/projects/codebases is missing - which doesn’t mean we won’t get that ever. So I continue appreciating API 2. But won’t use it for now myself. I wait a bit more to see what works and what no longer works, and until there are new features allowing to continue working productively with our projects.