Chasing Unicorns

I’ve been on the search, recently, for alternatives to Xojo.  I’ve done some basic research into Lazarus and RAD Studio and both came up short in a variety of ways that you can read about in past posts.  So what am I looking for in cross-platform development tool?  I’ll spend the rest of this post talking about some of my requirements.  

Desktop Targets

Most of our consulting work is macOS and Windows with the occasional Linux or Raspberry Pi project thrown in for good measure.  Whatever development tool I choose it needs to be able to build for Mac and Windows at a minimum and anything it can do with Linux is an added bonus.  Rarely do we get a project that is just Windows or just MacOS.  Being able to desktop and consoles apps is a must on each target platforms.  

Native Controls

Maybe it’s my Mac background but I’d like my controls to be as native as possible.  This means that when Apple, Microsoft, or Linux distribution changes their UI (again) the application will just work without requiring an update from the vendor.  I’ll be honest that this is a want-to-have option as even Xojo isn’t completely 100% native (Listbox I’m looking at you).  Accessibility is a big concern for some clients so I’m willing to forego native if it’s ‘close enough’ and works.

Mac IDE

I’m a Mac user so I’d like to stick to my platform of choice if I can.  This means that the IDE must have the features that I come to expect on the Mac (keyboard shortcuts, standard Mac text editor features, Finder integration, and so on).  Can I live with working in Windows?  Sure, but remember I’m searching for unicorns so it’s not my first choice.  Plus, having a Mac IDE is a good indication how good of a cross-platform development tool it is.  I find it laughable, really, that some companies create cross-platform applications but yet don’t have a Mac IDE.  Um…so do you *really* do Mac applications or is this a marketing checkbox?

RAD Environment

I’ve been doing Rapid Application Development using Xojo for nearly 20 years and while you could argue that parts of Xojo are not very RAD (database development I’m looking at you) it is very easy and simple to get simple applications developed in practically no time.  Just last week I was able to get a simple Mac/Win desktop application developed for a client in four hours and that included preferences, full menubar, a simple text editor, talking to a web API, all with code signing, notarization, and installers.  Some of that is experience and the kit that I’ve developed over twenty years but some of that is simply Xojo.  Xojo makes it easy to create a MenuBar and quickly create menu handlers at either the application or window level.  The integrated Layout Editor makes it easy to add events for the window and controls and automatically drops into the integrated Code Editor.  I really want the next development tool I choose to be as easy to use as Xojo so I can get work done quickly and efficiently.

As a bonus I’d like my IDE to have integrated git and/or subversion integration.  I’d also like built-in code signing and notarization if possible too.  I realize this last part might require some remote magic since only a Mac can code sign and notarize Mac applications.  Neither of these options are available in Xojo at this point and require command like voodoo or a third party utility.

Double-Clickable, Compiled Executables

I really need my apps to be double-clickable in the Finder and Windows Explorer and just run.  I should never have to start up an application with the command line nor should I have to have a runtime installed to run the application.  Xojo applications are packaged to run independently and on the Mac they are in a bundle and even in Windows and Linux they are self-contained builds not requiring anything special from the operating system (as in no runtime necessary).

Community Size and Friendliness

I’d like my new development community to large and friendly.  When I have those inevitable questions regarding my new language and IDE I want a lot of options and where the community isn’t full of jerks.  For all of its issues this is where Xojo really shines because it’s one of the most helpful and friendliest communities I’ve ever been part of.  I’ve seen the vitriol spewed in other communities when newbies ask a question that should probably be obvious.  Hey, mistakes happen, and what’s obvious to one person may not be obvious to another.

Consulting Community

I’ve spent the last two decades as a consultant so why would I stop now?  Whatever community I go to I’d like there to be a decent consulting community where an up and coming developer could make a name for themselves.  I have no problem becoming ‘certified’ (whatever that means) to get listed and to get prospective clients.

Large 3rd Party Ecosystem

One complaint I’ve had about Xojo over the years is the lack of 3rd party options for controls and libraries.  If you want reporting options, a better grid, PDF creation and viewing, database ORM options, and a whole host of other controls and libraries your options are extremely limited.  My new development tool should have a vibrant 3rd party community so I don’t have to reinvent the wheel in many projects.  I’m okay paying money for a quality controls and libraries but what I really want are options because each one is different.

Good Documentation and Examples

