I am trying to switch to API2 a huge project…
I am facing a HUGE problem : the compilation tells that a method doesn’t exist and the documentation tells it belongs to a deprecated item.
But nothing tells us how to replace the deprecated method.
Examples :
Type “DesktopListBox” has no member named “Selected”
if DestListe.Selected(n) then
Type “DesktopListBox” has no member named “InvalidateCell”
DestListe.InvalidateCell(DestListe.SelectedRowIndex, 0)
—> OK, but by what replacing it ?
Why not adding the replacement function name for each deprecated function ?
Yes I guess it’ll take a long time to do that, but the documentation is an important tool for us.
(I must say that the “item 1 is deprecated, You should use Item2 instead” checkbox is checked in my project)
The problem is that DesktopListBox doesnt have deprecated methods, It’s Listbox that does. So just like in any other situation where you physically change the superclass to something completely different, the APIs may not be the same.
What you can do is to type this in the code editor:
Call DestListe.
And the code editor will show you all of the methods and properties that are available on the control. Most of them have not changed very much and it’s usually pretty easy to pick out the new one.
Xojo expects users to waste countles hours/days/MONTHS changing the old names for the “new names” but they cant spend some time on at least making an entrance with the New name on the deprecated control…
My position on this (even when I was an engineer) is that you shouldn’t change an API 1 project to API 2 unless you absolutely have to for some reason. Now, that said, I also understand that the further forward we go, the more important that will be. When I write declares these days, I write them with API 2 in mind. It’s not impossible to change, but it easily makes twice as much work for me to support both, so I don’t.
And why would they? you’re already complaining that they’re wasting time in the first part above. Now you want them to waste time on adding all of the new methods to the old controls? To be honest, when they tried to change just the non-UI framework and support all of this conversion stuff, it went so badly for users, I don’t blame them for cutting the old controls loose.
But I still maintain that unless your app has a lot of life in it or there are things that you just can’t do with API 1 controls, you should leave your app in API 1. There’s no reason to go and try to change a large code base “just because”. It’s not like the old controls are going anywhere any time soon. The Xojo IDE would cease to function if they did.
Yesterday, I needed to make a change to Web Project, I opened it in the wrong Xojo IDE. Made my code changes, saved the project and went to run.
Nearly everything was deprecated. Like the OP I considered for a brief moment about potentially updating it to Web 2.0, but the IDE was incredibly unhelpful in pointing out what I needed to change things too.
After a few minutes, I gave up. This app is also mission critical, so I can’t be running into unknown Web 2.0 bugs.
It would have been nice if the IDE could have at least warned me, “This project is Web 1.0 and needs to be converted to Web 2.0 to work with this version of Xojo”. Would have saved me a lot of time, especially as I’d saved the changes, so I had to restore from a backup in order to get it to work with an older version of Xojo.
But in recent years, I’ve felt more and more than my time and effort are not a consideration.
When the time comes that I can no longer use Web 1.0, I’ll migrate it to a different tool.
Whe are talking about the docs, that is the topic of the thread.
Yes it was unpresedented that Xojo deprecated the whole control, but they should have put a little effort to add references in the deprecated control DOCUMENTATION where the Properties, Methods, Events, etc where renamed in the “new” desktop equivalent. That is what the OP means with “But nothing tells us how to replace the deprecated method.”
The IDE doesn’t help, the docs doesn’t help. It weird and unproductive to work on 2 different “apis” and there is a psicological pressure lokkinga all those warnings constantly
Humm : if it is deprecated, bugs will never be fixed and adaptation to new OS will never be done. And one day, with a new OS (macos 15 or 18, windows 14 or 32), the controls or the functions will not run.
So, with a software used by many clients, we have no choice to change or not.
This would be different if Xojo tells : “hey guys, it is not really deprecated, you can use API1 for ever”.
Yup. That’s the main reason I’m switching to API 2.
And for desktop API 2 I only have 2 words: popover windows and listboxes. Popover windows are currently not possible. I have done a lot of work with listboxes to give them a more modern look. But there are always small visual glitches.
You should approach this carefully and systematically, see (amongst others):
You have to do some research, by looking up Selected in the old Listbox docs, then looking in the DesktopListbox docs to see what has the same purpose now.
Well I never learnt how to do branches. I’d always cut the wrong side or make the rotten branch be the main one. For me, better to make two copies of the app’s source. One to apply permanent changes, the other for testing conversion ideas. The latter gets thrown away when necessary, and a new one made, cloned from the former.
This program does not directly address the two specific examples that you provided. I recognize that it is a limited tool. But I send this link because I find can occasionally be helpful in the task of converting from API 1 to 2.
