XDC 2018: Web 2.0 Notes

Greg O’Lone at XDC gave a talk on the progress for Xojo Web 2.0.

Web 2.0 represents two years of work.  Coding started a year ago.

Goals of Web 2.0

  • HTTP/1.1 compliant server
  • Improve responsiveness
  • Modernize framework
  • New and updated controls
  • DOM processing is now done in the browser
  • Building on Top of JQuery which is a feature rich JavaScript library
  • Controls are now used with Bootstrap and FuelUX 

Adding new technologies:

Server connection monitor in the framework.  If the connection drops for a moment the browser can tell the user that comms is lost momentarily or gone forever.

Visual Session Controls:  Want to make controls available to all sessions.  Example:  Chat control and notifications that all sessions can access at the same time.

Browser History Triggers:  because users hit the back button the framework will store some session data and will allow the developer to restore states if user comes back.

Styles:  Global bootstrap theme.

Drop-in theme replacement.

Selective control level customization.

Layout Modes: Three modes are available:

  • Fixed like it is today
  • Auto layout (similar to what is in iOS apps)
  • Fluid:  the controls flow based on the size of the container

View-Based which means that all three types can be used in nested controls.

Control Goals:

  • Updated/Unified appearance
  • Keyboard accessibility
  • Theme-complaint third-party controls

New Controls:

  • Accordion
  • Audio player
  • Breadcrumb
  • Charts
  • Combobox
  • Date Picker
  • PagePanel
  • Popover
  • Splitter
  • TabPanel
  • TreeView

Existing controls getting some new features too.

File Uploader split into two parts:

  • User Interface
  • File Management & Uploader

Listbox

  • Optional Pagination
  • Dynamic datasources
  • Sortable columns
  • Built-in search of listbox data
  • Custom Column Types

Canvas:

  • JCanvas underneath
  • Layers, Events, Drag & Drop

Toolbar:

  • Bootstrap Navbar

TextField:

  • Text formatting and validation on the CLIENT side

MenuItem:

  • Theme compliant
  • Can be disabled
  • Icons
  • Separators
  • Headers
  • Hierarchical

Demo:

Data on demand Listbox.  Loading from the server depends on the latency of the connection.

Browser consistency:  Looks the same between all browsers.  Everything just kind of works.  No more differences between browsers/platforms.

Moving from old style to new Framework is a one-way operation. All controls will use the new control API’s.  Layouts will be fixed by default. 

Warning:  JavaScript and DOM hacks used in the existing web framework WILL result in errors in Web 2.0.

All WebSDK controls will need to be updated.

WebSDK 2.0:

JQuery, Bootstrap, and FuelUX on every browser.

No more User Agent parser any more.  Modernizr is being used to query for capabilities.

Encouraging the use of TypeScript Definition Files.

TypeScript is superset of JavaScript.  Compiles to ES5 JavaScript.  ECMAScript 2015 will come when IE 11 drops out of support and it will get an immediate 11% decrease in size.  Has Mac, Windows, and Linux IDE’s and maintained by Microsoft.

Clearly a lot of thought and effort has gone into Xojo Web 2.0.  Many of the deficiencies that were built in to the product from the very beginning are being addressed in Web 2.0.  Of course we don’t know when Web 2.0 will be released, but the demo’s looked fairly well developed.  I know I’m looking forward to it.

XDC 2018: Android, Xojo Framework, and API 2.0 Notes

Travis Hill from Xojo talked about the progress on Android, Interops, and the Xojo Framework and API 2.0.

Interops is being used to build the Android framework.

Interops:

  • Need something from the OS
  • Use instead of declares
  • Ready to use with Xojo types.  No need to worry about type conversion.
  • Android will be the first platform primarily built with Interops.
  • Not a separate project in another language.  Built with Xojo.
  • Anything Xojo is doing, we’ll be able to do as well.

Mapping the Android SDK into Interops.  In 2016  they had completed less than 25% of the Android SDK.  In 2017, it was about 65% and in 2018 they have considerably more than 75% but certainly not complete.

Using Interops is totally optional – like declares.  Good way to think of them is that they’re pre-existing declares.

Android is being developed using Strings and Variants and using the global framework.