This seems pretty self explanatory.  The documentation should be sufficient to learn the language.  In an ideal world it would be fully fleshed out so you can get a feel for the gotchas.  As far as examples go they should just work without having to futz around fixing stuff.

Bonus Things

It can do web apps.

It can do iOS and Android mobile apps (with some of the same caveats above).

The company/community behind it has a roadmap and what they want the language and IDE to be in the long run.

A standards organization behind the language.

A large enough company behind it, or a large enough community, to ensure future new features and timely bug fixes.

The things that I’m NOT concerned (much) about

Pricing – if it works then the price is (almost) irrelevant.

Licensing – if the language, IDE, and controls and libraries let me create commercial applications then I don’t care if it’s an MIT, GPL, LGPL, or Commercial license.

So that’s my unicorn list.  If Xojo is not going to be my long-term development tool these are the things I’m looking for.  Is this an impossible list?  I don’t think so but as someone coming FROM Xojo these are the things I’m looking for.  I you have some suggestions, I’d like to hear them and please let me know what the tool does NOT have from my list above.  I know it’s highly subjective but I think it’s important to acknowledge the limitations of the language and tool you work with every day.  Like Xojo, no development tool is perfect.

Notarizing Your Xojo Apps

The release of macOS 10.15 Catalina is fast approaching. One of the new things that Apple has done in this release is increase the security even more. No longer is simply code signing your app good enough. Apple is now notarizing applications meaning that applications and disk images are submitted to Apple for their seal-of-approval that ideally have some minimum level of scrutiny that the item is not malware. Presumably this means they can identify bad actors even faster by seeing patterns. Good for consumers but it’s a pain for developers.

For those developers using Xcode it’s no big deal as it’s part of the built-in process. For Xojo developers the process is not nearly so simple. You still have to code sign your application and your disk image. We use AppWrapper from Ohanaware to code sign and notarize our apps. We also use DMG Canvas from Araelium Group to create disk images. AppWrapper can notarize disk images as well.

The process of Notarization is not as automated as one would hope. After you’ve code signed your application you have to click the Notarize button to send the application to Apple. This isn’t exactly clear but once you realize this it’s no big deal.

Notarizing requires some information for Apple. The first is your AppleID and since you’ve already code signed your application that should be a no brainer. The second is the application specific password. You can get this by logging in at AppleID account page at https://appleid.apple.com/#!&page=signin and then creating an app-specific password by choosing that option from the Security section.

The third bit of information that may be required is your short name ASC Provider. This information is not immediately obvious and your app may fail if you don’t have it. Note that the ASC Provider information is considered optional – until the process fails. Fun stuff. I had to look in the log created by AppWrapper to see this information:

Error: Your Apple ID account is attached to other iTunes providers. You will need to specify which provider you intend to submit content to by using the -itc_provider command. Please contact us if you have questions or need help. (1627)

To get your short name open Terminal and do the command shown here (this assumed Xcode 11). is your login username and is the password you created specifically for this application.

xcrun iTMSTransporter -m provider -u <AppleID>  -p <ApplicationSpecificPassword> 

This will provide you a listing of the long and short names of all of your providers. If you’re part of multiple Apple developer groups you’ll get all of them.

Voila! Once you have the short name and input into the ASC Provider section of AppWrapper and DMG Canvas my upload completed and Apple Notarized my application and disk image that works perfect in Catalina.

Hopefully this is helpful. Any other gotcha’s that you’ve seen from Catalina?

BKS Tab Control – Drag Rearrange Tabs!

Lenexa, KS (February 8th 2019) — BKS Tab Control update can now drag rearrange

BKeeney Software releases a minor update for BKS Tab Control enabling users to drag and drop to rearrange tabs. Developers can enable or disable this feature using a switch in the Xojo IDE. A new event, TabOrderChanged, is raised when the user performs a drag-rearrange.

The BKS Tab Control is a set of classes that offer developers a classic “tabs control” for Xojo Desktop applications. The Tab Control can attach to any RectControl or Window, and will maintain a relationship to this parent control if and when it changes size. Tabs can be displayed in one of four directions (North, South, East, West) and individually offer options like a close button, an icon, a background color, and can be disabled.

Other features:
  • Optional CloseBox can be positioned on the left of right
  • If the CloseBox is selected a CancelClose event is fired
  • Optional Icon can be positioned on the left or right
  • Each tab can be independently styled (colors, fonts, text decorations)
  • Each tab can be disabled
  • Tabs that overflow may be accessed with an overflow popup menu
  • Works in HiDPI, non-HiDPI, and dark modes

