Xojo released a dot release this week that contains some important bug fixes. Arm64 and iOS targets as well as the new Worker class received a number of important fixes. Let’s get into some of the details.
The new Worker class will now use the Error event if the main app tries to start a worker without the required Helpers folder instead of throwing a Nil Object Exception. The Error event no longer fires when the Worker quits normally.
ARM builds for macOS has added complexity for Build Steps. We now can specify architecture for CopoyFilesSteps. Resizing an array of structures no longer crashes on macOS ARM builds.
The ODBC database plugin no longer fails to connect.
ParseJSON no longer raises a failed assertion when passed an empty string.
The new DateTimePicker uses the standard border width and the control height was changed for Windows. The DateSelected returns a valid DateTime object in Windows. On the Mac side the control now honors the Top value when displayed in Text mode and you can now set the SelectedDate property regardless of the Regional settings of the user.
TabPanel.RemovePanelAt no longer throws an Out of Bounds Exception if the tab exists.
iOS has a number of changes. Global.Speak is now System.Speak, Graphics.Font returns a Font object instead of iOSFont. UDPSocket usage no longer causes the app to terminate after unlocking the phone. The Runtime module methods are now accessible. Graphics FontSize, Bold, Italic are removed in favor of the equivalent Font class properties.
All users should update to Release 2.1 because of these important bug fixes.
The second major release of Xojo 2020 landed this week. This release is filled with changes that will make many Xojo developers very happy. Let’s dig into some of the details.
To say that iOS had a major update doesn’t quite do it enough justice. iOS is now using the global framework so the old Xojo framework is now deprecated. What this means is that code shared between web, desktop, and iOS is now considerably more compatible. Plus, iOS is more complete with many of the missing classes, like XML, TCPSocket, RegEx, to name a few finally make their way to the target. And, perhaps more importantly the String and Variant classes can now be used instead of Text and Auto (and their requisite pain of usage).
This release also lays some of the groundwork for Android. No longer are the classes named with an iOS prefix but now use the Mobile prefix. Presumably whenever Android is released there will be many classes that crossover just like Desktop targets do right now.
Another big change in iOS is the ability to use plugins. This allows plugin developers, like Monkeybread Software, to add an extreme amount of functionality to iOS that simply wasn’t available until now. Simply looking at the Monkeybread website shows some of their biggest items available for iOS including Barcodes, Compression, CURL, DynaPDF, GraphicsMagick, SQL, XL, and XMP to name a few. Expect more and better things to be available to your iOS projects in the future.
How well does iOS work? I can’t really tell you. I have several iOS projects that use some of the iOSKit extensions and it will be a fair bit of work, I think, to replace everything. The sad part is that I’ll likely be forced to update them soon so I can release some client updates. I’ll keep you informed of my progress and pain when I do that. If you have some current experience with this iOS release please share your experience with us.
The R2 release also brings us the new Worker Class. The Worker is a way to utilize more cores on your machine than using a traditional Thread can use. Essentially you’re offloading work from the single core that your Xojo application uses and it starts a separate console application to do that work thus utilizing more cores on your computer. You could always do this on your own using a variety of methods but this automates the process.
You start by creating a Worker class object and implement the events Error, JobCompleted, JobRequested, and JobRun. When you want it to do some work call Worker class Start method that then fires the JobRequested event. This event is where you pass in some string data that the JobRun event uses. When that job is completed the JobCompleted event fires passing in whatever string data you need. The Error event is there to help pick up the pieces.
When run in the Debugger the worker classes is a thread but when it’s compiled a console application is placed in the appropriate placed for each target. This means that there is a real difference between running something in the debugger versus your final application so it’s very important to test your results. Since you’re limited to string data it’s probably not a great idea to pass large amounts of string data between your app and your Worker so maybe coming up with an intermediary (like a database file) might be useful.
The Worker class is only available for Desktop targets for now and will presumably come to Console, Web and iOS targets in a future release. I think developers will use this a lot and I expect some more advanced features coming to this class in the future.
With Apple releasing their first arm64 Mac’s just a few weeks ago this release also marks the first version that allows for native ARM applications as well as universal Mac apps (i.e. both Intel and arm versions). The only thing I’m aware of that is not arm compatible is XojoScript and that will presumably come in a later release. One thing to be aware of (this has been true for a while) is that to compile for macOS you need to be running Xojo on a Mac. If you are running in Windows or Linux you cannot build macOS apps. Xojo seems to think this is a temporary situation so hopefully that’ll happen soon.
The Graphics class received some love in this release adding LineCap and LineJoin properties. It also adds support for Linear Gradient Brush, Radial Gradient Brush, Shadow Brush, and Picture Brush that allows a developer to do some really cool drawing effects. This is long overdue.
For the first time in many years Xojo has added several highly requested and long overdue controls to the desktop. New in R2 is a Search Field and a DateTime Picker. The Search Field has pretty standard features. The new DateTime control has the ability to be used in text-only mode or in graphical mode. Again, it’s my opinion that these controls should have been added a long time ago but it’s nice that we have them now.
A few API 2.0 framework changes happened for TextField and TextArea controls. The Value property is Text and the ValueChanged event is now TextChanged. I think these changes make way more sense than Value and ValueChanged.
ColorGroups are now available for desktop, web, and iOS targets.
All in all this is another big release from Xojo adding new desktop controls, adding new capabilities to the Graphics class, the new Worker class, and doing a massive update to iOS. The Xojo roadmap has their next big item as Android and with the R2 release it’s clear that they are getting close. Will there be an R3 for the end of the year? My spider sense says no but there might be a dot release to fix any major bugs that slipped through the cracks.
What say you Xojo developers? Is R2 a good release? What quibbles do you have with any of the decisions they’ve made? Happy Coding!
Xojo 2020 R1 was released today. The last major release of Xojo came nearly 9 months ago. This much anticipated release has a completely rewritten from the ground up Web API that takes Xojo web applications to a whole new level in terms of look and feel with themes, new controls, and new functionality. This release also brings a ton of new and improved functionality to desktop applications too. Let’s dive into it!
The elephant in the room in this release is Web 2.0. Web 2.0 is a complete reimagining of what Xojo web applications look like.
Controls galore. Web 2.0 comes with all of the web 1.0 control (see exception below) and a host of new controls that look and feel really nice. Among the new controls: Audio Player, Breadcrumb, Chart, Date Picker, Pagination, Search Field, and a host of specific TextField types like email, number, password, and telephone.
Every standard control (buttons, text fields, etc) have a wide variety of new options that I think will make developers happy. The new WebListbox has monster changes and I really can’t do it justice in this review. Among some of the big additions is the ability to load data dynamically using the WebDataSource. If you’ve used iOS in Xojo it acts pretty much the same way and allows you to have practically unlimited numbers of rows of data and it will load the data as the user scrolls. This means you don’t have to page your data (though you can if you want by loading the data manually in combination with the new Pagination control).
Even more interesting are the new WebListbox Cell Renderer classes. In this release there are four built-in with DateTimeRenderer, ImageRenderer, StyleRenderer, and TextRenderer (the default renderer that doesn’t need any special action on your part). The DateTimeRenderer lets you specify the Date and Time format styles but also a Relative Style (like “Today” and “Yesterday” values with time) and it also localizes the data to the users locale. The ImageRenderer is pretty straightforward to view images, the Style lets you set the style of an individual listbox cell and, of course, the TextRenderer is the default. The WebSDK example comes with a Button Cell and Color Cell renderer too so it should be exciting to see what developers do with for this.
While Web 1.0 had WebStyles they really were hard to use. Web 2.0 uses Bootstrap and that gives you an incredible amount of variety available in your Xojo web applications. While there’s a default bootstrap theme there is no theme editor in this initial release but it’s not so hard to change the theme on your own. One way to change the theme is to go to https://pikock.github.io/bootstrap-magic/, save the css file to your computer, rename the file to boostrap.min.css and add to your project. Users can download pre-made bootstrap 4 themes from bootswatch.com. Unfortunately the IDE doesn’t render these themes very well but it works at runtime.
Web 2.0 projects compile only to standalone now so you no longer have the option of using a cgi version. Xojo Cloud users automatically get load balancers for your applications and you get the same number of application instances as you number of cores on your server plan.
While most of Web 2.0 is very exciting and enticing those that have an existing Web 1.0 project will most likely not be very happy. The conversion process is a one way process and not everything converts. WebAnimator does not have a Web 2 counterpart and WebStyles are completely reimagined so while the compiler won’t complain if your code uses an old WebStyle it’s pretty much ignored. I would even say that the conversion to Web 2 is broken to the point where it would be easier to rewrite your project into Web 2 than it is to try and convert it. Default control heights in Web 2.0 (38 pixels tall but depends on the theme) are considerably bigger than Web 1 (22 pixels) so I find it hard to imagine that most layouts wouldn’t need considerable work to get correct for Web 2.0. It sucks, but that’s the reality of it.
There are some missing parts in the IDE that are disappointing as well. The WebToolbar and WebStyle editors are missing in Web 2.0 but the good thing is that both can be created in code. Web 2.0 does not have control sets implemented at this point.
It’s also disappointing that not all of the Web 2.0 examples are working properly or are so simple as to be useless in learning how to use Web 2.0 (I’m looking at the WebListBox examples). The documentation for Web 2.0 isn’t as clear cut as I’d like too and I disagree with some of the property groupings for the Inspector. For example in a WebLabel and WebLink there are Font properties to set the font properties but a WebTextArea does not have this and you have to manually set them via the Style property. Why does one control have it exposed and another one does not? Xojo has one shot to impress developers with this release and inconsistency is a bad look in my opinion.
Everything Non-Web 2.0
While Web 2.0 is by far the biggest part of 2020 Release 1 but it is not the only important change. Here are some of the highlights.
Listbox Header drawing events. New in R1 is ListBox.HeaderBackgroundPaint and HeaderContentPaint. This allows the developer to have total control over the drawing of the headers. Want to draw an image, or change the background color, or even change the sort indicators? No problem now with these two events.
TextArea now has a UnicodeMode that allows you to change the way the control treats characters. The default is Native and that doesn’t change anything. The Characters setting counts by the single character regardless of the byes used and the Codepoints setting counts by number of Unicode Codepoints (bytes) it requires. The Codepoints way is what you’d have to use for an emoji. This is a nice addition from the the old Xojo Framework. They also now have a String.Characters iterator.
For years Xojo developers have had to rely on third party plugins to create PDF documents in Xojo applications. New in 2020 R1 is the PDFDocument class that allows you to create a PDF document fairly easily using simple graphics object commands. PDFDocument does not support transparency so you’ll have to consider the order that you’re drawing items and you might find it hard to create some forms of documents. All in all this is a great addition to the product that many people will like. PDFDocument is available in all targets excepts iOS. It’s not perfect but for many users it will be good enough and hopefully they’ll add some features to it in future releases.
Linux applications now have a Normalize Control Sizes build option. It normalizes the controls widths/heights, removing theme specific padding and adjustments to make controls on any Linux distribution look similar.
XojoScript’s can now be saved in their compiled form into a MemoryBlock and that means you can read and write them to a file. This should allow XojoScripts to be considerably faster since they may not have to be recompiled every time they’re used. If you use XojoScript I think you will really like this feature.
Project loading and compiling of desktop applications is considerably improved. In my testing it’s about the same speed as Xojo 2019 R1.1. Gone is the slow down users experienced after they did a check project.
There are dozens of other bug fixes and changes that I could tell you about but I’ll leave the joy of reading the release notes to you. Why should I have all that fun?
Xojo 2020 R1 is a huge release that’s been in the making for long time (if we’re being honest the wait was too long). Web 2.0 has a lot of exciting new features, controls, theming options that should excite developers. Converting projects is very hard and I think learning the new controls is harder than it needs to be with incomplete documentation and examples that are either not working or weak. I really don’t have a real good feel for how stable Web 2 is simply because I’m not working on any web projects currently. I suspect that there are bugs to be found as more people start stress testing it. But it’s a good start and I look forward to the missing pieces being filled in as time goes on.
Obviously Web 2.0 is the big star of this release but the PDFDocument class is a great addition that users have been asking for years. The other bug fixes and changes are also big and even if you aren’t a Xojo web developer this is a big and important release. I’ve been using R1 for desktop apps (Mac and Windows only) and I’ve found it to be stable and I have no complaints (other than no being able to turn off API 2 items).
What say you Xojo developers? Is Web 2.0 worth the wait? Is is stable? What do you think it’s lacking? What do you think about the desktop changes?
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.
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.
In my search for Xojo alternatives I was pointed to Lazarus https://www.lazarus-ide.org which is a cross-platform IDE that uses a Delphi-compatible language (i.e. object Pascal). I was pretty happy to see that it has a Mac version of the IDE and I will freely admit that I prefer to work on MacOS for a variety of reasons. Among them is usually ease of installation and Lazarus completely fails on this count in my opinion.
Let’s start with installation. The Lazarus website takes you to a SourceForge repository that has three downloads. fpc is the compiler, command line tools and non-visual components. fpcsrc is the sources of fpc and its packages and you need that for code browsing. And then finally there is the lazarus IDE itself with visual components and help files.
First issue is that none of the Package files are code signed which means you automatically have to work around Apple’s security. Not hard but still it doesn’t give you warm fuzzies right off the bat. I forget which step made me do this but I had to upgrade to the latest version of Xcode and install the Xcode command line tools.
Then there was the issue that the Lazarus downloads doesn’t included a Mac version that will run on newer Mac systems. So you end up going to the Free Pascal Compiler repo on SourceForge to get it to install.
Finally, you get to the point where the Lazarus IDE installs and then you get to the configuration screen. As you can the FPC sources can’t be found. But wait, wasn’t that part of the big three downloads I did to begin with?
In the long run no amount of reinstalling or internet searching could solve this problem. There does happen to be an entry in the ComboBox at /usr/local/share/fpcsrc and when you use that option a dialog warning you “Without the proper FPC source code browsing and completion will be very limited.” But it lets you ignore it and actually open the IDE. For now we’ll ignore that the debugger doesn’t appear to exist either.
A blank project appears including a blank form (Form1). The component library window is spread across the top of the window with 15 tabs to break it up. In the Standard tab double click on the TLabel adds it to the form. From there you can drag the control to the location of your choice.
Things go very downhill from here. The label is selected and the eight handles appear and the mouse cursor changes when hovering over them. One would think that you can simply grab the handle to resize the control. Alas, I could not with the label even though I could with the other controls. I couldn’t even change its width from the properties list.
The properties list is pretty standard. All of the properties are listed in alphabetical order which I can live with but I definitely appreciate the grouping that Xojo does (although I still prefer the older Real Studio properties list to the Xojo Inspector). Logical groupings make life easier in a properties list.
A tab control on the properties list also shows the available events for the control. If you click on the right side of the event I immediately get an error “Error: include file not found ‘typshrdh.inc'”. Um…sure. Anyway, at this point I can’t do much more without getting these setup properly.
After spending a couple of hours over the course of three days I’ve given up. My Google-Foo is pretty strong but I keep getting nowhere. The directions I’ve found are pretty minimal and I’ve done what they say I should be doing to no avail.
All of this tells me several things. The lack of documentation, particularly for MacOS, tells me that that it’s not well maintained for MacOS and I don’t think it’s used by Mac developers very much. And this is long before I get into evaluating the language and libraries that are available for it.
For ease of installation and getting that first Hello World application up and running Xojo is by far the clear winner. Look, I don’t expect an open-source project to be as easy to setup as a commercial tool so perhaps it’s not a fair evaluation. But it is one of my criteria because I have clients that take over development of their projects after we do the initial work. So if I’m having these types of problems I can’t imagine a less skilled developer having any less.
If you’re using Lazarus on the Mac I’d love here from you. Drop me a line at email@example.com and perhaps we can get me past this hurdle so I can do a real evaluation of the tool.
Xojo 2019 Release 2 arrived this week, and to say that this is a massive release would be an understatement. Among a large number of bug fixes and IDE enhancements is the first release of API 2.0. With every release I say that you should test your projects thoroughly, but in this case it needs to be mandatory.
API 2.0 is Xojo’s latest attempt to make the framework consistent across all the classes and should be easier to learn and use than the old framework. The properties, methods, and event names of practically every single class have changed. Some have changed in subtle ways, and others in a bash you over the head fashion. What might be even more important is that classes that used to set an error bit or error code will now throw an exception.
Some of the most basic things in Xojo have changed. Declaring a variable has changed from using the Dim keyword to the new Var keyword. Declaring an array is the same but resizing it is now accomplished like this:
//Declare the array
var arNames() as string
//Set it to a new size
//Clear the Array
Every Window and Control that comes with Xojo 2019 R2 has new events. Open, which admittedly can be confusing, is now replaced with the equally confusing Opening event. Close is Closing and so on. I have yet to find any direct mapping document of old events to new events and that’s a crime.
A complex control like the Listbox has dozens of events, properties, and methods and nearly all of them are renamed. Some make sense. ListBox.ListCount is now ListBox.RowCount. But ListBox.EditCell is now ListBox.EditCellAt. To append a row to a Listbox you still use ListBox.AddRow, but to insert a Row you substitute ListBox.InsertRow with ListBox.AddRowAt. I simply don’t see why AddRowAt is easier to remember than Insert (I could argue that InsertRow makes more sense).
Some changes I strongly disagree with. For example, Arrays in the old framework were simple enough to add items to:
dim arMyArray() as integer
arMyArray.Insert 0, 2000
With API 2.0 the Append and Insert methods are replaced with AddRow and AddRowAt. Again, one can argue that removing Insert and replacing with AddRowAt is simply a poor use of the English language.
Pre-API 2.0 Projects
The good news is that existing pre-API 2.0 projects will work with only a few modifications. In our projects (Task Timer, Shorts, ARGen) there were little to no changes required to get them to compile in R2. And the good news is that you can continue to use the old API in R2. The Code Editor AutoComplete will show you the old API and the new API with the old API call in Red and show you the new API 2.0 method or property.
Starting a new project in R2 will only show you the new API and events. Certainly one of the drawbacks is that Xojo projects created in R2 are not backwards compatible. Xojo has never really guaranteed that newer versions would be compatible and this is one of those cases where it’s simply not possible (theoretically if you never implement any events it will work).
My advice: Treat R2 with kid gloves and make backups of your project files before you play with it.
Let’s talk about events for a bit. I’ve already hit on the Open event that is replaced with Opening and Close that is now Closing. I find nothing wrong with the new event names, per se, but anyone with an older project, or someone taking an older class and putting it into R2 must be extremely careful. The old Open and Close (and other) events will fire as expected – until someone implements the new API 2.0 event like Opening. Once you do that the old event no longer works. This has the potential of really messing with legacy products that use the old Events and new users not knowing the difference and implementing new events and crushing functionality.
Frankly I find events to the most problematic part of API 2.0 since I, as a provider of 3rd party code, can’t enforce that a Xojo developer use the new or old events. It’s going to be a nightmare for the next couple of years (maybe forever?) as new people find old classes and implement them in their new R2 projects. Events cannot be coded out with #if statements. There is simply no way to control which events to use in a mixed environment.
If you’ve created your own control subclasses with custom events let’s hope you don’t have naming conflicts with the new event names. The only way to solve this is to change your Event definitions in a pre-API 2.0 version of Xojo.
Despite being a great idea, the Text datatype from the Xojo framework never really caught on. As part of API 2.0 many of the Text methods have been brought to the String datatype. As with all the other classes nearly every method and property name has changed in some way, shape, or form.
The biggest change, and perhaps the most problematic, is that the string functions are now zero-based. The first character of a string is zero and no longer one. The InStr method has been replaced with IndexOf (bad name in my opinion) and instead of returning a zero if the search string is not contained it will return a -1. Don’t get me wrong, this is a good change in the long run, but when developers are converting their projects from pre-API 2.0 things like this are going to bite a lot of developers as it’s not a direct replacement. You can’t just simply use IndexOf to replace InStr because it will break your code. Expect some grumbling about this from the greater community.
Date and DateTime Classes
Xojo has deprecated (not removed) the existing Date class and has created a new DateTime class. This is mostly a rehash of the Xojo.Core.Date class but it uses Strings. The new DateTime class is not a direct replacement for Date since the DateTime class is immutable. In effect if you’re doing any sort of date math you’ll need to use the new DateInterval class. The DateTime class also does not have TotalSeconds but instead has a SecondsFrom1970 property. To get a New DateTime you use the Now shared method instead of creating a new instance of it.
The FolderItem class was significantly updated on macOS and uses Apple’s more modern API’s. This should make file operations significantly faster on newer versions of macOS. FolderItem.AbsolutePath has been removed (it’s been deprecated for a while now).
Because of these changes you really need to be careful with URL Paths with query parameters. The behavior between R2 and earlier versions of Xojo has changed significantly.
The database classes have some welcome changes that have huge implications. Besides new classes, methods, and properties for everything to do with the database, any interaction with the database has the potential of throwing an exception. In the old API you had to explicitly check for the Error property. Now it will throw an exception that you have to capture and handle. This is both good and bad.
With ActiveRecord and ARGen we’ve been throwing exceptions for years when we found the database error property to be true. So not a big change for us, but for anyone that’s ever checked to see if a RecordSet is nil will be surprised when the exception is thrown. This is guaranteed to get your attention (many people never checked for the db error anyway!) but it will be a pain for many developers. Database code will need to be in a Try-Catch block, and doing this in a proper Transaction will cause some structural changes to your code.
RecordSets are deprecated. Long live the RowSet! RowSets are returned from Database.SelectSQL and instructions are passed through Database.ExecuteSQL. This is in contrast to the old SQLSelect and SQLExecute methods respectively. I can guarantee that I will mix the old and new versions up for many years to come.
PreparedStatements are no longer needed as they are built-in to the SelectSQL and ExecuteSQL statements. You no longer have to Bind the DataType and Value as the class does it for you. This is similar to what iOSSQLiteDatabase has done for years and hopefully this gives everyone more incentive to use them. PreparedStatements were a pain to use and this new method is considerably more streamlined.
One word of caution to anyone that uses the MBS SQL plugin: You must update to the 19.4 version as the database class changes required the plugin to be updated. Older versions of the plugin will fail silently and may cause other plugins to not load properly.
URLConnection received some updates. In Windows 7 and 8 it picks up proxy settings. It also no longer hangs a Windows application when downloading large files or content. In Linux a ResponseHeader that no longer exists doesn’t crash the application. They also made the ResponseHeaders an iterable function allowing the use of For-Each loops.
They (finally) added BeginTransaction to the Database class. It’s silly that this hasn’t been part of the framework for the past decade.
The Code Editor received some interesting changes. Pressing Shift-Return on an existing If-Then or If-Then-Else will now break the statement into multiple lines. On a comment line holding the shift key and pressing Return automatically adds another line of comment.
The Layout Editor has some changes too. It now has a control to switch between Light and Dark modes.
There is now a number of new Refactoring Tools available and they fixed a number of bugs in the refactoring tools. They added a new code assistant for wrapping the selected code in an #if XojoVersion block (handy with all the new API 2.0 changes). The Add Event dialog has been updated to allow adding deprecated events when a checkbox is selected (deprecated events are in red). In the same light you can right-click on an event in the Navigator and choose to convert it to the newer API 2.0 event.
The FileTypes editor and Associated File Types editor have been combined into a single editor. File Type Roles have been renamed to None, View, Edit, and Execute. For MacOS you can set if the File Type is unique to the application.
Catalina may force many developers to upgrade sooner rather than later. The SelectColor function was updated in R2 to no longer use an outdated API function. Using SelectColor with an app built before R2 will reliably crash on Catalina. The only solution is to build with R2 or use NSColorPanel yourself with declares or the MBS plugin.
Maybe I’m just an old school person and a curmudgeon but I find the lack of Old to New documentation extremely disappointing. Xojo has a Deprecated list at https://docs.xojo.com/Category:Deprecated but I find it worthless. I’d like to look at a single class at a time and have all of the events, properties, and methods showing the old name and then the new name along with any comments. I realize this is a lot of work but I’m surprised that Xojo didn’t create this documentation BEFORE doing any coding to use as their coding bible.
Any old example, sample project, old forum post, Google search result is now obsolete. BKeeney Software’s 65+ hours of Xojo training video that covers a good chunk of the Xojo framework is now practically worthless. I will be shutting the doors of the training site because it’s not worth my time (at this point) to redo over 200 videos. Xojo needs to convince me otherwise.
Deprecation Items That Have a Replacement
The Xojo IDE tries to be helpful in converting your projects to API 2.0. There will probably be a handful of things that will flag compiler errors in your pre-API 2.0 projects. If you Check your project you will get a rather large list of items that are deprecated that have a replacement. This list can be overwhelming and I recommend NOT doing global search and replace on these items because the code is sometimes quite a bit different. Good luck!
If you have an existing project I would be very carefully with R2. Sure, try it out on a *copy* of your project, but don’t expect to use R2 right away. I’m almost sure that there will be changes to fix bugs and strong community objections to certain things. We already know that Reporting and XML was NOT done for R2 and I’m sure we’ll find other things along the way too.
For developers using R2, please be patient. Get used to the question: What version of Xojo did you start with? The community is going to struggle with the changes for a while and we have no idea that his means.
All in all I think there are some good changes to Xojo 2019 R2 but I also think that there was a lot of change merely for the sake of change. I’m not convinced that all the changes were for the better. But really, only time will tell.
IDE received quite a few tweaks
Lots of bug fixes and enhancements
API 2.0 is mostly consistent with naming (with some oddities for sure)
Lots of bug fixes and enhancements
Exceptions now thrown instead of having to check for error codes
FolderItem significantly upgraded for macOS
DateTime added as a replacement for Date class
API 2.0 is not entirely done yet with more changes to come
Change for the sake of change in some cases
Exceptions for common and expected errors is not ideal
New String methods are not drop-in replacements because they are zero-based
API 2.0 event handling prevents API 1.0 events from being raised
Documentation woefully incomplete
All existing documentation, examples, videos are obsolete
What topics would you like for me to talk about with API 2.0? What do you like and dislike about API 2.0?
Markdown is a popular text formatting syntax in use all over the web. Markdown was designed to be human readable in plain text, and formatting parsers are available for many different formats.
There are a few different parsers for Xojo, available in both add-on and plugin format. Garry Pettet provided MarkdownKit for us to look at and review. MarkdownKit is written entirely in Xojo code, is fully CommonMark compliant, and generates HTML.
MarkdownKit is implemented with both String and Text versions, and is designed for both Desktop and iOS projects. MarkdownKit is provided as full source code, and includes documentation as well as examples.
With everything provided, MarkdownKit is very easy to use. It really is as simple as one line. dim sHTML as String = MarkdownKit.ToHTML(SomeMarkdownString) The output can then be passed into an HTMLViewer and displayed. This can all be done so fast you get near live rendering.
The way MarkdownKit renders the input is impressive. A MarkdownKit document is parsed into a syntax tree so that an implementation of the rendering interface can walk the document. What we get from all that is a fast and accurate Markdown renderer. And wow is it fast. The demo application really illustrates the speed of MarkdownKit.
Overall MarkdownKit has proven to be speedy, well documented, easy to use, expandable, and CommonMark compliant. MarkdownKit is a great Markdown renderer written entirely in Xojo code. If you don’t yet have a Markdown renderer in your toolkit, MarkdownKit is a solid option.