« MBS FileMaker Plugin … | Home | The Last Xojo Black F… »

Xojo 2021r3 release

The new Xojo release showed up and it brings us over 130 bug fixes, 40 changes and and a few new things. While part of the team is hard at work for Android to come in a later release, other engineers had plenty of time working on a lot of little things:

  • We got an update on the WebKit library for Windows, so a few websites may no longer complain about older browser engine.
  • The PDFDocument class learned a few more tricks like transparent colors and form fields.
  • Windows got a kind of dark mode. While Win32 doesn't really support it, Xojo got a lot of custom drawing code in to realize it.
    When the Windows framework gets rewritten with modern UI controls in the next years, it will go native for dark mode. See Roadmap.
  • You can now build MacOS apps on Windows and Linux. This once again makes Xojo a real cross platform tool again for desktop. Still customers will need a Mac to do testing, code signing and notarization.
  • The Crypto module got new functions for Blowfish, Twofish, AES and CRC functions.
    If you needed this before, you had plenty of choices with several plugin and declare libraries. The plugin still may offer more and do it threaded.
  • Some bigger companies may be happy to see iOS Enterprise signing works now.
  • The OSHandle data type for declares sounds handy to avoid conversion between ptr and Integer for handles. But since it's implemented as an extra class, I prefer to do a cast if needed or just change the declare to take integer/ptr instead of using a new class.
  • Running Xojo inside Windows for ARM sounds great. Seems to work fine for my copy of Windows 11 on MacBook Pro within Parallels.

With this release we got new Desktop controls. They are a result of the API 2.0 direction Xojo went a few years ago. Changing existing controls didn't work well and now Xojo Inc. found a different way: They duplicated the existing controls, renamed them all with Desktop prefix, applied their new way of naming things (RowCount vs. ListCount) and renamed events, e.g. Opening vs. Open. Now we have for example

  • WebLabel for web
  • DesktopLabel in addition to Label and the ancient StaticText for Desktop
  • iOSLabel for iOS
  • MobileLabel for iOS and Android

The library in the IDE may show you those controls without the prefix, so we got a bit of unification and you Drag & Drop a button to a layout on all targets.

You may wonder why they added new controls to introduce their 2.0 API naming. Well, it looks like they didn't want to or couldn't implement alias names for the compiler for that. While we now have "Dim" to define a variable, Xojo Inc. added "Var" as an alias for it. The parser part of the compiler can read both and get internally the same token for compiling. I suggested years ago to do that for events. Like you could have Opening as event name and Open as an alias. Implement either and you get an event. Internally the compiler knows both names reference to same object. So you could have a control define Opening and you have Open implemented and RaiseEvent Opening would call Open. A bit confusing, but over time people may just rename theirs events. For that I would have suggested a context menu to update event names for a control or a while window. The alias system would have made a seamless transition as you could just use old names and the compiler map them to newer ones. Same for RowCount vs. ListCount.

You may wonder why Xojo doesn't have a Label class implemented three times. You can mark classes to be available only for some targets in Xojo. At least plugins can register something to be only available for Web, iOS, Console or Desktop. Tturns out the compiler isn't that smart for built-in classes. While you can't use the desktop Listbox class in web app, the namespace still contains it. The compiler may complain about you naming a class e.g. Listbox. The IDE nowadays prevents you to name the class in the first place with one of the internal names. But you may have noticed, that in a console project the web classes show in auto complete.

For myself, I will probably ignore the new desktop classes for quite some time. If I drop a new control from library to a window, well, it may be a new desktop control, if the window is a DesktopWindow in a new project. To get the older classes, I may have to create the project in an older version. I hope the new and old classes share implementation so a change or bug fix will go in both and they will not divagate in features over time. There will be confusion if people log a bug to Listbox and the bug is actually in DesktopListbox. We'll keep an eye on it.

You may get trouble when you mix API 1 and API 2 desktop controls. If you have a new DesktopWindow vs. old Window, you may see complains about the MainMenuBar being either old or new API and not match to the window.

If you analyze your projects, you can check the Analysis Warnings dialog to disable annoying warnings about deprecated desktop controls. This may bring you to the same level as older Xojo versions with the number of deprecation warnings.

Beside that we recommend the new release to everyone. It contains a lot of nice goodies for various groups in the community and it looks like Android may get into an early beta testing later this week. Enjoy!

18 11 21 - 16:34