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 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)?
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 support@bkeeney.com and perhaps we can get me past this hurdle so I can do a real evaluation of the tool.
I’ve been doing consulting work for over sixteen years and a vast majority of it using Xojo. During my time with my own clients I’ve tried real hard to keep them happy because I’ve always known that happy customers come back. Finding new clients takes a lot of effort.
I know I’m not the least expensive Xojo consultant out there and I’m certainly not the most expensive either. Our billing rates reflect what we feel is a good value. If our rates are too high for a prospective client I’m okay with not getting their business because it’s not worth it to me to compromise on that (and I’ve pointed them to other developers that I believe could help them). Sometimes they come back later and sometimes they don’t.
The post I linked to talks about getting ‘Customers For Life’. I’m happy to say that we’ve had some of the same consulting clients for well over ten years. I try to make them feel appreciated and that we listen to their concerns. When things go wrong we try to make it right. Some clients have left and I hope they’re happy with the new developer they decided to use. But a lot of them stayed and that makes me very happy.
As the post said it’s not all that hard to keep a customer. All you have to show is that you have their best interests at heart. As Maya Angelou said, “People will forget what you said, people will forget what you did, but people will never forget how you made them feel.”
How does this all relate to the general theme of my blog? Well, it’s no secret that I’ve been unhappy with Xojo recently. I’ve felt for many years that Xojo doesn’t court people like me (consultants and 3rd party developers) with much fervor. I’ve generally been okay with that because the product works well for what I do for my customers and if they’re happy I’m happy.
The whole fiasco with API 2.0 has left me feeling rung out and unappreciated. Many of the beta testers gave their opinion and concerns about API 2.0 very early in the R2 beta and those concerns were either ignored or dismissed. Those concerns have since been confirmed by the 3rd party developers.
If you had asked me a year ago would I be this mad at Xojo? I’d say, not a chance. After all I’ve been their customer for a long time. I’d hate to add up all the money I’ve paid them for licenses, consulting leads, and conferences over that period not to mention the number of blog posts, the many hours to create training videos, and in general promoting their product. Obviously helping them has helped my business. I’d like to think my work has helped them too.
So what happens when they lose a customer for life? We’re going to find out, I guess. I’m not going away any time soon since I’m not going to abandon my consulting clients but rather than renewing annually like I’ve done for many years I believe I’ll wait until I’m forced to upgrade for whatever reason, or they release a version I can use.
I’ll still blog about the product because that’s what I do and I’ll continue to update our Xojo products because we use them too (converting to API 2.0 is still up in the air for now). Will I start looking at alternatives to Xojo? Yes because they’ve made me feel like I’m unimportant to them. They don’t want customers for life they only seem to want new Xojo developers.
Finding an alternative to Xojo won’t be easy. Despite its warts it’s still a pretty unique product. There are lots of alternatives that don’t do something that Xojo already does, but the flip side is that there are products that do some things way better than Xojo.
Over the upcoming months I’ll start letting you know what I’ve been looking at and why. It might be illuminating and it might just end up being that I stick with Xojo because I just don’t find an alternative (I doubt this but it’s a possibility). I’m looking at the overall package from the IDE, to the language, to the 3rd party market, to the consulting market. It’s a big task.
Could Xojo win me back? Anything’s a possibility. Heck, I want to be excited about the product again. I need it to succeed for my clients to succeed. But for now, I’m satisfied with 2019 R1 and looking for alternatives.
The Xojo Developers Conference (XDC) is just around the corner. In less than two weeks Xojo developers from around the world will gather in Miami to talk Xojo for three full days. The speakers have sent in their slides and gotten feedback from Xojo and flight and hotel reservations made.
This is my favorite part of the year! Really. BKeeney Software has been around for nearly 18 years and in that time I’ve gone to many Xojo Developers Conferences including those sponsored by Xojo, sponsored by Monkeybread Software, and even held a few I helped host with the defunct Xojo developers user group.
Many of the developers that attend are my friends. Many more are colleagues, and competitors. Some are current and old clients. Some of those clients I met at XDC looking for developers for their project since there will be no greater concentration of Xojo developers on the planet!
You’d think that with as many developers conferences under my belt there would be nothing new to learn. I disagree since Xojo is always morphing into the next phase of its existence. When I started, 68k Mac apps were transitioning to PowerPC. They added Windows and Linux targets. They added Cocoa for MacOS, 64-bit builds for Mac, Windows, and Linux, the ability to create web applications, Raspberry Pi apps, and mobile applications for iOS.
I expect this year we’ll learn a lot more about Xojo for Android which will be a significant new target and make iOS that much more relevant with Xojo. We’ll learn about InterOps that aims to make adding libraries much easier for iOS, MacOS, and Android. And I’m sure we’ll see a lot about Web 2.0 that will make Xojo web applications more powerful and more robust.
At the end of the week, it’s always sad to go home. The bonds you make while sitting across the table from someone at a meal, or over drinks at the end of the day, is something that you can’t get in the forums, email, or via videos from the conference. Don’t get me wrong, the Xojo forum is one of the friendliest developers places I’ve ever experienced, but there is something truly powerful about chatting with people and being able to read their body language and talk about their developer experiences that far outweighs the convenience of the electronic venues.
If you have the means I highly recommend making it to XDC. It’s well worth it. You’ll get to meet some awesome people, learn a bunch of new things, probably see some alpha or beta of new features, and overall have a good time with your extended Xojo family.
If you’re going and we haven’t formally met, please feel free to stop me and introduce yourself. Remind me how you came to find me and what products, if any, you use. Tell me what features you like, or don’t like. Just say hi and then go talk to the many other Xojo developers there – you might just find friends for life.
Of course I’ll blog about the keynote and the cool new things that I see at the conference. See you in Miami!
The session list for the 2019 Xojo Developers Conference (XDC) was released today at https://www.xojo.com/xdc/sessions/. Take a look at this interesting list.
I’ve been attending Xojo developer conferences for twelve plus years (don’t remember what my first XDC was – maybe 2004?). Each one is unique and the topics are usually interesting but do tend to be repetitive from year to year at times. The session topics for XDC 2019 seem to be more unique than past years.
Obviously Geoff will do his keynote address and talk about what they’ve done in the past year, what they’re currently working, and what’s coming up (sometime) in the future. There is a session each for Android, Web 2.0, API 2.0, beyond Linux, everything MS Windows, and more by the Xojo staff.
What’s left is an intriguing list of sessions that will be tough to figure out what I want to attend and which ones I can wait to see recorded (assuming they’re recorded again). I can’t remember an XDC I’ve looked forward to more.
Carol is doing a session on Database Topics for Programmers and I’m doing one called “Xojo Mistakes We All Regret Later”. My alternative title is “Thankfully time travel doesn’t exist otherwise my future self will no doubt come back to murder me for these stupid programming mistakes I’ve done.”
If you’ve never been to an XDC I highly recommend it. You will get to meet some of the best Xojo developers on the planet, talk Xojo non-stop for 3 (or more) days on end, talk to Xojo staff, and have fun. Of course that last point is mostly because of the first three. You won’t find a bigger concentration of Xojo developers on the planet!
I hope to see you all in Miami in the first week of May. What sessions are you excited about?
One of the joys of doing a blog for close to eleven years is that I feel like I’ve talked about a lot of topics and people ‘know me’ fairly well. I always get a thrill when people tell me they’ve read this blog. That is so cool and I thank you for your valuable time!
As many of you know I do a quick review of every Xojo release. I often do a blurbs about updates to our own products. Occasionally I even rant about things (you should see the posts where I never hit the Publish button!).
When I had a column in Xojo Developer magazine this blog was a convenient place to discuss the ideas from the column. But writing a reoccurring column is tough. Keeping a blog going for eleven years seems to be even harder. I’ve been writing fewer and fewer posts and I’d like to change that trend.
At one point I thought about taking a topic in the Xojo Forums and talking about it in-depth here. We’ve been busy doing consulting work so I spend far less time on the forums than I used to but it might be an interesting way to generate new posts.
So, my fellow Xojo developers, what topics would you like to see me tackle? Topics can include my opinions on the future of Xojo, how’s the 3rd party market doing, why did we choose <x> or <y> over <z>, or anything in between. I’ll let you be in the drivers seat for while.
Some ground rules:
If you’re rude to me, my staff, or Xojo staff I’ll just delete the comment, ban you, and move on.
Keep it simple – this is a blog and not a magazine. Though that doesn’t mean I can’t do a multi-part blog post.
I reserve judgement to make more rules as I think of them. 😉
The latest version of Xojo hit the internet this week.Release 3 has a number of important new features, some changes, and the usual assortment of big and small bug fixes.So let’s get to the highlights!
The flashiest new thing in Xojo is that it natively supports macOS 10.14 Mojave.This means that the entire IDE (as well as all of the peripheral apps like Feedback, Linqua, and the Remote Debug Stub) draws properly when the user has Dark Mode enabled in Mojave.
Perhaps it’s my older eyes the IDE seems very ‘light’ in color in Light Mode – meaning that there’s a lot of white and grey and the contrast isn’t nearly as prominent as it was in R2 and earlier.Where some buttons have a slight 3D effect the buttons in R3 are flat with no grey background.Funny enough, I think the contrast of the IDE in Dark Mode is better.
2018 R2
2018 R3
As a long-time Mac user I’m not entirely sold on Dark Mode.Some of that is change and that I’m just not used to it yet.In some respects I feel like I’m reverting to my college PC where light text on a black screen was the norm.I guess the more things change the more they stay the same.
A new property, SupportsDarkMode was added to the Build Properties section to build apps with Dark Mode enabled.To help developers the application class has a new event named AppearanceChanged to let them know when the OS has switched between light and dark modes.
Labels, TextFields, and TextAreas running on Mojave will now use the automatic system colors to get the correct appearance on light and dark modes when text is test to opaque black (0, 0, 0, 255) and backgrounds set to opaque white (255, 255, 255, 255).In a similar fashion, FillColor, TextColor, and FrameColor now map to proper light/dark system colors.
Currently Xojo does NOT support Windows dark mode but is looking into it.A Xojo blog post suggests that Microsoft has released several API’s for dark mode and another one is due in the near future.
Incremental compiling for LLVM/64-bit targets now works.The first run can still take some time but after that it should only compile changes.This should significantly reduce cycle times on debugging 64-bit applications.
In Windows Xojo updated the text rendering so that it matches Win32 controls.I’m just guessing but if Xojo ever moves away from Win32 controls the text rendering will have to change to match.
Windows is now using the native Win32 Label control.Overall drawing seems to be significantly faster with this change.
Among the changes is one that might affect a lot of legacy projects (we have a number of these) is that drawing directly to the Graphics property is no longer allowed.To be explicitly clear about the change this does not affect, in any way, the graphics parameters passed into a canvas or window Paint event, nor does it affect getting the Graphics object from a Picture object.This only affects the graphics *property* on Canvas and Windows classes.The fact that it’s continued to work for all this time says that it was definitely time to retire this ‘feature’.
There is also a list of 79 bug fixes.Some Windows, Mac, and Linux framework issues fixed.A couple of changes to MySQLCommunityServer and Postgres.SQLite was updated.
Xojo 2018 Release 3 isn’t just about Mojave dark mode.The 64-bit incremental compiling is a most welcome feature.The speed increases in Windows drawing is also well worth the upgrade.As always, please test your projects fully before releasing them into the wild.
What is your favorite new feature, change, or bug fix?Anything causing you problems?What are your thoughts on Dark Mode and the contrast of colors in the IDE?
We use cookies to ensure that we give you the best experience on our website.OKPrivacy Policy