BKS Tab Control has been tested in macOS, Windows, and several varieties of Linux with Xojo 2018 R4 and back to Xojo 2017 R1. The control may work unchanged in older versions of Xojo.

BKS Tab Control is sold as unencrypted source code and costs $75 USD. Existing customers can download the update with the original link on their sales receipt. More information and a demo project are available at: https://www.bkeeney.com/allproducts/bks-tab-control/

2018 Was a Weird Year

I hope everyone’s holiday season was good.  We’re approaching the end of 2018 and I find it nice to reflect on what’s happened and what we’ve accomplished this year.

Looking Back

Let’s start off with the blog posts.  I did 41 (well now 42) blog posts in 2018.  Five were about Xojo releases.  Four were BKeeney Software product releases.  Four posts were about the Xojo Developers Conference.  The rest were a variety of Xojo related topics.

The most highly commented blog post was from June called Chasing Xojo where I lamented that Xojo, at least until that point, seemed to be a less stable when it came to Windows and Linux due to major revamping of the drawing systems on both platforms.  In Windows, Xojo doesn’t flicker as much but the struggle to get speed was a concern for all of 2018.  In Linux, the switch to GTK 3 wasn’t as smooth as we could have hoped.

The most viewed blog post was from August called Xojo 2018 Release 2 where I did my usual review of the most recent release of Xojo.  I heavily criticized Xojo for their poor documentation in that release.  I received plenty of blowback on that one.  But I think the end result is that R3 and R4 documentation was much better.

We released two new products with BKS Report Studio and BKS Tab Control.  Report Studio is our reporting utility meant for end-users for macOS and Windows and it was built using the award winning Shorts reporting classes (also a blog post).  The Tab Control is a canvas subclass that replaces, and extends, the built-in Xojo tab control in many ways and was our attempt at replaced the old CustomTabControl that many use but is unusable for HiDPI apps.

The other major release of the year was ARGen 3.0.  ARGen is our utility to create Xojo projects that creates ActiveRecord objects.  Among the many changes was the ability to generate ActiveRecord objects for iOS projects, supporting GUID primary keys, and the ability to include Audit Trail, Localization, and Database Update modules that help in many products.  We use ActiveRecord in practically every project and having the ability to generate some basic desktop and web UI is a huge time saver.

2018 sure seemed like a mixed bag for Xojo.  The Windows drawing issues took up a good chunk of the year and I think R4 was the first solid Windows release (although I still have 2 client apps that won’t remote debug in R4).  I can’t imagine the amount of effort that Xojo and the community put into getting Windows drawing fixed.

64-bit remote debugging became a reality for all targets this year.  64-bit compiling isn’t the huge gain that many in the community hoped for but then we always want more.  We just have to remember that 64-bit doesn’t necessarily mean ‘faster’.  At least the debugger works and that’s not nothing.

Dark Mode came soon after the release of Mojave.  The IDE works in Dark Mode and we were given many of the tools to implement it in our own projects.  Dark Mode only works in MacOS but some are already clamoring for it in Windows too.  It’s still to early to tell if Dark Mode is a hit on Mojave much less in xojo.

Looking Forward

What is 2019 going to bring us?  For one, we’re almost finished with a fairly significant update to Formatted Text Control and after that’s released we’ll start with an even bigger version 4 update to the venerable word processing control to bring it up to date and extend its capabilities to make it even more powerful.

We have a number of large consulting projects that have been in gestation for many months and years.  It will be nice to have a big project or two to keep us busy.

With the release of Web 2.0 I will redo all of our Xojo training videos related to web.  They’ve been outdated for a while but it’s not worth redoing the videos until Xojo releases Web 2.0.  If they release Android I’ll start on at least some intro videos for that too.  This might finally be the year that I redo the remaining Real Studio videos.  No doubt I’ll redo them just before a major IDE change.  🙂

What do I expect from Xojo?  That’s a tough question to answer since they’re so damn secretive now.  I expect Web 2.0 to show up in time for XDC (so maybe release 2?).  I think it will be pretty solid in the first release but it wouldn’t expect it to be good until the following release.

I also think that at XDC we’ll get an alpha of InterOps but not anything other than another dog and pony show for Android.  Targeting another platform is long and tedious process and involves some serious IDE work.  How much of the iOS editors can they use?  I can only guess but at first blush I say not much.

