I’m considering the possibility to convert some my huge projects to API 2, and I give it a look this morning.
The first impression was “ok, I can do that” because after the project conversion there was only 160 errors. After fixed those, “Oh my GOD”… 4500 errors!
So that project has a lot of procedures, classes, windows… shared with other projects constantly in progress, so I roll back to the last backup (two hours before) and think “let’s ask on the forum”…
Here the question: Will converting to API 2 be mandatory in the near future? Does it make sense to spend tens of hours doing this work, or will API 1 remain available for many years?
Obviously every new project I start will already start with API 2 … but the ones in progress are important and I can’t spend that much time converting them …
In my humble opinion, converting a big project to API 2.00 makes little sense. If it ain’t broken, don’t fix it. Xojo stated that they will keep API 1.00 alive “for a long time”. So your project should do fine under coming versions of Xojo.
Personally, while i use the latest version of Xojo for my Mac apps, I did not convert projects I spent months if not years creating and maintaining. I don’t see any benefit in spending a month or so updating to API 2.00.
I recently upgraded RubberViews to support API 2.00, so I did go through the process. It is not as painful as it seems, since most of the errors are due to the rather pedantic new way of naming event handlers and properties. Like “Var” instead of “Dim”, “messagebox” instead of “msgbox”, “pressed” instead of “action”, “opening” instead of “open” and so on. More annoying than anything. It can be done indeed, but in the end, the program will do strictly the same.
Now that I am familiar with the new syntax, I may use API 2.00 for a new project, though.
For Windows, since the fated switch to Direct2D and the abandonment of true transparency, I am still using 2016R3, and have no intention whatsoever to upgrade in the near future. I was not broken, but Xojo decided to break the camel back. Besides, VS still sports true transparency. So if for some reason I needed to switch to another environment, it is there.
I converted my major application in about 2 days. Sometimes the large number of errors are easy to fix. For example a simple find and replace can cure 100s of them in one go. Other things, such as swapping from InStr( String, value ) to String.IndexOf take a lot more thinking about.
I found that changing each window in turn worked a lot better than trying to do the entire application. Converting the application caused problems with MacOSLib, which I like it. Once I had done all of the windows I did modify some of MacOSLib to change the likes of handle to integer for window references.
I also converted mine in about a weekend. My main goal originally was to help Xojo uncover bugs during the beta process, and I’m glad I did, because I found quite a few. I figured the new API needed a real-world test.
The conversion was pretty painless, but there are some things like changing InStr for IndexOf that need to be paid special attention to. I think the biggest frustration was trying to convert something like Str(Value + 1) since there’s no way to do (Value + 1).ToString. Having to add a temporary variable for the conversion is… annoying, to put it nicely.
At this point, I like converting the projects I work on because I’ve become familiar with the “new” way of doing things, but there’s not inherently one better than the other. If you want to switch, switch. If you don’t, then don’t. And I think that really demonstrates the biggest problem with API2. All of us are saying there’s not really a reason to make the switch, so what purpose does API2 have to exist?
The Xojo IDE and many internal projects are written in Xojo.
Rewriting the IDE and internal code base and then verifying that nothing has changed would take years, if not decades.
With that in mind, you shouldn’t worry about leaving old projects in the API 1 format. The only real reason to upgrade would be if Xojo fixes something only in the new framework that you need.
I just issued an update to a several year old iOS app. Only had 4 errors (a property name became a reserved word) when I tried to Run it. Made the changes using API 2 and submitted it. Good enough.
How do the Xojo people write code without autocomplete? That alone drives me bonkers. Or is there a secret setting to get autocomplete working for API1?
I think I’ll follow your suggestion and when I’ll have 2/3 days I’ll give a look more deep. May be I was screamed when the debugger said more 4000 errors!
I ever wanted to be updated because I want my projects works fine on newer devices, and (first of all) I don’t want that, in a future day, one of my projects can’t compile because of deprecations.
Anyway, I don’t know what is the benefit to change an event from “open” to “opening”, and other very similar…
So, thanks to you all for the answers and opinions!
Yeah, it’s a tough call. I always recommend people handle their deprecations sooner rather than later, because you never know when a change - possibly not by Xojo - will bite you. Better to update the code on your terms than risk scrambling later.
BUT in the case of API2 it’s hard to treat these changes the same as a regular deprecation. There’s no indication that Xojo will stop maintaining the API1 stuff, so is the code really deprecated?