I have a fairly large project (>100MB Binary) which I have converted some parts to API 2.0 (RowSet, Arrays, DateTime…), but have stopped at the UI. I attempted it a couple of times, but it looked an almost impossible task.
I’ve always had the concern that I’m working in borrowed time and I will need to change the UI some day before any of the controls I am using becomes deprecated.
Does anyone have any advice on how best to approach this (I’m hoping no one mentions eating elephants :-D)
There is no need to use the Desktop-prefixed-framework unless you have a need for one of the controls only provided there. Xojo themselves haven’t been proud enough of the renaming to announce that they’ve gone updated the IDE to use it.
Until they do, I have no fear that the normal control names will go away. I also hold very little value in the name changes.
Want and actually doing it are not the same. I’ve heard estimates from former Xojo employees where they believe it would take several years to convert the IDE to be fully API 2.0 compliant. They may already be in the process of converting the IDE for API 2.0 but I would not be in a hurry to do so myself as it’s a lot of work with very large projects. Not to mention there are several replacement API’s that are most definitely not the global search and replace type due to 1 vs 0 difference.
My approach was one replacement at a time, meaning “Okay this time we’re updating Ubound to LastIndex”. That made it so when it came time for the 0/1 changes, everything I needed to change would also need the value reviewed for change.
I was lucky because I was trained to use a reliable naming scheme (and thanks to OCD it really stuck). This meant I could use RegEx to perform many of the changes necessary.
Yeah, 1 vs 0 was a bit of a nightmare (well I had nightmares while I was doing it!), but I think I have that all done now - I can’t recall any UI that was base 1 in 1.0.
I hear what ye’re saying and thanks for the feedback. It still is a lot of work alright. I think when I changed the Menubar from API 1 to 2 (which you have to do to change to a DesktopWindow and the you have to change to the DesktopApp), there were over 100,000 bugs listed
I converted my main app some years ago. It took a few days and I wrote it up here:
The main thing is to be careful and systematic and take it bit by bit. DO NOT just select the menu option “Convert tthis project to API2”. Work from the bottom up. A project can perfectly well be a mixtture of API 1 and API2. Do you use any Text or Xojo.xxx stuff? I dumped all that even earlier than API2 appearing. If you do, you might want to convert that first.
Tim, Thanks! That’s exactly the type of advice I was looking for. I’d like to think it will only take a few days for me! Maybe I’ll order in less Guinness for Paddy’s day and make a long weekend of it
The only really “Big” issue I would say is going to Desktop. That you really have to do all at once and if you do it.
And it can get really bad.
Rest, syntax changes like Dim / Var , Ubound / LastIndex, those all are minor thing you can do over time at any pace you choose.
Its the Desktop mess that is the Elephant in the room. I converted 2 relatively small applications and it was absolutely terrible to say the least. And the benefit was of course zero except for the sake of staying up to date.
Depending on how your Application is structured as in if Windows are well separated from code then if you possibly can pull out Window one by one to separate project and work on them there in smaller units then that helps. (I know most projects do not have that good separation where that is possible though)
Thanks Julia. I have them all done and they weren’t so bad as long as you kept your coffee intake up When I say UI I more or less mean anything that now has the word “DeskTop” in its name.
Thanks Björn. Yes, that’s exactly the point where I have stopped and wondering if I should not take the plunge as looks like it might be like climbing Mount Everest blindfolded. It the day or so I spent seeing what it might be like, most windows ended up with classes represented as unusable invisible squares, so there would need to be a plan of order related to dependencies and I expect not having the “luxury” of being able to run the project until every one of the 100,000 bugs are resolved (not to say a change somewhere wouldn’t half this number or make it worse).
I think the only thing I can do is using some of Tim’s insight and blocking off a week to see how far I get.
Thanks Arnaud. Thankfully I steered clear of all that is only Apple when I could as I needed cross-platform. At least that will be one avoided headache
There has been a bug in the Xojo Windows framework since the switch to Direct2D which causes controls to redraw at unexpected times. This causes all sorts of problems when trying to move several controls at once (ie: via a splitter). This is one of the several issues which prevents us upgrading our main application past Xojo 2014.
I was promised that it would be fixed and changes were made but only for Desktop windows / controls. Apparently, fixing a bug was a change in functionality so they wouldn’t apply the fix to the original controls.
I did a trial upgrade of our project by manually changing the relevant parts but soon found out that we couldn’t restrict the conversion to certain classes because the window in question relied on container controls, canvas controls + other stuff which also had to be converted to enable the fix. This then meant that other windows using the same controls / code also had to be converted. In the end, I did get the project to compile but it was in such a mess that it would not be feasible to work on afterwards.
Wow, and I thought my 20,000+ errors was large!
I did a talk at a Xojo conference on this and provided a spreadsheet showing the API 1.0 commands and their API 2.0 equivalents. I suggested testing your weird code and objects to ensure API 2 was actually possible, backing up you API 1.0 project in case you ever need to through the changes out and revert, backup every few hours since you’ll be doing mass Find/Replace and losing an hour and re-opening a backup is faster than undoing a change, proceed function by function, not window by window, as it’s easy to change all 1-based functions to 0-based in one go than remembering how they operate later and maybe missing one. Document each change type so you can replicate the changes consistently. Remember that Desktop can cope with API 1.0 and 2.0, Web 2.0 is mainly API 2.0, but iOS is strictly API 2.0, so if you have any cross-platform code it will pay to make it strictly API 2.0 now.
Every couple of months I try to work on the conversion to Desktop API2. I convert my project, note down some changes and then wrap the changes with a global. This way I can go back to my original project but still make some progress over these unnecessary changes:
#if Globals.UseAPI2 then
self.Show(ShowAboveWindow)
#Else
self.ShowWithin(ShowAboveWindow)
#EndIf
Thanks Beatrix. Sorry for my stupidity, but I thought it wasn’t possible to mix API 1 & 2 when it came to windows - I thought you needed a DesktopApplication and API Menu 2.0 to use DeskTopWindows.
Am I wrong? It would be terrific if I could introduce as I needed it. It would mean I could still continue adding features as requested.