Major Project Milestones:

  • 32-bit and 64-bit ARM – done
  • Linker – done
  • Position Independent Executables (PIE) is still a work in progress.
    • Can execute from any address
    • Required for Android
    • Supported on other platforms
    • Will be moving this feature to other platforms
  • Compiler
    • Native code
    • Virtual code
    • Bytecode
    • Android built with virtual code in mind
    • Building a two-way bridge between Native and Virtual
    • Mirror classes with native and virtual will be transparent to developers
  • IDE Integration:  Typically one of the last steps
    • Graphics
    • Layout editors
    • platform particulars
    • baseline project
    • Autocomplete
    • Build Settings

Requirements:

  • Mac/Windows 64-bit
  • Linux has issues so it remains to be seen if Linux will be able to do it.
  • Android Studio provides the emulator and debug tools
  • Apps use Android 8.1 (Oreo) SDK
  • Targets Android 4.4+.  Trying to hit the 80% mark

Travis showed a demo with three controls:  TextField, Button, and HTMLViewer.  Doesn’t seem like much, but is a huge amount of progress.

New Xojo Framework

The Xojo framework is dead.  Ends the split personality.  No more Xojo namespaces and no more ‘wall of code’.  Unified Language Reference (brought applause from the crowd).

API 2.0 is NOT a new framework – it’s adding to the existing one that’s been around since the beginning.  Can be added to over time with little disruption.  No requirements for everything to be present.  De-empasize/Deprecate old ones over time.

Naming Example:

Add(“Hello”)

AddAt(5, “Hello”)

Count

Remove(“Hello”)

RemoveAt(5)

New names allow for behavior updates.

Exceptions on Errors

Always 0-based offset

Easy transition

Namespaced types (Text and Auto) will be deprecated.

Classic types will get some enhancements from the Xojo framework.

String going forward.  Text will be de-emphasized and then deprecated. 

Coming to String:  ToString/FromString.

Optional Locale support.

Better default encodings from outside sources (web, databases).

Variant going forward.  Auto to be deprecated.

Implementation may change.

Date going forward.

Timezone handling and math.

Android will ship with String/Variant types.  Ship with API 2.0.

iOS adding string and variant and API 2.0 naming.

Desktop adding API 2.0.  Deprecating Xojo framework.

Web adding hybrid approach.  Will use existing web framework but API 2.0 as well.

Overall Goals of API 2.0

  • No namespaces (though we can still use namespaces)
  • All platforms consistent
  • Learn one, learn all
  • Clear naming
  • Clear documentation

I will give Xojo some credit for admitting that the Xojo framework did not accomplish what they had hoped for.  It’s clear that Text and Auto were not well received by the community despite the things they solved.  In talking with one of the engineers at lunch they will be bringing some of the good ideas from Text into String and Auto in Variant.

The downside to this change is that those developers that have spent considerable time and effort learning and implementing the Xojo framework have to convert it to API 2.0.  The plus side is that the new approach is less intrusive and more likely to be adopted by the community.

XDC 2018 Keynote Notes

Notes from Geoff Perlman’s keynote address at XDC 2018 being held in Denver Colorado.

XDC sold out a full two and half months ahead of the conference.  24% are first time attendees.  34% are from outside of the United States representing 12 different countries.

There are over 18,000 users in the forums.  That’s a 20% increase over the last XDC.  Over 43,000 conversations and 370,000 posts.

Geoff talked about the forum and the conversion to esoTalk from the old phpBB forum software.  The original developer is doing a new forum software called Flarum and the plan is to start using it in the future.

Xojo cloud continuing to grow.  Zero configuration.  Zero maintenance.  Industrial strength security.  Recently introduced new server specs (twice the server for the same price).  Now in 8 data centers.   Now has  in-IDE server monitoring.

Xojo Design Awards:

Best Developer Tool – BKeeney Shorts by BKeeney Software Inc.

Best Specialty App – Curve4 

Best Consumer App – Alinof ToDo LIst by Alain Clausen

Best Mobile App – Packr by Jérémie Leroy

Best Utility App – Server Ranger, by Gavin Smith – Liberty App

Best Cross Platform App – LehrerOffice, Jürg Otter – Roft Soft AG

Platform Landscape:

In 2016, mobile became the most used platform.  In 2017, desktop increased a bit and now the two are running in parallel.

