The Xojo drought we’re experiencing in 2020 is starting to become ridiculous. The last release, Xojo 2019 R 3.1, was released January 23rd, 2020. As of today we’re at 152 days.
The longest previous delay between releases was 143 days between Xojo 2012 R2.1 (January 12, 2013) and 2013 R1 (June 4, 2013). If I recall correctly this was the transition from Real Studio to Xojo and was when the IDE went through a massive redesign (and ironically I was accused of causing a 6 month delay due to a blog post).
Come on Xojo. There are plenty of bugs and enhancements that should be shipped NOW. Is the Rapid Release Model being replaced with once a year monolithic releases?
I understand that the future of Xojo is API 2.0. I have used API 2.0 and while I disagree with some of the naming conventions I can live with it. I do have a problem with many of my older projects, however. My older projects, especially the big ones, will most likely never use API 2.0 because it’s simply too big of a task to convert.
To upgrade to API 2.0 for a desktop project I have to change my error handling to go from checking for error codes to handling exceptions. Any string manipulation cannot simply be upgraded because the older API is 1-based and the newer one is 0-based. And the sheer number of property name changes is disastrous in some projects. Converting from Date to DateTime is not a simple replacement either.
That’s not to say that these things are not doable but they are not desirable right now. And I’d really like to not accidentally invoke an API 2.0 method or property because AutoComplete shows me both. AutoComplete conveniently shows me the old, classic property/method in red which is great but I have no way of knowing what is new for API 2.0. Therefor I’d love to have the option to choose what is shown in AutoComplete.
Feedback 57885 Feedback #57885 is just that. This case is currently ranked fairly high so I’m not the only one that thinks this is a great idea. The basic gist of it is this: there is a preference setting that allows me to select what I see in AutoComplete, API 2.0, API 2.0 and Classic, or just Classic API.
In the ideal world (as stated in the Feedback case) this would change the deprecation warnings for API 2.0 if you’ve selected Classic API and it would also switch the local documentation to the proper usage to avoid confusion.
Obviously, Xojo does NOT want to implement this because API 2.0 is the future of the platform. My argument is that without this mechanism many of us with older, big projects, won’t update our licenses because we can’t/won’t use Xojo with API 2.0.
This is not a good situation to be in because I feel we’re one macOS upgrade away from disaster. If you’ll recall before Catalina was released FolderItems were broken in for a while. This turned out to be an Apple bug that was fixed. Another example is the ColorPicker and if you’re using an older version of Xojo you have issues with it that you have to workaround. What happens with Son of Catalina comes out and something else is deprecated and we *have to* upgrade to newer Xojo.
You might feel like I’m complaining for the sake of complaining. I assure you I am just looking out for my clients assets and my own hard work. I can’t justify the cost and expense to upgrade to API 2.0 and I really don’t want to mix and match API’s. I could use a newer version of Xojo but I just can’t take the chance of using something (API 2.0) that’s not fully proven (to me) yet. All it takes is one mistake and I have a mad client.
Currently 57885 is ranked 9th. If you’d like to see it get implement throw your points at it. What do you think? Am I agonizing over AutoComplete too much or do you think I’m justified in my concern and request?
I’ve been a Xojo consultant for nearly 20 years. BKeeney Software has worked on dozens of commercial applications and untold numbers of private projects during that time period. Consulting is both an extremely rewarding and terrifying business since income can be so variable. We’ve had multiple employees for years and providing health insurance costs is an expense that’s ever growing. Having your own business is hard in the best of times.
Over the past twelve months we’ve had two employees leave on their own volition to pursue other employment opportunities. During that same period the amount of new projects slowed to a trickle and even existing clients haven’t brought in as much new work as they have in the past. Where once we routinely acquired new projects it just didn’t happen as much in 2019.
Consulting is a weird business where every client wants their project done last week for as little money as possible and then get yelled at when you tell them version 2 is going to cost a lot more money. As a consultant I’ve had to compromise with what’s best for a project with what the client is wiling to pay for. It’s a constant struggle and one that I can’t imagine going away as a consultant.
Earlier this year I was presented with the opportunity to take a full-time job as a senior developer for a company that uses Xojo along with other programming technologies. I have accepted that position and started with them in a full-time capacity a few weeks ago.
BKeeney Software will continue to support existing clients to the best of our ability. We will not be taking on new clients and we will have to be very selective in taking on additional work. We hope the transition is as painless as possible. When we cannot do the work we will give clients a list of Xojo consultants to contact and we will coordinate with them as best we can. If you’d like to be on that list let me know. Send me an email with your qualifications, types of projects that are in your wheelhouse, and maybe even a client reference I can contact.
Several Xojo developers that know me socially (and knew about the new job) have asked about our products, mainly ARGen, Shorts, and Formatted Text Control. At this point in time we will continue to offer support just like we always have. However, we are hoping to find new homes for them and have already reached out to various developers that we feel will treat them and our existing customers right. Our products were mostly driven by consulting and if we are not consulting we have no need for the products. Since we know a lot of developers use these products we’d love for them to stay in the community and stay actively developed. If you are interested in acquiring the rights to any of the products, please contact us.
I love the Xojo community and its users. I’ve never found a community that is as passionate about a product as the readers of this blog. I’m not leaving the community – but transitioning into another form. My new job uses Xojo. It’s a very large project and is certainly bigger than anything I’ve ever worked on before.
I’m looking forward to working on a set of products with a team of dedicated developers that are working on products that matter while providing a stable work environment for my family. Certainly the events currently happening in the world do not make consulting any more stable so the timing of this opportunity was exceptionally favorable.
I still plan on doing some blogging about Xojo but it will certainly slow down. As Web 2.0 and Android hits I will kick the tires and give my opinions of them because…well…I always have an opinion. 🙂
Stay safe and I look forward to seeing you all again at a Xojo event! Happy Xojo coding!
Xojo released a video today of Geoff Perlman talking about Xojo. This is mostly information that would have been given at the Xojo.Connect keynote address but, well, we all know that it isn’t normal times. I urge you to watch the video and come back. I won’t bore you with repeating what Geoff said but I’ll give some thoughts on each section.
Last 12 Months: Pretty typical recap of the last year.
In The Works – Big New Features:
Xojo Cloud: Makes sense to go to all 64-bit and to make them stand-alone apps. Having the built-in load balancer is really nice for those that don’t want to mess with it themselves.
Feedback: Web based. Yay! It’s about freaking time to get away from the stupid desktop app. I guess my question is will it improve the responsiveness of Xojo actually fixing bugs that are reported?
Web 2.0: Telling me you have great looking controls and not showing me anything to prove that makes me doubt the claim. Session restoring should be a nice feature assuming it works as required.
Really, you want to add 10,000 rows to a ListBox? I’d say that’s a bad example as that much data should be ‘paged’ but whatever. Users will do stupid stuff like that all the time.
What they didn’t say was that the conversion to Web 2.0 is a one-way trip. Make sure you backup your project before you do that.
iOS: Notifications, SearchField, Application Shortcut Items, Custom URL Schemas are all basic features and should have been in the product long ago.
iOS plugins will be good news for MonkeyBread and maybe one or two others. No idea if this means the plugins are still C++? I’d assume so but no details given.
Having String and Variant instead of Text and Auto is a good change. Mobile classes to replace iOS makes sense with Android sometime in the future. No timeframe makes it hard to guesstimate how excited anyone should be.
API 2.0: While it’s cool that a desktop, web, iOS, and Android projects can now use the exact same code it’s a shame that we can’t have all of those projects from a single project with different targets. I know I’m being petty but that seems like the next logical step.
Desktop Controls will be replaced to use the API 2.0 events. This is the way it should have been done from the beginning. It completely eliminates the train wreck that we all experienced with the now non-existent Xojo 2019 R3 release.
Android: The fact there’s an Android version of the Conference app in Google Play Store is a good sign that it’s coming along and fairly well advanced. Hard to say exactly how far along but is but still. The Android video should be interesting.
Graphics: Having XojoScript be able to do graphics is a really nice feature. I’d love to know what the refresh rate can be. I don’t have any idea on what I’d use it for, but I could see that being used to create control plugins made in Xojo.
PDFDocument: It’s a great beginning. I suspect that most people will be disappointed because it looks like it’s graphics only. Meaning that the PDF can’t be searched. I might be wrong but that will be the first thing that I’ll check. Without that it’s pretty minimal feature set and not what many people want.
Worker Class: A good discussion on why threads are hard and why using console helper apps makes use of multiple cores whereas a normal thread only uses one. Geoff might be using App.DoEvents in the only permissible place to use it but even then, I wouldn’t use it since too many people use it as a crutch and abuse it.
The Worker class looks really cool and is probably the best thing that Geoff discussed. I have many questions on how the class and its events work. For example the JobRequested and JobRun events only uses string. Is that the only datatype we can use with that? I suspect it is because it’s creating a console app in the background. Regardless, it really takes the work out of working with console helper apps.
Also no talk about what’s the preparation time. Would it be easier, in the long run to simply create your own helper console apps? My guess is probably but the details are important here.
Overall: It’s nice to see progress on things in the Xojo universe and a few surprising additions (Worker class). What we don’t know is when these things are going to ship (and be useable). The thing I could use today is the Worker class and I suspect that it will be the last thing introduced (sorry for being pessimistic). This has always been the most frustrating thing about going to XDC and being told about something really cool and then having to wait a year (or more) before we see it.
Last week Xojo 2019 Release 3.1 hit the internet. This small bug fix release is a critical update and is recommended if you are using one of several areas. Let’s get into the details.
One of my biggest issues of concern with API 2.0 is with a dangerous memory leak in the DatabaseRow class. Doing practically anything with a database would quickly eat of RAM until it brought your machine to its knees. R3.1 fixes this issue and also a memory leak when using ODBC.
A couple of iOS bug were fixed in this release. R3.1 fixes a regression that caused iOSTextAreas to overflow their bounds when the border was set to None or Regular. iOSView headers no longer show the previous view during the PushTo animation. Xojo added the Operator_Compare to the ColorGroup so that it can be compared against a color value.
A number of API 2.0 bugs (besides the database bugs noted above were fixed):
TextArea.SelectionAlignment now accepts enum values.
String.IndexOf now properly matches its signature when you leave off the startPosition but include ComparisonOptions or Locale.
If an empty name is used in the TimeZone constructor it will create an instance for the current timezone.
String.LastField now works
SerialConnection.Connect no longer raises an Error event. It now throws an exception as expected.
DateTime no longer reports a Nil TimeZone
In Windows, having multiple HTMLViewers on a window (or multiple windows) no longer continuously switches focus.
In MacOS setting FolderItem.Visible no longer inverts the visibility.
The Plugin SDK now lets you access the new API 2.0 string extension methods.
The burning question that everyone wants to know: Do I think that Release 3.1 is safe to use? The answer is a definite maybe. Let me explain.
I’m still not sold on API 2.0 being completely stable. A few additional bug reports were filed after R3.1 was released including a GenerateJSON bug with Variant arrays (Feedback 58940), and a DatabaseColumn.Value bug where value always returns a String value (Feedback 58934) where it should be bringing back the correct data type. Both of these bugs are marked as fixed and ready for 2020 R1. Unfortunately we don’t know when R1 will drop but if I was a betting person I’d guess sometime in March either the week of Xojo.Connect or maybe even later.
If you’re using Classic API then I believe R3.1 is safe(ish). I’ve experienced some oddities in the Constants Editor but I can’t replicate an issue where it reverts the value with no intervention on my part. The new ColorGroup Editor for iOS projects just seems sluggish but that may just be the result of the new ColorPicker. If you’re doing iOS projects you pretty much have to use R3.1 to stay up to date.
I have migrated a few projects to R3.1. A few that I’ve attempted have had compilation issues and I haven’t gone back to determine if they were plugin or code issues and frankly I’m not that big of a hurry to upgrade. R1.1 is still working fine for me and I don’t need the hassles involved with major Xojo upgrades.
So my advice is to test the heck out of your projects if you upgrade to R3.1. I say this every release (because its true) but if you’re using API 2.0 then massive testing is a necessity. I put it this way: do you want to bet your company and/or product on trusting a new API?
What is your experience with 2019 R3.1? Is it worthy? Are you holding back and, if so, why?
I’ve been a member of the Xojo community for nearly twenty years. In that time I’ve seen a lot of people join the community, become fantastic contributors, and then suddenly leave the community. There are a lot of reasons developers would leave the community but I thought I’d capture some of them.
Xojo scratches an itch and if the developer no longer has the need to scratch that itch they use a tool that scratches their next itch. Xojo is great for cross-platform applications but certainly less so if you need only a Mac or only a Windows application. Xojo’s strength is cross-platform which means compromises in abilities and controls so I can understand people wanting a pure Windows or MacOS application. Apple and Microsoft have large developer communities that are attractive.
The Rapid Release Program held much promise when it was introduced many years ago. Xojo went from two big monolithic releases a year to three, four or more releases per year. Sure, Xojo fixes a ton of stuff in each release but they also seem to break stuff in each release. I know we have a list of verboten releases for various platforms and it gives the impression of a perpetual beta status for Xojo. I have been a big fan of releases that are almost all bug fixes with no new features but those are pretty rare.
Xojo is a modern object oriented language and is quite powerful but it’s not a popular language. Many developers have never heard of Xojo. There is no standards committee that adds features to the language and the language itself is closed source. If there was a standards committee I suspect there would be some serious language additions done sooner rather than later. It certainly would have given much more forethought into API 2.0 and how it would affect the existing user base and the documentation done long before any coding started.
Xojo isn’t like any other development tool I’ve ever used. It’s great that it doesn’t allow a developer to make a stupid mistake when declaring a method. It forces you to use the Xojo IDE user interface to do everything from creating methods, declaring properties, constants, enums, etc. I’ve never used another developer tool that does this. Xojo pretty much forces you to use it the way they want you to rather than what most other languages do with a text editor. This makes it easier for beginners but if I’m being honest it’s a drag for someone like me that (usually) knows what they are doing. Forcing developers into the Xojo-way of doing things makes the IDE seem like a toy at times. It’s certainly slower.
Change does not happen quickly with Xojo. It has a small development staff and I’m always amazed at how much they get done. But it means that it can take an incredibly long time for things to change and become stable. The transition to 64-bit was a huge multi-year project. iOS was a huge multi-year project. Web 2.0 and Android have become huge multi-year projects (with still no idea on when we’ll see them). The new targets might be good eventually but history shows it will take a few releases before they’re really stable. Meanwhile older targets seem to get significantly less attention.
Xojo isn’t really a business development tool. When I say business I mean databases and reports because that’s practically every application we’ve done for the past twenty years. Doing database development in Xojo is NOT Rapid Application Development (RAD) because you have to deal with everything database related yourself and the IDE and compiler give you zero help. Reports are simplistic and aren’t exceptionally powerful and there’s no way for an end user to create or edit reports. There’s a reason why BKeeney Software has its own database Object Relation Model (ORM) classes and reporting tools and classes because we have to use them in nearly every project we do for clients.
In addition to all that it’s really missing some things that business users need. The TextArea control has pitiful RTF support, there is no built-in calendar, date, or time controls. The built-in grid (Listbox) is more powerful than many people give it credit for but cannot hold native controls and can be very slow with large data sets. There is no PDF read or write support either. There are 3rd party options for all of these things but something lightweight would go a long way to supporting new business users.
These are a few of my thoughts. What am I missing about developers that leave Xojo? And is there a way to stop them from moving away from Xojo? What are they doing to?
Xojo announced today the creation of the Most Valuable Professionals (MVPs) advisory board. More information here: https://www.xojo.com/mvp/
Having ‘known’ these five Xojo developers for many years (mostly online and a few in person) I think they are an excellent group to advise Xojo. Most of these developers have many years of Xojo experience ranging from being 3rd party control and library developers to consultants to commercial application developers.
It makes me happy that every single one of the developers on the Advisory Board is what I would call part of the ‘professional’ developers of Xojo. It is surprising, however, that there are no ‘citizen’ developers on the board. So I call this a mixed signal to who Xojo is trying to appeal to (obviously it’s everybody but I think you get my point).
The Association of REALbasic Professionals (ARBP) tried to do this ten years ago with no success. The groups mission was to help inform Xojo (then Real Software) on what the professionals wanted out of the tool. If I recall correctly the only thing that was ever implemented out of our top 5 list was reporting. Grids, PDF support, and more basic controls never materialized. Sadly, we all still want those options.
It’s not being said but I believe the MVPs Advisory Board is a direct response to the virulently negative (and vocal) reaction by some Xojo developers had with the rollout of API 2.0. I am one of those developers and it is no big surprise that I was not invited to be on this board and, if I’m being honest, I’m not sure I would have accepted anyway.
We don’t know how the advisory board works, or even if it will significantly change how Xojo approaches future changes. Even if they do have significant input I’m not sure we’d know unless Xojo specifically tells us.
Good luck to this group and Xojo: There are some relationships to mend.
Xojo 2019 Release 3 hit the internet today. It’s only been three weeks since R2 was released and while this release has a number of bug fixes that are important this release is mostly about iOS.
R3 introduces a new ColorGroup class that will eventually come to all targets but for now it’s only available for iOS. The ColorGroup has its own editor and allows the developer to set or choose colors they want to use. You can choose Single, Dual, or Named colors. I’m not entirely sure the point of the Single color, but Dual allows you to change a single color based on Light or Dark mode, and then there is the Named option.
I feel that the Named option is the more valuable of the settings as it allows you to select what type of ‘color’ you’re using and allow to use, or modify the default colors in Light or Dark Mode. For example, if I simply wanted to use the default colors of an iOSLabel I can select the ColorGroup from a new popup in the Inspector. The control then will automatically use the Label color. But if I want to override the defaults I can do so here for both Light and Dark modes.
This has the promise to help Xojo developers that are supporting Light and Dark Modes in their applications. Since it’s currently for iOS only and I’m not actively working on an iOS project I can’t speak to its effectiveness and usefulness in coding. I feel that the ColorGroup editor was slow to respond to color picker changes. If you have some firsthand knowledge of the ColorGroup in action please leave a comment below.
The iOSTextArea control has a new Border Style and Border Color properties that allow you to create rectangle and rounded borders. SF Symbols can be retrieved by the iOS framework using the iOSImage.SystemImage shared method. The iOSRectangle now supports Blur effects.
After iOS there are number of new additions and changes that are part of the API 2.0 work. If you are interested please read the release notes. I am not actively using API 2.0 in any projects so these changes don’t mean anything to me yet.
Some Windows bug fixes: The Draw Caution/Note/Stop icons are updated to the newer look for Windows Vista and later. The app now terminates when the system sends a shutdown message (like when an installer is trying to update the app). The GroupBox no longer draws funny when the caption font size is different than the default.
Some Linux bug fixes: Changing the Label Text Color no longer leaks memory. Clipping the listbox graphics in the CelLTextPaint or CellBackgroundPaint now works as expected.
With iOS Dark Mode out of the way, hopefully this means that 2020 R1 will have the long awaited Web 2.0. My gut feeling is that Web 2.0 won’t be released until Xojo.Connect at the end of March and even then it might be only in beta form. Web 2.0 is a complete rewrite from the ground up that’s been underway for a while. Maybe I’m wrong but experience says they’ll want something big and flashy to show off. Of course I also expect more from Android but I still expect that to be in alpha and nowhere near ready for release.
R3 is mainly an iOS release for Dark Mode and some changes for API 2.0 and then mostly bug fixes. As always, before using you should read the release notes and then thoroughly test your application before issuing any releases.
In my quest to find a Xojo alternative I came across RAD Studio https://www.embarcadero.com/products/rad-studio that is owned by Embarcadero. RAD Studio can work with C++ or Delphi (object Pascal) and build for Windows 32 and 64-bit, MacOS 32 and 64-bit, Linux, Android, and iOS depending up on the license. They also have a Community Edition that can build for Windows, macOS, Android, and iOS but is free until company revenue reaches $5,000 or you get to 5 developers.
The RAD Studio IDE is Windows only even though it will allow live debugging into the other target environments. For my testing I was running the IDE using Parallels 15 in Coherence Mode running Windows 10 64-bit. The VM resides on an external SSD via Thunderbolt 2. I found the environment to be responsive despite being in the VM environment.
During installation it asks if you want C++ or Delphi for MacOS, Windows 32 bit Windows 64 bit, Linux, Android and iOS. I selected Win32 and MacOS. It took a good 15 minutes to install. You definitely need a large VM to do this. I ran out of space on my VM and had to start over again after clearing up some space.
To start testing, I created a New Multi-Device application. Doing a Hello World was simple enough. Double click on the on the label in the Palette, or drag and drop onto the form. Scroll down in the Object Inspector and change the Text property to “Hello World”.
At this point I’m ready to rock and hoping for the best. Pressing the Run button runs the app and voila a Windows app with a window saying “Hello World” pops up. Passes the first easy test. But what about getting the Mac version going?
To set up for the Mac (or iOS, Android, Linux or even another Windows computer) you’ll have to install the Platform Assistant Server (paserver for short). Paserver is a command-line application that you install on Windows, macOS, and Linux so that RAD Studio can connect and do its thing.
I had to read through the help file to figure out how to do this. PAServer20.0.pkg is located in C:\Program Files (x86)\Embarcadero\Studio\20.0\PAServer and you copy it to the Mac side to install it. The PAServer installer is using a code signing certificate that’s expired but it’s easy enough to work around. The installer puts two applications in your Applications folder: PAServer-20.0 and PAServerManager. But for now we’re only concerned with the PAServer-20.0 application. Go ahead and double-click to start it.
This opens the Terminal and the first thing it asks you for is a Connection Profile password. I set it to blank for ease of setup. It automatically opens port 64211 and a Mac security prompt immediately pops up asking if I want to allow incoming connections.
Going back into RAD Studio if I go to the project listing that shows my targets and I select Properties from macOS 64-bit I can setup my paserver now. Select which SDK to use (Mac 64-bit), then input the TCP address of the Mac. Test the connection and then select OK. A bunch of files get copied over to the Mac side.
Trying to debug run the application on the Mac side generates an error. Module not found: dccosx64260.dll After contacting the sales rep for help it appears that I had version 10.3 Update 2 and the fix for this problem was in Update 3. Maybe I just missed something in the myriad of menu’s but I never did find an “Update” in the application. I had to go to their website and search for updates and download an updater. The updater then proceeded to uninstall the previous version and then proceeded to give me the default settings (not what I’m looking for). It seems that the installer is pretty stupid. But it installs.
This is really where my review should end. After spending a number of hours trying to get this working I was unable to actually see a Mac app running. Despite updating the entire RAD Studio (twice) and update paserver I could never get any of the demo apps to run on the Mac. I know this works since I saw an Embarcardaro engineer do it. I’m sure it’s something I’ve done wrong but I figure if I can’t figure it out in a couple of days of messing with it then it’s not a trivial issue. It was very frustrating.
Initial thoughts on the IDE: This is a very typical 90’s looking MDI Windows application with one big overall window with various smaller windows inside of it. I find it to be very busy but not awful. I can live with it. I have to remind myself that I’m a spoiled Mac user and I expect ‘pretty’ and functional UI from every application.
The Projects list shows all of the available targets and seems pretty straightforward. This window disappeared on me once and the only way I found to get back to it once reopen the project. I’m sure there’s some menu command to get it back – I just couldn’t find it.
The Object Inspector is listed alphabetically and not grouped into functional groups. It has two tabs, Properties that shows the properties and Events which shows the available events. Double clicking on a control, like a Button, automatically drops you into the Code Editor and into the Action event. All code for a form or library is available as a complete text file rather than the way Xojo presents it to the user in a singular fashion (i.e. you get to see one method, property, or event at a time regardless of your coding skill level.
Here’s where things got really confusing for me. A multi-device project has one library (FMX) whereas a Windows-only project could use that one or one called VCL. Then there’s the choice of what language to use C++ versus Delphi. I was really confused on how to even figure out how to do a simple message box on the click event. I don’t see this as a huge problem as it’s common with learning any new framework so it’s just a matter of finding the right documentation and doing some reading. But it is a little concerning that I wasn’t able to find this readily. It was frustrating.
Code signing is built-in for all target types. For Mac deployment (assuming you can get it working) has built-in Notarization but it should be noted that you have to have a Mac and use paserver application to do code signing and notarization.
Another interesting thing is that you can have Windows, Mac, Linux targets all in one project file. That’s not too much different than Xojo but what’s also interesting is that you can have Android and iOS targets as well. The form editor gives you a simulation of what the UI looks like native to that platform. I’ll be honest, it’s not a great simulation but it’s enough for you to get the gist of how it will look. Of course, it’s convenient that you can reuse code amongst all of the targets in the same project.
During a demo with a sales rep and engineer I asked if the Mac controls were native. They said they were but I can say with 100% certainty that the standard tab control in RAD Studio is not using the standard Mac tab control (that looks like segmented buttons centered on the page). So I wonder about the veracity of this claim. I could never verify this as i was unable to get a Mac app running on my machine.
RAD Studio has considerably more built-in controls than Xojo. It really puts Xojo’s control library to shame. It has everything to get going without having to jump to the 3rd party market. However, when you do need something not provided (or that needs more features) there is a window to find them. Simply go to the Tools->GetIt Package Manager menu option and use the search field to find what you need. Additional filters allow you to see all, free, already purchased items and so on. Need a PDF viewer, reporting tool, or advanced grid? It’s in the list along with details about it and it has a convenient Install button right there.
RAD Studio is more expensive than Xojo but it does things that Xojo cannot currently do (Android for example). To create macOS, Windows, Android, and iOS applications it costs $2540 for the first year and that includes all major updates, hot fixes and ongoing maintenance of previous releases, and 3 developer support incidents. The Enterprise license allows you to do client/server databases, build for Linux, and build REST API applications for $4217.
In many ways, RAD Studio is what I wish Xojo was striving for. It has a definite “we’re serious” feel to it. The 3rd party integration is really nice. The documentation is very expansive and relatively easy to find things although as I noted above I had issues figuring out how to do a simple message box. It is nice to see that they have hot fixes available rather than having to wait for a major update.
For a company that touts its cross-platform development capabilities I find it kind of funny that they don’t have a Linux or Mac version of their IDE. If they did I think they’d learn a few things about making Mac applications in making their IDE truly cross-platform.
The fact that I’ve struggled to find answers to installation issues says that it’s not an easy language and IDE to learn. I suspect that having dual languages (C++ and Delphi) along with multiple UI libraries makes getting started much tougher than it needs to be. Getting the cross-platform applications working seems to be finicky and while I’m sure it works I threw my hands up in frustration.
Yes, I’m spoiled because the Xojo IDE (mostly) works the same on Mac, Windows, and Linux and compiles for the other platforms without needing to run a special app on the target platform (iOS requires a Mac but that’s an Apple restriction). While it’s true that there have been hiccups with API 2.0 the language is still undeniably Xojo and the Language Reference is decent with working code examples. Where Xojo is deficient is in default controls (like Date, Time, Calendar) and there is zero 3rd party controls/libraries discoverability in the Xojo IDE.
If you have a different experience with RAD Studio I’d love to hear from you. Are you doing macOS and iOS development with it? Did I do a fair review (keep in mind I’m coming from a Xojo)?
Xojo 2019 Release 2.1 hit the web today. If you are using R2 and any of API 2.0 this dot release is a must for you. I almost would have almost preferred this release to be called R3. The biggest change in Release 2.1 is that the API 2.0 events have been dropped from API 2.0 entirely. There are also quite a few other changes and bug fixes that might impact your projects too.
Removal of the API 2.0 events was a concession to the 3rd party Xojo market (myself included). There really was just no tenable way for Xojo developers to support both the old and new events simultaneously and after much lobbying and teeth gnashing they were removed.
If you had implemented the new Events the R2.1 IDE will rename them back to the old events. This is a good feature, but I’m always leery of the IDE changing code on me without my knowledge. I recommend making a backup of your project before using this release.
Not everything is perfect with API 2.0 as it’s still hard to provide backwards compatibility with versions of Xojo prior to R2.1. All of the new API 2.0 Properties and class Methods are significantly different and permanently change your source code that is not compatible with pre-API 2.0 versions of Xojo. To help with this Xojo has added a new compatibility flag under the Gear icon in the Inspector that works with classes and properties. You can check if the Object, Method, or Property is API 1 or API 2 compatible.
Really, these flags should be titled XojoVersion < 2019.021 and XojoVersion >=2019.02.1 to make it more clear. But in reality this means that a Xojo developer must be using Xojo 2019 R2.1 or better to take advantage of these flags. To be honest I’m still unclear on how these flags really work and the documentation regarding them is sparse.
Another change is a new menu option called Analysis Warnings under the Project Menu. This dialog lets you pick and choose which warnings to see when you Analyze your project. If you set “Item X is deprecated. You should use Item Y instead,” to false you will no longer receive the API 2.0 deprecation warnings. This is set to false by default so you won’t receive the deprecation warning unless you go looking for it.
The FolderItem class has new methods: CreateFolder, CopyTo, MoveTo, and Open that now raise exceptions.
Window.Controls is now Iterable and you can use them in a For Each Loop to iterate through all controls on a window.
The DateTime class now has an optional parameter that lets you specify the TimeZone.
There are ton of bug fixes. Here are some of the highlights:
The IDE no longer crashes on macOS 10.15 (Catalina) when clicking on a color swatch in the Inspector and then navigating to another control before closing the color picker.
RemoveAllRows no longer crashes the application under certain circumstances.
The Database Editor no longer throws exceptions when dropping table columns.
They fixed a number of memory leaks. This includes (but probably not limited to) ODBCDatabase when binding parameters to prepared statements, MSSQLServerDatabase when using Prepared statements. When database objects go out of scope or are set to nil.
There are numerous examples of Deprecations with Replacement warnings now working properly with various classes. Constants have been replaced with more enums and so on. There’s just a boatload things working better with API 2.0.
In general if you are already using R2 then you MUST upgrade to R2.1. If you’re not using R2 then I still suggest waiting for at least another cycle since more bugs will be found and probably a few more things tweaked.
If you feel like you’ve wasted your time with R2 I feel your pain. The whole R2 cycle was really long yet API 2.0 was rushed through without much thought about the existing Xojo community and ecosystem despite attempts at communicating this information. I just don’t see the benefits of disrupting the entire user base, 3rd party ecosystem, not to mention 20 years of documentation, internet search engine results and so on, for what, in my opinion, are arbitrary and meaningless name changes. Some of the name changes make little sense but that’s a different argument that I’ve made before.
Personally, I would have appreciated the approach that they took with the URLConnection class that replaced HTTPSocket. It was a new class and you didn’t have to use it. It is using the new style exceptions rather than relying on error codes and it is a complete break from the old class. They did this with DateTime and RowSet and I’m fine with those. But having FolderItem (and other classes) now doing double duty depending on *how* you create them is a long-term support disaster.
So there you go Xojo coders. Xojo 2019 R2.1 is out and it’s better than R2 and has major changes that make our lives a little easier. What are your thoughts about Xojo 2019 R2.1?
[Edit] Apparently the Analysis Warnings dialog is NOT new. I’ve just never noticed it and, until now, I guess I’ve never needed to care.