That’s a different debate Dale. The question was, why is the OP forced to change code in r2, and the answer with the examples given is, you’re not.
99% of the old stuff will be there in 10 years
I will be using Dim because I type that faster
View>Hide Toolbar
UBound literally means nothing to a new coder where as LastRowIndex is self explanatory
I understand the changes, I like the direction and new features of 2019r2, it’s implementation was just a bit… rushed, seemingly to align with a certain time/release schedule so I’ll see how it ends up over the next 1-2 updates. As it stands right now, I wouldn’t be moving any projects to it though due to a few major bugs that are due to be fixed in r2.1. How long that takes will determine how far the train ends up from the tracks and how much work is needed to get it back on track.
I’d like to be accurate about how we talk about this. LastRowIndex is not a change, it’s an addition. Nobody has to be use it, now and probably ever. This is opposed to, for example, event names which is a true change.
You don’t HAVE to use the new event names either
Except in a project started in 2019r2 since it hides the old ones
The difficulty comes when or if you use both
I’ve watched this discussion from the sidelines.
What I hear makes me worried about API2 and worried about upgrading.
I can handle the changes - eventually - but there is nothing about them that makes me feel API2 is somehow better and a reason to upgrade. Quite the opposite.
I get that many of the changes are additions,
and we don’t have to use them.
It’s like needing new tyres on a car, but you decide to install some fluffy dice instead.
I can’t be alone in wishing the language had been left alone, and some new controls appeared, or more substantial work was done on iOS.
Right now, my main concern is : what about changing the index of strings?
Haven’t they switched to a zero base?
So if “You don’t have to rewrite a single line…” won’t that immediately hard break any app of a decent size that uses INSTR and MID ?
Won’t it immediately make for off-by-one errors?
[quote=462292:@Jeff Tullin]So if “You don’t have to rewrite a single line…” won’t that immediately hard break any app of a decent size that uses INSTR and MID ?
Won’t it immediately make for off-by-one errors?[/quote]
No… as everything from API1 still works… its just that API2 will tell you about it everything your analyze
To build on that with an example, InStr is 1 based as always, but now there is a new IndexOf which is zero-based. Mid is 1 based, as always, but now there is a new Middle which is zero-based. If you do a search and replace of “.InStr” to “.IndexOf”, yes, you will break your app. So don’t do that. 
While I can’t speak for other companies, that is NEVER the goal at Xojo, Inc.
I’ve spent the last few weeks updating my primary projects to API 2.0. Naturally, these were copies.
While I like much of what is here, certainly there were some frustrations. The transitions from Instr and Mid are already mentioned–I was VERY careful with those once I understood the implications, and some of the event renaming seems less than necessary.
Overall, though, I’m a glass-half-full kind of guy. A side benefit to this project was that I wound up doing considerable refactoring, reducing the spaghetti quotient. In this vein the new Thread.AddUserInterfaceUpdate really helped reduce the pasta, as I was able to eliminate several timers and the properties that supported them.
If LastRowIndex was truly seen by Xojo Inc as an addition and not a replacement, Ubound would not have been deprecated… That means Xojo inc would strongly prefer we not use it NOW, and it theoretically could disappear in any future release (well any after at least 1 year)…
While I realize that is not likely anytime soon, if one is writing code one expects to need to maintain for the long term, one has to take deprecations seriously… While not actually forcing the change NOW, deprecation is rather strong coercion to do so… Ignoring deprecations is sort like having an overdue loan from a loan shark! You never know when you will get a “Candygram”… Oh never mind, CandyGrams are from Land Sharks not Loan Sharks! 
(to mix skits)
BTW using row terminology for arrays STILL really grates on me… it is IMO so obviously conceptually wrong for arrays!
- Karen
Mongo likes Candygram…
They might have rewritten Xojo for beginners only without using a documentation
Thank you all for making me feel so young. At 60 I can still embrace change, but please don’t bring back the data division of Cobol that really sucked.
To me API2 is a welcome refresh and shines a light on an awesome future for the product.
Terminology also changes. Most of the people I deal with have used this little thing called a spreadsheet before citizen coders existed and guess what a row is a row not a record, they don’t append a record they add a row and that carries through to an array or now a table.
Those of you that don’t want change, just keep with your old versions & don’t complain, us young fellas will carry on with the good stuff!
Wayne, you’re right. But it’s frustrating to keep an old Xojo version for someone who paid for the upgrade. If Xojo told people some months ago that a future update will come with a lot of work in the code people would have think twice before renew license.
I personnaly would have hesitated, but renew anyway.
You are not forced, for now. But in few releases you won’t be able to use them anymore.
This was not the question. The question related to all releases. And what you don’t need to rewrite now surely you will have to do in some future version. As has happened in the past.
When my development platform says “deprecated” it scares me. It gives me the idea that I have to rewrite the code or soon in future releases it won’t work anymore.
Maybe they are trying to change the programming language, to replace Basic? I hope the change is due to future compatibility on Android.
Because, until there isn’t a release that will allow me to create App for Andoid, I don’t need to update Xojo, and its license.
I got a phone call from a company yesterday and they ask me my developing environment. They answer Xo what ? and I answered a Visual BASIC competitor, but this was a bad answer.
On the other hand, there are nowadays so many different software to build applications / so few time to explain. Ive made a bunch of demo applications and I sent links to prospect companies, but apparently, they never download them to watch them. (they probably trust the resume).
It is at the foot of the wall that we see the mason … (bricklayer)
One question remains: wheres the wall, and I think this was deprecated long ago.
I understand that, and that’s why “deprecated” was … shall we say, not the best choice for API 1.0 calls. But this is merely a fear with no basis in Xojo’s history. Other than changes dictated by evolving OS’s, we haven’t had to do more than make some fairly minor (in the general scheme of things) modifications over the years. I have projects started for OS 9 (!) that haven’t needed much change. Heck, I can still use #if TargetPowerPC..., and that hasn’t been relevant in, what, fifteen years?
This is, frankly, not a concern, despite the “deprecated” label.
What you should have said is “A modern, object oriented, multi-platform development language”. They push you for the language, just say that it’s a “highly modernized BASIC variant”.
If you say “Visual Basic” to many potential customers in-the-know, you’ve already lost the war. How you present something is, in many cases, more important than what you are actually presenting.