Windows:  Now using Direct2D for drawing and printing.  With 2018 R1 is now flicker free in Windows.

Xojo Cloud:  Faster uploads.  Caches the frameworks and only uploads what’s changed.

Linux:  Gtk3 now lets us create HiDPI applications.

64-bit builds.  One of the benefits of 64-bit: They now have an optimizing compiler and apps that use a lot of mathematical operations this can make a huge difference.  One user, a professor at Cal Poly Pomona, has spent 10 years writing an app and when compiling for 64-bit he found a 7 times improvement in performance.  This is all because Xojo is now using LLVM, an open-source compiler.

The IDE is now 64-bit.  It now allows large projects to address more RAM.

A few misses since last XDC:  Interops, plugins made in Xojo.

Communication with end users:  Xojo plans 18 months in advance.  Going to stop talking ship dates.  No longer saying when a particular feature is going to ship.  Instead going to talk about what’s ‘important’.  ‘Priority’ means that are things that are in development.  Bottom line:  no more ship dates.  No change in regular releases.

What are the Priorities?

Interops:  like declares on steroids.  Android is first.  iOS next, and MacOS eventually.  Windows is tricky and it might not make sense for that platform.  Linux is even more of a wildcard with so many distributions.

Android:  working super hard on it.  They hit some milestones recently that Travis will talk about more.

Plugins made by the IDE:  Still ‘important’.

The IDE Interface:  Since last XDC been a lot of work done.  Geoff showed a demo.  Home screen is overall project overview.  The Navigator is no longer there.  Double clicking on an object takes you into the object.  Where the Navigator was is the Toolbar.  Each tab can use the Home Screen.  Geoff didn’t show the Code Editor or anything other than the Form Editor.

Web Framework:  Web 1.0 was designed in 2009 so that’s like last century.  Windows XP and 7 were the dominant Windows OS.  Mac OS X 10.5/10.6.  JQuery was immature.  Browsers not very feature rich.  And the goal at the time was to make web apps look like desktop apps.

Web 2.0:  ground up rewrite with significant modernazations and optimizations.  This will result in far greater speed between the client and server.  Overhauling 5 controls.  10 new controls.  Improved look and feel.  99% compatible with existing projects.  One of the new controls is a charting control.  Feels more web-ish and less like a desktop app.

Xojo API’s:  The original API’s designed in 1997.  Much of the current framework is the same.  Originally started with one platform.  Accumulated a lot of cruft over the years which resulted in behavioral inconsistencies.  Making changes would break existing projects.

This all resulted in the new Xojo framework to help keep Xojo modern and keep it moving forward.  Namespaces were used to avoid conflicts with the existing API.  Behavior was consistent.  Tradeoff was complexity and also created some inconsistencies.

Guidelines:

  • When to use which case
  • Intuitive identification over accuracy
  • Avoiding abbreviations and truncations
  • Enumerations should always be plural
  • Method names who’ll be verb-noun
  • Event that fire after the vent has occurred should be past tense
  • Conventions for classes that deal with list data

Found that the new API’s don’t conflict with the old ones.

Keep the current API’s for compatibility

Add new API’s for better consistency

Replaced API’s will be deprecated.

Migrate to the new API’s at your own pace

Can mix the old and new API’s

NO NAMESPACES!  The Xojo Framework namespace is gone!  Not 100% true but for the most part it is.  To clarify developers can still use and create their own namespaces but no more ‘wall of code’.

Easier transition for Xojo and for developers.

Called API 2.0

Easy to learn.  Easier for them.  Easier for developers.  All possible via API Naming Guidelines.

They’ll release this document later on so the community can use the guidelines.

Last but not least:  XDC 2019 will be in Miami, FL.  May 1st through May 3rd.  $149/night and the rate is available 3 days before and 3 days after the conference.

More info as it becomes available.

Xojo 2018 R1

Xojo 2018 R1 was released today.  It’s been over four months since Xojo 2017 R3 was released in December of 2017.  By any stretch of the imagination that’s a long time between updates.  Let’s start with the big ticket items that you’ll be relatively happy about.  2018 R1 has a ton of bug fixes, enhancements, and new features.  