Some of Android’s success may hinge on getting iOS to use the global framework and away from the Xojo Framework.  Nothing like rewriting an entire framework while keeping backwards compatibility.  The more I think about it the more I think the iOS rework is put on hold until Android is released.  

Which leads to API 2.0 in general.  We’ve already seen some of the first new controls to use API 2.0.  URLConnection was introduced in 2018 R4 with mixed success.  I would expect more API 2.0 controls to show up.

So what do you think?  Was 2018 a successful year for Xojo?  What do you see happening in 2019?

Xojo 2018 R3

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.

Since there are many OS colors available than what Xojo provides natively, you might want to look at CSTrueColors by Ulrich Bogun at https://drive.google.com/open?id=1vg-sN8_7mz18zeu9XoRWZaBc8Tm-_Enb.  

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?

BKS Tab Control

Lenexa, KS (June 20th 2018) — BKeeney Software releases BKS Tab Control
The BKS Tab Control is a set of classes that offer developers a classic “tabs control” for Xojo Desktop applications. The Tab Control can attach to any RectControl or Window, and will maintain a relationship to this parent control if and when it changes size. Tabs can be displayed in one of four directions (North, South, East, West) and individually offer options like a close button, an icon, a background color, and can be disabled.
Other features:
— Optional CloseBox can be positioned on the left of right
— If the CloseBox is selected a CancelClose event is fired
— Optional Icon can be positioned on the left or right
— Each tab can have a different background color
— Each tab can be disabled
— Each tab text can be stylized with font, font color, text size, bold, italic, underline
— Tabs that overflow the available width may be accessed with an overflow popup menu
— Works in HiDPI and non-HiDPI modes
BKS Tab Control has been tested in macOS, Windows, and several varieties of Linux with Xojo 2018 R1.1 and back to Xojo 2017 R1.  The control may work, unchanged, in older versions of Xojo.
BKS Tab Control is sold as unencrypted source code and costs $75 USD.
More information and demo project download available at:
macOS
Windows
Linux
All Directions

ARGen 3.0

BKeeney Software Inc. is proud to announce that ARGen, our ActiveRecord Generator utility for Xojo developers, has a new major update.  Version 3.0 includes a host of new features including the ability to generate ActiveRecord classes for Xojo iOS projects, the ability to use GUID primary keys, the option to include a database update module, include an audit trail module, and include a UI localization module.  There are also new ways to arrange your user interface layouts that can save you even more time when initially creating a project.  In addition to these major new features, ARGen fixes a number of bugs and provides more enhancements.

ARGen has versions for macOS and Windows.  It costs $99.95 but can be used in limited mode at no cost.  Existing version 2.x users will be provided an upgrade opportunity with a 50% discount or they contact us at support at bkeeney dot com to get an upgrade coupon.

Pricing, examples, and more details can be found at the project homepage at https://www.bkeeney.com/allproducts/argen/

3.0 Release Notes:

New:

* iOS ActiveRecord!

* Reorder fields in the order they should be displayed. This would work both on List and Edit forms.

* Name labels for generated UI elements

* Switch between horizontal and vertical alignment for UI fields and labels

* Projects can now have individual Namespaces

* GUID support (except for ODBC connections)

* Can now include a Database Update module

* Can now include an Audit Trail module

* Can now include a Localization module

* Warnings for aggregates that conflict with Xojo (note below)

* New database connection window

* New app icon

 

Removed:

* Oracle databases are no longer supported

 

Fixed:

