I have a very old application that needs to be updated from Realbasic 5.5.5. It runs key aspects of my business and unfortunately the code hasn’t been touched since 2005ish. Currently I have to run Mac OS X 10.6 inside Parallels, but that won’t be an option eventually with m1 Macs.
My question is what is the minimum version of REAL or Xojo that works in and can compile for Catalina? Eventually I’ll get the code up to current, but for now I’m trying to avoid as many depreciations as possible…
If you want Retina support, you’ll need at least 2016r1
Catalina+ is pure 64 bit, the first said more stable and fully qualified for the job that I do remember was 2019 3.2
If the program is that important to your business, I suggest you bite the bullet and bring it all the way up to date with the current operating system and the current version of Xojo. The effort required to bring RB 5 code up to snuff with Xojo 2016 (for example) is much larger than getting Xojo 2016 code up to date; you may as well make the investment now, because you’ll just end up in this situation again in a few years.
I don’t agree with that what you say about the amount of work comparison… Fro me at least there have always only bene relatively minor codes changes needed to update od tha old… UNTIL API 2 can along…
Going from 5.5 to 2016 is IMO opinion a piece of cake compared to going from 5.5 (or 2016!) to any API 2 version…
I’m not saying he should not bring it up to date… he probably should… but please don’t trivialize the difference API 2 makes to bringing old API 1 “up to date” compared to doing that pre API 2.
The change in index bases alone can introduce subtle bugs if you don’t get it all right.
-Karen (who came in at RB 3.0)
You’re right. I had forgotten about API2. However, API1 still works in the current version, right? Perhaps I should say that he should work to get his project running on the current version of the compiler, even if he doesn’t upgrade the code to API2.
That said, he is going to need to do it at some point. At a minimum he should start making plans.
(Eric - started using RB at version 2 )
It’s been awhile since I updated a RB 5.5 project, but let me address the basic question (pardon the pun).
I found that one of the key differences was in the project format. The layering was substantively different between versions; or perhaps, there were versions in which the layering shifted enough that GUI elements that had been on top found their way towards the bottom or ended up on it. I, therefore, ended up updating the RB 5.5 project to RS 2012 and then RS 2012 to Xojo 2019.
Occasionally, I had to open the RB 5.5 project in a version of REAL Studio between RS 2012 and RB 5.5 and fix it there because a class had been substantively modified or dropped altogether that it wouldn’t compile properly. Then I had to open the fixed version in a later version in a yet later version. As for the language, it was fairly unchanged. It was mostly changes in the layering and classes that tripped me up.
Mind you, they aren’t insurmountable, rather things are done differently through time, and I had to recode those things. Things like the database engines have changed significantly since RB 5.5.
As I wrote, it’s been awhile since I last updated a RB 5.5 project, so some details are fading. But I’m mostly a hobbyist. I find having some familiarity with programming and other computer development software helps in my job as a library systems manager.
Hope that helps.
– Charles (and I’ve had it since CrossBasic).
Thanks to everyone for their input, and sorry for the slow reply. Holidays and then a busy season of work where I can’t code…
I agree that I’d like to eventually get everything fully modern. That said, I’m a one man coding team and also own the business, so there isn’t a lot of much time for fun things. I’m hoping to get things to a bare minimum first and then tackle the rest as time permits.
My biggest current problem is that database connectivity is relying on a no longer supported plugin: pgSQL4rb. Even worse, it’s version 1.x which has some portions that rely on EditFields. I haven’t come up with a smooth way to work around that. The classes are encrypted, so I can’t get into them to change the calls to TextField/Areas. Casting a TextArea to an EditField seems to not be possible. I may start another post with more detail when I find time, but if anyone has any ideas, I’d love to hear them.
Would https://documentation.xojo.com/topics/databases/supported_engines/postgresql.html do the same job if you stop having ‘bound controls’ and update them manually?
Many of my little “helper” apps since the main program have used the native Xojo PostgreSQL Database classes. So, yep… those will eventually work. Unfortunately for the main app, pgSQL4RB’s approach is so different that it would be an inordinate amount of work to refactor everything.
In the meantime, as an update to anyone interested, I have my application up and running on an m1 MacBook Air compiling with Xojo 2021 r3.1! I stepped through a number of old REALbasic/Studio/Xojo versions to get to that point. As @Eric_Williams stated, it was a nightmare in the early versions. Once I got it running in Xojo 2016r41, it was trivial to update it all the way to 2021.
My biggest hack right now is that I simply did not update two key controls: an EditField and a StaticText. Even though in theory EditFields are completely removed, it seems to work. Both controls are only used in debug builds for checking server queries/status, so they shouldn’t affect day to day. Eventually I’ll do a major rewrite using native PostgreSQL classes and not have to worry about it, but seeing as my current application survived 16 years without an update, I think I’ll make it a bit longer