I just spent most of Sunday afternoon converting part of my current project to un-decremented commands in 2019r2. Some of it was easy and handled by global find and replace. Some was not. Processing Modbus responses now requires memory blocks rather than strings and setting parity for a serial port requires an enumeration rather than the integer I used previously. I was not impressed. Even though I could keep my old code and edit it with the new (and future) version of Xojo, I lose the AutoComplete and help for the commands I know. I know the commands to do almost everything I need and 2019r1.1 does everything I need for any project I am likely to work on. I have about half a year to go on my current Xojo subscription but probably won’t bother downloading future versions unless a lot of the issues addressed earlier in this thread are resolved. If future versions make my job easier to accomplish my goals, I will resubscribe. If not, I can live with 2019r1.1 for the rest of my programming career.
I think a lot of long time customers will look at it that way…
But you might need to have newer version - for compile only, to deal with OS changes…
Since the vast majority of the Xojo changes are just renaming (or changing indexes ) any updates they do to deal with OS changes should work equally well with API 1.0 code (and needs to since the IDE will have a lot of API 1.0 code for a long time)…
But unless things change, just don’t edit and save your projects in the newer IDEs or you won’t be able to go back.
- Karen
I got help from API 2.0.
It makes me push my efforts to go to another technology and not always use the one that seems the easiest.
It’s great and very simple how MBS put LibXL into Xojo; but I can bind with another technic to C/C++ and still use it from there.
But with Aloe Express (to be clear -> great help), I see what it means to not have a robust, wide spread base.
Microsoft will have done it’s .Net Core in end of 2020 and then, You’ll don’t know what crazy things they plan next…
Win32 -> am I the only who has noticed that HTML/JS/CSS has won???
“open” gets “opening”… wow!
At the end I must see how I can use the MBS things in another way than for Xojo maybe by using the C libs directly.
The add-ons are what brings Xojo to live.
[quote=458034:@Dave S]Perhaps 2019r2.1 could add
- Option - do NOT show API2.0 deprecations when doing an Analyze Project
- Option - disable Autocomplete of API2.0 items
At least this way a developer could continue in the API1.0 world without having to wade thru tons of messages they KNOW they don’t care about in the moment[/quote]
Do you have a Feedback request for this? Willing to upvote
No, but please feel free to submit one.
Feedback and I have never gotten along, and I just quit wasting my time trying to deal with it.
<https://xojo.com/issue/57885> A per project setting: API 2 | 2+1 | 1
<https://xojo.com/issue/56856> IDE: Make Output of ‘Analyze Project’ useful to get an overview and allow to drill down
@Greg O’Lone “every Xojo engineer has the same 20+ year muscle-memory issue that everyone is talking about and we still think API 2 is a good idea”
Yet there are so many important things to fix in Xojo. Do you really think that the API 2.0 was a priority?
yet the FORD engineers thought the EDSEL was a good idea once upon a time 
I think all the benefits of API 2 are currently not apparent… but in the long term it will be the basis for a much more consistent framework for all the platforms. I assume Android will be entirely based on it and that iOS will soon move there also.
My only complaint is the renaming of the events… I can see why it was done but the downside was not worth it.
Dave… do not blame the Edsel on the engineers… The car was in fact way ahead of its time… Blame the styling and the marketing. And never name a car after your father.
Yeah… my fathers name was RICHARD
and API2 may “be ahead of its time”… but I am blaming the “style”
if the ONLY thing that was not done was the event renaming EVERYTHING else could be handle using
#if XojoVersion
#else
#endifuntil/unless we can / could handle the event renames the same way it should have been avoided as now it can silently break third party code or your own code
but … it wasnt 
I agree with this. I tried to be a good boy and use the new framework as much as possible, but then found that Text was slow under some conditions. The major frustration for me was having to mix the two frameworks and keep converting my data so I could use a number of important methods which had no Text equivalent. I’m moving entirely back to String now.
I have a suggestion that will address some of this:
https://forum.xojo.com/56367-suggest-api-1-0-deemphasized-instead-of-deprecated
Dad joke incoming… Well, sometimes that sort of thing works out 
When folks say that they are not going to buy another copy of Xojo until such and such is fixed, it reminds me of the reaction of a politician to a member of a hostile audience who pips up, “I am fed up with politics and lazy politicians. That is why I never bother to waste my time voting.”
The politician (in his mind) can be forgiven for thinking “Is this the constituent that I am going to focus on?”
Or the captain of a 19th century sailing ship complaining about sluggishly performing sailors. “Reduce their rations until they start working harder”.
Progress in the development of programming languages is difficult and always accompanied by the gnashing of teeth. The jump from Python 2 to Python 3 dragged out much longer than was hoped. But you have got to do something.
“I think a relationship is like a shark. It has to constantly move forward or it dies.” – Woody Allen. You could make the same remark about a programming language.
But developer’s have to have really thick skins. Guido van Rossum is the author of the Python programming language, for which he was the “Benevolent dictator for life”, until he stepped down last summer. He was generally respected and liked by the community. He had a lot to be proud of and had gotten a lot of recognition. But harsh, endless criticism can be exhausting. He cited acrimony over a recent Python enhancement proposal for a language expressions capability as motivating his exit.
The kerfuffle about this Python proposal, when weighed against the overall success of Python, seems so minor, but people can get really pissed about changes that they do not want or changes that were not the changes they would have made. Perversely, the more they like/love something, the greater the anger engendered. It got very heated.
Many people find it tiring to be the targets for this sort of thing.
[quote=458272:@Norman Palardy]#if XojoVersion
#else
#endif[/quote]
I think the goal was to be coding faster, not slower (much slower).
Robert? I am not really sure what you are trying to say here.
Are you inferring that we (as developers) are obligated to accept what many (myself included) consider unnecessary changes, changes that cause hours worth of non-productive work to move an existing project forward, while hoping that other errors are not encountered due to the required changes in syntax, not to mention bugs that may exist under the hood and are as yet unseen? That we should continue to pay our annual subscription (be it $99, $299 or more?), when that product is considered (by seemingly many) to be a worse offering than “the new framework” was? That we should not voice our concerns and displeasure with the direction our toolset is taking? That we should just say “oh well”, smile and carry on.?
Sorry… if that is what you are inferring, then do so be my guest and “carry on”… But unless and until the vast majority of these “improvements” are either removed, or an option is provided to silence the “deprecation” warning so API1.0 can live on quietly… well…
I have a project that runs just fine… but R2 throws 1832 deprecations… making it near impossible to find anything that I NEED to care about. (and this is by no means a “large” project)
Dave,
I do think that you should continue to pay your annual subscription.
Constructive criticisms and suggestions are fine.
I don’t speak for @Robert Livingston , but I certainly didn’t get that message from what he wrote. I think he’s just saying the change is painful, not only for the recipients but also the implementers. And that we all have choices available to us, to either walk away or not.
Talk about painful, I started my programming career on a proprietary language where the vendor went right out of business, but only after I spent years establishing myself as an “expert”. Based on that experience, I thought I’d bank on a sure thing and go Microsoft, only to be stung by having them deprecate a technology recently where I’ve spent the last 15 years building some pretty huge applications. Am I going to rewrite all that on their new platform? Decisions still pending…
Do I like API 2.0? You bet I do. It much more closely conforms to naming and behavior (Exceptions) standards of other modern languages and Xojo is still in business. Plus I like how much more straight forward the Xojo platform is compared to other ecosystems. It’s not a pretty picture out there, especially at this point in time, for any vendor.
From my point of view, in this industry, there are no safe bets - there never was. But having a thick skin is essential to longevity, for both us developers and the vendors.
Keep up the good work Team Xojo!