* Add / Edit dialog now shows in web version (#3556)

* Icon now displays properly in alerts (#3474)

* PostgreSQL Views now working

* Control init on add and edit windows

* Preferences now correctly handles prefix and suffix settings

* Selecting suffix no longer causes a compile error

* Confirmation dialogs are now set up properly (#3643)

* MenuBarVisible is no longer false on any template windows (#3475)

* Rescan Schema works again

 

Changed:

* Database specific PreparedStatements

* Instances of MsgBox replaced with MessageBox (#3474)

* Enhanced Save() on add and edit windows

* Listbox.Open() now has a ColumnWidths placeholder for convinience

* Desktop projects now created with HiDPI on

* Desktop projects now default to 64 bit for Mac

* Opening a SQLite project automatically attempts to connect (#3596)

* Auto-Generate UI step is now easier to understand

Aggregates Note:

When using aggregate like Count(), Max(), Min() some DBs will return the aggregate as the field name.

Added code to warn on open project that there is invalid for xojo field names, and fail generate. 

Serial Devices as Keyboards – Yuck!

We’ve recently had a number of projects that required the use of a serial devices in desktop applications.  In all cases the clients said the devices are, “easy to use,”  since they act just like a keyboard.  If our experience is typical then I’d hazard a guess that many Xojo developers are frustrated with them.

Several projects required the use of barcode scanner.  Having a barcode scanner work as a keyboard makes sense, I guess.  It means that it can work with literally any application, anywhere, any time.  All it needs is focus on a text field and whatever the scanner sees it puts into the control.

In another project we had an ultrasonic sensor that would take the application out of idle mode and present the user with purchasing information.  Again, it acted just like a keyboard which means it works with any application as long as you had focus in a text field.

If you happen to know WHEN this information is going to come in it’s not so bad as you can plan for it.  Putting the focus in a field and waiting for information is easy.  It’s not so easy when that information could come at any time.  Of course all of our applications had data that could come in at any time and we had to be prepared to act on it immediately.

If you rely on a TextField or TextArea getting this information the rest of your interface can really suffer.  It means that when your barcode/sensor field loses focus you have to get it back (or you lose information).  Do you do this right away or wait a few seconds?  And if you have a complex user interface how do you deal with tabbing between controls, or even simple things like a user changing a checkbox because the focus is lost on your TextField?  It can be a nightmare to try and figure out and get right.  The differences between Mac and Windows and Linux can be frustrating!

The answer that we ended up implementing was putting the barcode readers into serial mode.  I’ve not run into a barcode scanner yet that couldn’t be used in serial mode.  Every scanner has a gazillion different modes and properties (all set via barcode of course) and one of them is to make it appear as a serial device to the computer.  On Windows this is a COM port and on the Macintosh they tend to show up as a USB Modem.  If I had to guess I’d say it’s harder getting barcode readers that are Mac and Linux compatible.

Once it’s in serial mode it’s almost trivial to create a class that monitors the serial port and reads the data WITHOUT needing the focus in a TextField.  The class then distributes the data to the objects that can consume the data.  What I do is have the window or objects register itself with the class and then when the data comes in the class sends it to all registered objects.  Each of the objects has an Interface with a simple HandleBarcode method.  This is known as the Observer Pattern and there’s an example that ships with Xojo.

My ultrasonic sensor wasn’t so easy to overcome as it couldn’t be put into serial mode.  However, it did come with a Windows-only SDK (thankfully it was a Windows only project) and with a little help with Declares we were able to get it working so we could tell if someone had walked up to the device and when they had walked away.  I’m not sure what we would have done if it had been a Mac or Linux project.

Serial Devices are relatively easy to work with in Xojo (as long as they show up in the serial list).  Having to deal with devices that act as keyboards not so much.  I’d highly recommend trying to get them to work as serial devices and save yourself a ton of grief.

What’s been your experience with serial devices in Xojo?

Xojo 2017 R2.1 and Updated Roadmap

I’ve had a hellacious travel schedule the past six months so I apologize that I’ve not been up to snuff on Xojo news. Last week Xojo 2017 Release 2.1 was made public and earlier this week Xojo CEO, Geoff Perlman, penned a blog post about the short-term roadmap for Xojo. Let’s dig in!

First, the 2.1 release has a mere 16 bug fixes in it. This dot release fixes some critical Linux, and Windows bugs. A few IDE bugs were addressed and the PostgreSQLDatabase plugin was updated. Many of these bugs won’t affect everyone but it’s definitely worth upgrading from R2 if you have not already done so.

Now on to Geoff’s short-term roadmap. You can read the entire blog at https://blog.xojo.com/2017/09/19/the-short-term-xojo-roadmap/. To summarize it in a nutshell: 64-bit is taking them longer than expected.

To this I say, ‘Duh’. Anyone who expected 64-bit to be done by this time hasn’t been around very long. Xojo has consistently blown their estimates for most (all?) of their big projects. The transition to Cocoa from Carbon took a lot longer than originally announced. iOS took longer than expected. The introduction of the Xojo IDE from the Real Studio IDE was also delayed (as a side note I’m still amused at the accusation that I personally caused a 6-month delay in the Xojo IDE due to a blog post).

The point isn’t, ‘Oh my gosh, Xojo has yet another delay’ it’s that Xojo is very bad at estimating this stuff. Some of this is on them but some of it is beyond their control. Supporting mac OS, Windows, Linux, iOS, Raspberry Pi, desktop, console, and web apps is a mammoth undertaking. I am constantly amazed at the magic Xojo performs without my knowledge. To me it ‘just works’.

Apple, bless their hearts, changes things on a whim every year at a minimum (sometimes even more often than that) and causes Xojo to play catch up. And they usually do this with little notice. The current change being that the iOS Simulator will no longer support 32-bit apps so guess who has to scramble to make it work now?

Linux distributions seem to change daily. Xojo has to scramble to catch up with those changes too. They recently updated Xojo to use GTK3 and that was a big deal. They sort of had to do this upgrade because GTK2 was pretty long in the tooth. I can only imagine the internal efforts they did for testing.

Windows doesn’t change much for better and worse. The technology from ten years ago still works but that’s not necessarily the best ‘modern’ approach for Windows. Many users complain about flicker when windows are resized. This is a valid complaint but because Windows does not double-buffer their windows like Mac and Linux the older Win32 controls flicker like mad under many circumstances.

Regardless, 64-bit is the roadblock for other things. If you were hoping for Android, interops, or plugins compiled in Xojo to be released in 2017 you’re out of luck. This is what happens with a small development team. There simply isn’t enough man-hours to work around delays in some projects. This happens in ALL software development products but with a small team this impacts everything.

The only bit of good news from Geoff’s blog post is that the Windows framework is getting a big update. This update will ‘dramatically’ reduce flicker according to Geoff. No word on what exactly they’re changing though a thread on the forums from Aug 9 might give a little clue. Changing transparency seems like a little thing but perhaps they plan on implementing a double-buffering scheme. Until we find out more it’s not worth speculating. It seems like this new scheme might make it by the end of this year. So either this has been in the works for a long time or it’s not huge from a coding standpoint.

Promising services based on a product feature that doesn’t yet exist is dangerous. If you were promising Cocoa, iOS, or 64-bit versions before they were actually released you did your customers a disservice. I remember one XDC where a database ORM (Object Relational Model), similar to ActiveRecord, was shown with a lot of interest by those attending. I’m still waiting on it. The lesson is to not depend on vaporware!

So what are your thoughts on R2.1 and the Short-term Roadmap?

The Xojo Community is Awesome

Have I told you how much I love the Xojo community?  I’ve been part of it for fifteen years and I’ve met hundreds of Xojo developers at developers conferences and probably exchanged emails with thousands more.  I am amazed at how much this community helps each other and I wish there was a way to promote that as a key feature of the product.  It’s a big deal.  Really!

If you’re just starting out using Xojo know that there are a bunch of people, myself included, that are willing to help out, if we can, on your journey.  Programming is hard.  Well, I don’t think it’s hard because I’ve been doing it for so long, but it is complex at times and that makes it hard.  Just ask your question in the Xojo forums and you’ll almost always get an answer within hours.

Even Xojo pros, such as myself, have need of help.  Xojo covers Mac, Windows, Linux desktop, console, and web apps.  It does iOS apps for iPhone and iPad.  It now does Raspberry Pi for heavens sake!  It works with dozens of different databases.  There is simply no way any one person is going to know everything there is to know about Xojo.  It just can’t happen.  So yes, I go to the forums, all the time, and ask for help.

Just the other day I asked for some help with WooCommerce.  Not Xojo related, really, but certainly related to a project we’re working on for a client.  Within a few hours I had half a dozen developers private message me saying they might be able to help.  Subsequent contact narrowed that list down a bit but the point is that I have probably shaved off several days worth of work simply by asking for advice.

I am biased towards Xojo, naturally, as it’s been my primary development language for fifteen years.  I think I’d be hard pressed to find such a friendly community.  I call many on the forums my friends even though I’ve never physically met them.  The few that I’ve met in person have lived up to their forum reputations and are really friends for life.

So maybe this is my belated Thanksgiving post.  I am thankful that so many years ago I jumped both feet first into the tool.  I asked questions – many of the silly and redundant.  I became more proficient and then made another jump to start blogging about it, making products for other developers, and training the next generation of developers.

So if you are in need of a cross-platform development tool I highly recommend Xojo.  It ain’t perfect but no development tool is.  If you jump in I think you’ll love the community.  I know I do.

What say you fellow Xojo developers?