For DesktopAPI 1 the global UseAPI2 is set to false so the old code is executed. After converting the project to DesktopAPI 2 the global is set to true so that the new code is executed. Of course, I can’t fix the window and menuitem problems with this method. But I can prepare the small things like Show vs. ShowWithin.
1 Like
This is why I said it may be necessary to make a class have an API1 version and an API2 version, temporarily (with NEW or something added to the name, obviously). Once the old class is no longer used, remove it and make a global name change to the new class. Xojo’s search feature was a great help in this regard. This prevents looped dependencies which can involve making the change in a large number of places ALL AT ONCE.
It is important to avoid these loops (and you may have to sit down away from your computer with a bit of paper and work out what these are). Then mitigate them so you can continue to proceed stepwise.
1 Like
No, As far as I know mixing is entirely possible, except perhaps for the app’s main menubar.
1 Like
This would make such a difference. I’m going to try attacking this in the next week or two and let ye know how much I’ve aged when I’m either done or I quit 
Thanks for all of your help and advice
Having 2 versions of everything would not make the transition any easier.
I didn’t say you have two versions of everything. I said you make two versions TEMPORARILY in order to get round the problem that you may have a class or method that is API1 and that gets used everywhere. You make a second version for only as long as you haven’t finished all conversions that involve it.
I use IMSplitter to have splitter bars in the app. Each splitter has an array of controls whose height/width needs changing when the splitter bar is moved. But IMSplitter’s code to effect this is (now) full of:
if (me.CtrlArrayAfter(i) IsA DesktopUIControl) Then
where previously it would have been something other than DesktopUIControl (I forget what, now). So I just duplicated the code there, so it would work with either API1 or API2 controls. That seems quite simple to me and I removed the now-obsolete code at the end.
For an app of any size, making this change requires care, planning, and attention to detail. If you go at it like a bull in a china shop, then of course your Ming vase will be reduced to atoms.
1 Like
Xojo provide a few Menus to update ui to api 2 which save alot of time.
if your app have a wide userbase you have test the whole program or give a few
a test release.
To be fair to Xojo, what you are talking about may not be possible (I’ll be happy if they proved me wrong). The problem is that they’d make a branch and have to dedicate someone to this task for the foreseeable future, likely the person who has the most IDE maintenance experience, and periodically you’d have to merge from the development trunk and just about everything would require changes. Regardless of whether they are modifying or rewriting the IDE from scratch, I would expect this process to take 2-4 years.
It would mean having two versions of several complex canvas controls and complex container controls along with other code. Both versions would have to be maintained for a significant period of time as there is no way we can perform the conversion in one hit.
Isn’t this a proof that the API2 change was a mistake? That some projects can’t be moved to the new “technology”?
6 Likes
If you could only write in api2 then yes, but Xojo made it possible to continue using api 1 on desktop projects.
1 Like
In this case, Xojo will have to support API1 and API2 “forever”. A waste of resources, IMO.
5 Likes
Nope. They’ve already started doing ‘API2’ only fixes.
2 Likes
Not only that, but they do whatever they can to “force” the users to follow API2 rules…
Save, AutoComplete, Picture, DesktopXxxYyy, Language Reference (I cannot complete this list because I nearly stopped using it because of these…).
It is a challenge to not use API2 (with time) when you add code and need to use Language Reference…
And when your Intel MacOS computer dies… (Spanish terms to add).
1 Like
Assuming it’s possible to work on API 1 projects in the current version of Xojo, what precautions (apart from backing up) need to be taken to ensure that one’s project gets saved as API 1 and doesn’t end up in a fubarred state?
Some of the reported recent speed improvements are enticing, but there just isn’t time to attempt conversion of my existing suite of apps to API 2 for dubious benefits.
1 Like
Well, for those projects that will remain strictly on API 1 this is what we are doing:
- Project get edited, worked on and saved in a Xojo Version that’s pre API 2
- Newest Xojo Versions are used for “load & build only” (e.g. only use a newer XojoVersion for macOS, because of Universal support and the speed improvements, but compile for Windows with older Xojo Version)
- or load the project for debugging purpose; however fix/save in the older XojoVersion which the project is maintained with
1 Like
That’s what I do now - 2021r2.1 supports API 2 syntax but is the last version before the “DesktopXXX” madness. But that means I don’t benefit from subsequent speed improvements in Xojo opening time, plugin loading time, compilation time, etc. 
Yeah, just not worth it.
1 Like
yeah. I’m not alone in working in an old version, and compiling in the new.
If you save in the new and open in the old, control properties are changed, even if the code hasnt been.
2 Likes
I just opened a Desktop project created in Xojo 2018r3 that I haven’t touched since 2019 (opened with Xojo 2023r4), the result is that any new Window that I add is a regular Window and not a DesktopWindow.
Any control that I add to a Window is a regular control (for example TextField) and not DesktopTextField.
The Library doesn’t offer the new Charts as those are DesktopX only (for example).
If you can use version control, you can see the changes after you save with newer Xojo. You then can know if your project can be opened in previous version (if needed) but you may not need to do that if you just need to continue using API1 and non-Desktop controls.
Note: I said maybe because I don’t use Xojo Desktop much so I’m not sure.
1 Like
I tested tonight to port a project.
I took my documentation tools and ported to DesktopControls. This is fairly big project.
I was curious to know how long it would take me now that I know most of the cases and how to deal with them. (As opposed when I did it last time).
It took 2 and half hours to get it running as Desktop project with only DesktopControls.
I have of course not done full Api2 thing but after doing the Desktop port the rest can be done slowly over time by using Analyze project and walk through the warnings.
I would say this took quite a bit less time than in my previous ports. Which is maybe due to different project partially, and for sure also because of knowing the cases and what to do on them.
This is project with a lot of plugin controls which Xojo does not auto convert the events for or non desktop to desktop.
3 Likes