I’m taking the time to future-proof my app a little by converting the UI elements to API 2. Since it’s a big job, I’d rather get it out of the way now instead of when I’m trying to actually use a new feature, such as if we ever get windows popovers.
Just felt like sharing some infuriating results. The process seems to “randomly” mess up a handful of properties. Font, alignment, text, hint, and listbox has header seem to be the candidates for random nuking. For example, here’s a before and after shot. All the labels are the same super, as are all the text fields.
Yeah that’s most likely because they changed property names too. It’s a mess but we’ve seem to get it to work after 16500 compile errors there where only about 150 to fix (including the layout issues) so it looks worse than it is. Well it could be different cases, it’s still more work than it should have been.
I found that I got much better results by converting each window one by one, rather that trying to adjust an entire project in one go. I don’t recall having such issues, but it was a while ago.
One issue I did run into was with this approach was menus. You cannot have an API 1 menu on an API 2 window, and vice versa.
Without knowing a lot more about your application I can’t really hazard a guess. Are you for example using subclassed controls. Perhaps it is related to that in some fashion?
Many are, but there’s no pattern. Like I mentioned, every label and every field in the screenshots are the same subclasses of label and textfield, respectively. If I could find a pattern, I could hazard a guess what is going on, but this seems almost random.
I will say it feels like older controls were more prone to problems than newer ones. For example in these screenshots the bottom three fields are the newest. So the newer ones had their captions reset, older ones had their alignments reset. In this case only though, I still couldn’t find a pattern through the rest of the app.
I have a program that runs schedules of employees and I did window by window at first and finally did all the entire project because of the menu bar.
For that program, I had 2023 errors and 3400 deprecated items that have a replacement .
Two weeks after, I have now 0 errors and 1434 deprecated items. I have to admit that I prefer the api 2.0 spelling because it is easier for me to remember it since I don’t program everyday (my first job is pharmacist).
The other thing that it did good for me was the code refactoring that I did in the same time since I had to go in every method to correct items. So basically, I find the change to API 2.0 positive.
I see a lot of negative comments on the new API 2.0 and I can understand the frustration of some people that use Xojo every day. I can only say to those that in my first domain Pharmacy, a lot of changes have been happening and the tools that I use today to practice are in constant evolution and are in no way comparable to those I used 30 years ago. The law of Pharmacy here in the province of Québec are changing constantly and we have to adapt and sometimes it is very upsetting. I would’t go back to my practice 30 years ago.
I guess what I’m trying to say is that I view as a good thing that Xojo evolves even with the frustation that goes with it.
I think it’s fine. I’d be more happy to make the conversion if we actually gained something from it, but right now we don’t gain anything at all. Maybe some features in the future, but for now… zilch.
Oh. Yeah, sorry there’s a separation of API 2 framework vs API 2 controls. I switched to the API 2 framework during the beta period to help them work out the kinks. I have held off on doing the API 2 controls because Geoff told us there was no reason to make the switch. But I know there is stuff on the horizon and I’d rather get it done sooner rather than later. So when I said no benefit, I meant about the controls.