Windows users will find things to be happy about as Xojo has gone way out their way to reduce flickering issues in the Xojo IDE and in our own built apps.  The magic behind the scenes is not that Xojo is using double buffered windows (or anything like it) but they are now freezing drawing in the window while it’s doing things in the background.  Thus the flicker is gone but at the price of speed.

If you’ve spent a lot of time working around the limitations of control flickering in Xojo, your upgrade to 2018 R1 won’t be a walk in the park.  A number of forum users have done considerable work figuring out the best way to get things to work well together.  The basic premise is that everywhere there is a Transparent, DoubleBuffer, or EraseBackground property you should turn them off.  I’m sure in the upcoming days a more thorough explanation of the best practices will turn up on the Xojo forums.

One thing that might really turn developers off is Feedback Case #51337 where Labels look ‘fuzzy’ and not acceptable to many end users.  This appears to be caused by the difference between the Direct2D drawing engine and the old GDI engine.  Before jumping into 2018 R1 you might want to do some testing to see if this is acceptable to you.

Printing in Windows appears to be better now as you can now print with higher resolution than 96 DPI.

The other big Windows feature to make it into 2018 R1 is the ability Debug and Remote Debug 64-bit Windows applications.  This is a big deal and required that Xojo upgrade the compiler to LLVM version 6.

In late beta testing I had issues with the Remote Debugger (from MacOS to Windows) not dropping down into the debugger and AutoComplete sometimes not working but those appear to be fixed just before the final release.  If you run into issues with either please report them as soon as possible!

The EraseBackground property is now gone for Canvas and Container Controls.  Container Controls have a new DoubleBuffer property that composites the control on Windows and allows for moving/scrolling controls with less flicker.

The Currency datatype is working properly again in 64-bit builds.  In previous builds the Currency comparisons didn’t always work and precision was lost when dividing Currency values.

A host of Windows framework bugs were fixed in the Listbox. The Val function in 64-bit Windows builds now returns appropriate values.  BevelButton captions and menu arrows now work properly when the DPI scale factor is greater then 100%.  Graphics TextUnit.Pixel is no longer treated as Point sizes when the DPI scale factor greater than 100%.  Please see the Release Notes for a complete list of Windows framework changes.

The Web framework received some love too.  The WebFileUploader control works with files greater than 2 GB in size and works with files with ampersands and apostrophes in their name.  It also supports drag and drop and now has a new UploadProgress event.  It also supports file multi-select to allow users to select more than one at a time.  It also has a CancelUpload method and a new UploadTimeout property.

The WebMoviePlayer now uses a native HTML5 video player on supported browsers (I believe this means all of them) and now has a separate Stop method.  Internet Explorer 9 support was removed.  WebMapViewer only calls into the Google Map API once per browser session.

The SQLite library was updated to version 3.22.  One of the big changes is that errors when creating SQLitePreparedStatments now get a more meaningful error messages versus the unhelpful ”unable to prepare” message.  SQLiteDatabase now supports AES-256 encryption.  The SQLiteDatabase now yields to other threads when it’s busy performing a long operation and using the ThreadYieldInterval property.

For many users the upgrade to 2018R1 will be a no brainer.  However, those that have a complex UI should do some testing in Windows to ensure that drawing speed is still acceptable.  Some beta testers found that the tradeoff of being flicker free was not worth the slower rendering speeds.

The Debugging of Windows 64-bit applications is a much needed and welcome feature.  Without much time to see it working (properly) I can’t give much of an opinion of it.  The compiling speed of 64-bit apps is very slow and it appears that incremental compiling is off.  I would expect the entire process to get better over time.

With this major milestone out of the way I hope we see considerable progress on Interops, creating plugins from within Xojo, Android, and Web 2.0 in the next couple of releases.  I’m sure we’ll find out more next week at XDC.

What excites you in 2018 R1 and what gives you some concerns?

Musings on the Xojo Framework

The Xojo framework was first introduced with Xojo 2014 Release 3 (December of 2014).  That’s when iOS was added as a target to Xojo.  Since it’s initial release it’s received plenty of bug fixes and some libraries have been added to the desktop, web, and console targets that use the new framework.  But it sure seems like there hasn’t been much news about the new framework.

