We’ve migrated a couple of projects to 64-bit and for the most part I’m pleased with how Xojo handles it. It’s pretty seamless and it just works. I can’t ask for anything more. Additional observations:
The lack of Windows 64-bit debugging makes life difficult. This appears to be corrected in 2018 R1 (in beta now) so that will be a most welcome change from having to go old-school and use logging to debug my Windows applications. 64-bit debugging in macOS and Linux works just like 32-bit applications.
There is no incremental compiling, yet, in Xojo. This makes the debug cycle much longer than we’re used to with 32-bit applications. When you debug a macOS or Linux application the dialog is quite clear that incremental compiling is off so there’s hope that the next step in this process is to get incremental compiling working.
The 2018 R1 beta cycle has taken a long time. Presumably the level of effort to get the LLVM compiler working for Windows 64-bit debugging was painful. And now that it appears to be solved hopefully all the other goodies on the plate (interops, Android, web 2.0) can all proceed at a good pace.
I had an instance the other day in 2017 R3 where Target64bit didn’t work. After struggling with it for a while (because it should have worked) I deleted the plugin cache and restarted Xojo and voila! It started working again. I wish I had a better way of diagnosing stuff like this.
I’m a big fan of the Einhugur Treeview control for several reasons. First, it’s very fast with the ability to LockDrawing. Second, since nodes are persistent you don’t have to go to extra lengths to manage your nodes as the user expands and collapses nodes. Load them once and they’re there for the duration. It’s a good option, in my opinion, for really fast development work.
The only drawback I have with the TreeView control is that it’s not compatible with Gtk3 yet. According to Bjorn it won’t be until this summer. This means any Linux projects using it will have to stick with Xojo 2017 R1.1 until it’s updated.