If I go back into my archives and what I’ve reported from past XDC’s we were told in March 2014 the new Xojo framework would come first to iOS with it’s own version and then to console, web, and finally to desktop apps.  At the time I took that to mean that they’d be a replacement to the old global framework but, in retrospect, it’s obvious that they meant what they had done for iOS would get introduced to those targets.  That meant that the core data types, Auto and Text and the core classes, MemoryBlock, Date, DateInterval, Dictionary, FolderItem, Crypto, and so on, were available for use.

Some things like the Xojo.Net.HTTPSocket are now the ONLY way to communicate with some servers because it can handle HTTP 1.1 and supports proxies which the old global HTTPSocket can’t do.  So for some things we are forced to use the new version.  For some it’s quite a change because the old global version could do things synchronously but the new version can ONLY do things asynchronously.  Using sockets from the new framework is not a simple proposition.

There are still huge swaths of functionality that is not available in the new framework and if you need it you’re forced to either develop it yourself, or to use one of the open source projects the Xojo community has released.  While the community has been generous this goes against the modus operandi of Xojo where they’ve provided all of the basic functionality.  This is particularly vexing for newbies that know there’s a new framework but need functionality not provided yet.  And as someone who has tried having global and Xojo frameworks working together it’s not very fun.

Because it appears we’re not seeing much progress, Xojo developers are starting to get nervous and asking questions.  Is the Xojo framework a bust and will Xojo be going in a different direction?  I’m hoping that both of these questions get answered in a couple of weeks in Denver at the annual Xojo Developers Conference (XDC).

We already know that Xojo Web 2.0 will be introduced at XDC 2018.  If it’s still using the old global framework I think it will call into serious question on whether or not the Xojo framework is viable.  I mean, if you’re going to the trouble of rewriting the web framework, why not make it use, exclusively, of the Xojo framework?  If it’s not, why not?  

Well also know that we’re getting some major news for Android for Xojo at XDC 2018.  Will it use the new Xojo framework?  If not it’s a clear sign that the Xojo framework is dead on arrival.  If it is but Web 2.0 is not again I have to ask why not?  Xojo then is sending out mixed messages as far as what the Xojo framework means to their future.

XDC 2018 is going to be an important one.  We’re going to learn about the progress on Web 2.0 and Android.  Hopefully we’ll have reasonably firm targets for releases.  As part of that I really want to know what the status of the Xojo framework is what the future brings for it.

Other topics that I hope to hear about:  plugins made in Xojo, and Interops

What are your thoughts about the Xojo framework?

Does Xojo Crash On You? Try Clearing the Plugin Cache

Several people on the Xojo forums have complained about Xojo crashing on them multiple times per day.  I rarely, if ever, have that issue but I do occasionally get an issue where a compiled application will do something that’s batsh*t crazy and nonsensical.  

For example, I had some database code that was doing a simple database query where the error bit was returning true (or at least the compiled application was saying so).  I spent hours trying to figure out why it was returning an error.  I replaced the database file (SQLite) with a fresh file, ran the query in external editors, I did practically everything and finally I gave up.  I shutdown Xojo and restarted my iMac.  The issue persisted.

Finally I did my fixit option of last choice:  I cleared my plugin cache.  I restarted Xojo and voila!  The problem went away.

This happens once or twice a year for me.  We use a lot of plugins from Monkeybread and Einhugur (and others too) and switch versions of Xojo quite a bit so I’m never really surprised that this happens.  Usually when I clear the cache there are a LOT of versions listed.

The Xojo IDE has plugins that it has to compile and use so those that don’t use third-party plugins may also experience this issue.  And of course the project cache is true for everyone as well.

For those using third-party plugins, it’s ALWAYS a good idea to keep up to date.  I know Monkeybread Software has done a LOT of work recently getting ready for 64-bit for Windows and Einhugur has done a lot of work recently to support Gtk3 in Linux and 64-bit Windows. I know I’m still waiting on the Einhugur Treeview plugin so I can move a Linux project from 2017 R1.1 to something newer.  Before complaining to Xojo do your due diligence and check for newer versions!

So my advice is when things are acting weird, empty the plugin and project caches.  On macSO this is in ~user/Library/Caches/Xojo.  In Windows this at C:\Users\YOUR USERNAME\AppData\Local\Temp\ with two folders, XojoIDEPlugins, and Xojo scratch XXXX folder with XXXX being some specific number (build number?).  I have no idea for Linux (sorry).

This might not be a perfect solution but it might keep you from going crazy(er).

RAD Still Means You Have to Learn the Language

Xojo is a great development tool that is a Rapid Application Development (RAD) environment.  That’s marketing speak for you can get stuff done quickly.  The marketing speak isn’t wrong but for many people they think this means that Xojo is ‘easy’ and the learning curve is next to nothing.  I hate to break it to those developers, but it just isn’t true.  Xojo, like any development language has a learning curve.  It might be a lot less than others but there is definitely one.

The truth is that Xojo is RAD once you learn how it works.  This means you have to learn the basics of the IDE, the language, and the debugger.  And only after understanding the basics of Xojo can you start taking advantage of the RAD part.

There are parts of Xojo that aren’t so RAD.  One of those, in my opinion, is database coding.  You still need to know SQL, and use the basic database classes to read and write data into your application.  In fact, it’s so low level that the IDE does not help you, in any way, which may lead to database errors.  The IDE will happily let you try to put a string into a numeric field in the database.  What worse is that depending upon which database is used (looking at you, SQLite) it won’t complain when you do so (thankfully this is not true of all databases).

Putting data into a database using the database classes is a two step process.  One, you have to query the database knowing what the field names and datatypes are as there is no autocomplete for them.  Xojo will happily let you (try at least) put a date value into an integer at design time.  It’s not until you try all this at runtime that things fall apart.  The same is true for updating and inserting data.  These are the reasons why we came up with ActiveRecord – our database classes for Xojo.

ActiveRecord is our way of making the Xojo compiler a little bit smarter.  It maps each table to a class and the properties in that class map to the database fields.  ActiveRecord checks to make sure that all of the fields in the table are represented in the class.  If not it flags the developer.  (It does way more but this post isn’t really about ActiveRecord.)

From our experience, jumping straight into ActiveRecord isn’t all that helpful for new Xojo users.  It’s a shortcut and you’re depending on our code without understanding it and I strongly discourage it until you’ve gone through the pain and tedium of using the standard Xojo classes.  In fact, when we train new developers we ALWAYS have them do a small project using the standard Xojo database classes.

Then we train them in how to use ActiveRecord.  The setup is a bit more involved and it’s not a perfect system, but once they start using the Table/Field autocomplete and having the compiler warn about mismatched datatypes they start to understand how much faster they can code database applications.  We are consultants, after all, and time is money.

Rapid Application Development systems do NOT mean quick to learn and being able to create an application with no experience.  RAD means that AFTER you’ve learned how it works it can be incredibly fast.  Once you learn Xojo is *can* be very fast to develop applications.

Anyone disagree with this?  What is the best method of learning Xojo?  Online documents?  Webinars?  Videos?

What is the Best Font for the Xojo Code Editor?

Somehow, after working with Xojo for seventeen years I’ve never changed the default typeface for the Code Editor.  It’s not that big a deal, really, but there are times when the default proportional font causes some issues.  At times it’s hard to read the difference between i’s, l’s, and 1’s as they all tend to blur together.  There are also some issues with selection and cursor placement that are annoying.

If I can find the right font I’ll change in a heartbeat.  What do you use and why?

Xojo 64-Bit Debugging

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.

Miscellaneous:

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.

Happy Coding!

Updates

One of my goals for 2018 is to write more.  So here’s an update on stuff.

We hired a new developer who comes on board in a few weeks.  I’m really excited about his Xojo experience and what he brings to the company.

The planets and stars aligned and I will be going to XDC in Denver next month.  This makes me very happy as XDC is one of my favorite events!  I get to immerse myself in Xojo for a week and see all my friends and meet new ones.  I’m not presenting so that makes life a little easier too.

The week of XDC is going to be hectic as the weekend before as the FRC robotics team my son is on will be attending the World Championships in Houston.  Last weekend they won the Heartland Regional Tournament in Kansas City.  After a pretty disastrous first day where a lot of mechanical issues arose they had a solid last day, got picked by the 3rd seeded alliance, and eventually won the tournament (an alliance is composed of three teams) and advanced, automatically, to the championship tournament in Houston.

If you are geeky and interested in what these kids build, here is the final match where they won the tournament.  https://www.thebluealliance.com/match/2018mokc2_f1m2