Automating Xojo Database Development with ARGen

Database applications are relatively easy with Xojo. The native Database, DatabaseRecord, and Recordset classes make it easy to connect, add, edit, and delete data in your console, desktop, and web applications. What we’ve found over the years isn’t that it’s hard to create these applications but that it’s tedious and also the very nature of Xojo tends to make life more complicated. Let me explain.

The Xojo database classes are very generic. To insert data into the recordset you either use an SQL Insert statement or use the DatabaseRecord class. The SQL statement, by itself if fraught with peril as it’s very easy to mistype the statement and miss it in testing. Even using PreparedStatements (which you should be using whenever possible) you can still screw it up. Using the DatabaseRecord class is more object oriented and without a doubt easier to use but it has one big problem: It doesn’t check datatypes. At design time it will happily let you try to put a date value into an integer field (depends on how you try, of course). It is not until runtime that you may get any sort error which leads to the next issue.

Database errors, at least in the global framework, do not generate exceptions. This means that unless you, the developer, check for the error, you may not get the results you expect. On an Insert statement, either using SQL or the DatabaseRecord, your data may simply never be inserted and you’ll never know it unless you’re checking the Error property on the database connection. The Error must be checked after EVERY SQL action whether that be SQL Select, Insert, or Delete. Even checking after a Prepare statement is wise to do so.

The good news (maybe) is that Xojo for iOS and the iOSSQLiteDatabase class will throw an exception if it experiences a database error. It’s good that you don’t need to check for the error manually, but now you need to put in exception handling around your database code and deal with exceptions accordingly. It’s not hard, but it’s also not trivial code either.

The IDE knows next to nothing about the database and certainly when you code it you have to query the database for Table and Field schema’s. To make it worse, the Xojo database framework has no idea about the concept of Views requiring you to query the database specifically to find and learn more about them. The IDE has no idea about the field datatypes either and the compiler can’t warn you about mismatched datatypes. These types of errors are only caught at runtime which is usually way too late in the process (hopefully not by the client either).

The database frameworks are not very object oriented friendly. If you have a simple Add/Edit dialog you need to know if the record is new, or not, since this changes how you code saving the data. New requires the DatabaseRecord object and an existing record can be updated via the Recordset object (both can use SQL statements but the statements themselves require different statements).

Xojo is easy to use but the ability to stick code in control events tends to make big database applications unwieldy and full of spaghetti code. Changing a field name in a commonly used table, or even worse changing the field datatype, is often at your own peril because you might have SQL statements referencing it in hundreds of places in the code. Forget it one place and you have an error in the waiting.

Finally, there’s the hooking your user interface up to your database code. Many people have Load/Save methods in every window/dialog/container that needs it. Use a SQL statement to get the data, then use the Recordset to load the user interface, and then use a Save method (that knows the difference between new and existing records) to put it back into the database. Again, the IDE compiler can’t help you if you make either a spelling mistake in the SQL statement or Field names so you won’t find these errors out until runtime (which is often too late).

There are options, to all of these problems. Creating your own data classes is a step above the standard Xojo code, in my opinion. You encapsulate a record into a Xojo class and implement your own Load and Save methods. This is a better object and forces some compiler warnings into your code. It also tends to put your database code all in one folder and/or NameSpace. You can use field name constants for field names, and force all db code into one class or module. Unfortunately, if you have hundreds of tables it’s also tedious to do all this.

There are other solutions out there, but ARGen takes some of the tediousness out of the work of creating a Xojo database application and does some other nifty things too like creating a basic User Interface for you.. ARGen is short for ActiveRecord Generator. ActiveRecord is a set of classes that map the database into equivalent Xojo namespaced classes.

Say you have a table named Employee. ARGen would create a class named ‘Employee’ in the ‘Data’ namespace and you would reference it in code as Data.Employee. Each field in the table is then mapped to a property in the class. The FirstName text field would be mapped to a string property named “FirstName”. This property is referenced as Data.Employee.FirstName and since the compiler knows this property is a string it will complain if you try and put an integer into it. Since there’s only one place you would ever define FirstName in your project it becomes really easy to change the name or change the datatype and then have the compiler catch any errors. It also means that AutoComplete in the code editor works meaning you’ll never mistype a table or field name again without the compiler catching it.

When an ActiveRecord project first starts up and connects to the database we call a Register method that calls out which tables/views are added into ActiveRecord. ActiveRecord scans the schema of the table and then attempts to match up every field with a corresponding property on the class. If a field is missing from your class it will generate an error that’s caught only while debugging (a “table x is missing field y” type of message).

Each ActiveRecord instance is a complete record. It has built-in Save and Delete methods. It also has events for Before and After Create, Before and After Update, to let you do things globally for each record. One example we use all the time are CreatedBy, CreatedDate fields in the Before Create event and ModifiedBy and ModifiedDate fields in the Before Update event. One place, ever, to put that data into the database rather than the potential thousands of places it might. There is also a convenient IsModified method to figure out if data has actually changed or not.

The Save method knows if it’s a new record or an existing record and does the right thing behind the scenes for you. Using a transaction, using a PreparedStatement. I think this one feature alone saves us hundreds of hours of coding because it’s a simple Save call. Nothing more be done. It really takes the worry out of it.

There are other coding features that we could get into but it all revolves around making creating database applications in Xojo fast and easy. ARGen creates a bunch of helper functions like IsDuplicate, List, and so on to help make your life easier. ARGen has a free mode which allows you to get the ActiveRecord classes and up to two tables at a time done.

For many years this is all ARGen did and we used it with great success. However, we found ourselves spending a lot of time on the next step – creating windows, dialogs, and containers and hooking up the database classes to the User Interface. Practically every table you run across has a List and Edit form. In version 2 we added the ability create a rudimentary User Interface which saves even more time. You only get this ability with the fully paid version.

When generating a Xojo project ARGen puts in a number of #pragma error statements where the developer needs to look at code and uncomment code and/or fix code. It’s hard to guess and frankly we don’t want your newly generated project to compile without you having to fix some code. Trust me – it’s better this way. There are simply too many variables and ways of doing things. Because of the #pragma error statements I like to bring over classes and UI over from the generated project as I need them rather than all at once. No need to fix hundreds of pieces of code until you’re ready to look at them.

ARGen and ActiveRecord isn’t perfect and it’s not the only solution around. ARGen lets the compiler do some work for you and eliminates some of the very common, but trivial, mistakes. It also lets you save a ton of time when it comes to standard database code and building user interfaces. It isn’t a panacea for development but ARGen can save you a lot of time and effort.

If you’d like to learn more about ARGen and what it can do for you, please download the free/demo version from the product page at http://www.bkeeney.com/allproducts/argen/. There are several videos on the ARGen menu that show more details.

Update:  I did a Xojo webinar a while back that talks about some of this in detail.  It’s a little dated but worth watching:  http://developer.xojo.com/webinar-simplying-db-access-with-bkeeney-activerecord

Shorts 2.0.3

Today we released BKeeney Shorts 2.0.3.  This is a free update to all version 2.0.x users.
Shorts is the premier reporting tool for Xojo applications.  Shorts allows a Xojo developer to embed a report designer inside in an application, view reports in any resolution, save report files to file or to a database, and to export reports to HTML, CSV, and PDF (requires the DynaPDF plugin from MBS).  Shorts works with SQLite, CubeSQL, PostgreSQL, MySQL, MS SQL Server, ODBC, and Informix (requires the SQL plugin from MBS).
Shorts comes as 100% unencrypted Xojo source code.  Please visit the product page at http://www.bkeeney.com/allproducts/bkeeney-shorts/
Release Notes:
New:
* Designer: Wrap lines without allowing the item to grow (#3419)
* Designer: Text fields can now have borders (#3486 #3437)

Changes:
* Database Type detection moved in to SQLGeneratorBKS.Generator
* Removed global PAF_DatabaseKit.bIsPostgres
* GroupItemPF.HasItems no longer counts empty text items
* Report template now only stores the database fields used (#3281)
* Designer is no longer tied to App object with constants and methods (#3487)
* Designer can now discern the app name by itself
* Designer propery list now scrolls when it’s too long

Fixes:
* Body Band Limit works (#3505)
* Line wrap drawing code in the designer now wraps properly
* SQL Generator no longer chokes on more than 2 data filters (#3501)
* Suppress duplicates no longer suppressing fields it shouldn’t
* Previewing a report in the Designer no longer briefly shows the last report run 
* Connection window no longer shows the same error message twice when SQLite fails to connect
Existing Users Should Note:
The App.AppDataDirectory, App.AppIcon, and App.AppImageDirectory methods have been moved to PreferencesModule to make Shorts easier to install. Please be aware that you may need to update the PreferencesModule.AppIcon method with your existing App.AppIcon code.
The App.kAppName constant has also been moved into the PreferencesModule. The value now comes from the PreferencesModule.AppName method, which can automatically discern the app name, or you can have it return a string of your choosing. The later approach may be more desirable if you used a value in the kAppName constant that was not the actual value of your app’s file name when built.

For best results when updating, delete the three methods and constant from the App object. This will highlight any spots you may have referenced these methods (and will need to update them)

Updates are available through FileShare and you should get a notification email.

Is Xojo the Right Development Tool

Quite often prospective clients, and developers thinking of learning Xojo, ask my opinion of Xojo.  They are about to embark on a journey spending tens of thousands of dollars on a cross-platform tool and they want to know if Xojo is a right for them.  It’s a good question and I’ll share some of what I share with them in no particular order.

Xojo is pronounced “Zo Jo”.  I can’t tell you how many times I’ve heard it pronounced “Ex Oh Jay Oh” or something else.  They just don’t know and I think it spooks a lot of people as it doesn’t exactly roll off the tongue.  Xojo has been around under various names (REALbasic and Real Studio) for twenty years – all with the same company.  At that point it’s easy to name a dozen languages/development environments that were popular twenty years ago that either don’t exist today or been sold so many times that they’re now obscure tools.

This isn’t your fathers BASIC.  Xojo uses the BASIC syntax but this isn’t like the venerable Visual Basic or even older GWBasic or QBasic.  Xojo apps are NOT interpreted at runtime – they compile down into native code for each of the platforms.  The language itself is a modern object-oriented language that happens to use the BASIC syntax.  Xojo is updated three to four times a year and has undergone a lot of upgrades in the past two decades.  It first supported 68000 code, then PowerPC and Fat applications, Carbon, and now finally Cocoa on the Mac side.  They’ve added Windows, Linux, Raspberry Pi (Linux ARM), desktop and console application targets.  In the mobile space they’ve added iOS, and by the end of the year Android.  They’re also in the middle of the transition from 32-bit only applications to 64-bit applications.  For the most part things ‘just work’ and developers don’t experience too many issues (bugs happen but think about how many targets they’re supporting!).

Xojo applications are self-contained.  Take a compiled Xojo application and (with very few exceptions) literally copy the files to another computer and the application will just work.  Even Windows applications don’t need an official installer, however, it is recommended since most Windows users are comfortable and familiar with using them.  Most Mac applications are installed via drag-and-drop from a disk image but an installer can be used on the Mac as well.  This ease-of-installation is huge and it’s rare to have “DLL Hell” issue since all required libraries and resources are bundled together.  This does make the resulting output larger than some other development tools that depend on system libraries but I’ve rarely seen this an issue.

Xojo provides nearly everything you need in one tool (with some caveats).  The Xojo IDE has Code, Form, Menubar, Database, and Report editors (to name some of the big ones) in one tool so you never have to use another tool.  We’ve found the database editor to not be powerful enough so we prefer external database editors.  The built-in reporting tool also isn’t very powerful so we created our own reporting tool (Shorts) which has served us well in our consulting projects.  The nice thing is that all of the built-in tools work seamlessly with each other so the tools that are powerful enough for you ‘just work’ with few hassles.  The editors try really hard to protect your from hurting yourself while other tools are just a big text file that must be in an exact format.

The Xojo community is incredibly helpful.  The Xojo Forums are filled with some of the most helpful people I’ve ever met.  Some of the Xojo engineers respond to questions, but usually the community answers before they get to it.  Many other support forums are rude and condescending to newcomers to their language/tool.  The Xojo forum has even been known to answer questions about other tools.

Xojo is a cross-platform tool and because of this it has some compromises.  Controls are often the lowest- common denominator.  Grids especially aren’t as powerful as some are used to in the Windows world.  This is mainly because complex grids are not common in Linux and Mac environments.  Other controls have similar issues.  Things like automatic spell checking in TextArea’s are platform specific as on the Mac.  At times it is disappointing that there aren’t more control options for Xojo right out of the box (think date and calendar controls) but thankfully there is a third-party market for controls and libraries for Xojo that can often help.  Even though much is provided for you, it’s possible for a developer to use OS API’s using Declares that can significantly modify the appearance and functionality for some applications.

Xojo is a Rapid Application Development (RAD) environment.  Between the all-in-one IDE and the language creating applications in Xojo is fast.  This means that an initial investment can get your app developed faster and cheaper than many other languages.  Obviously some of this depends on the developers doing the work but it can make a huge difference.  We’ve always told clients that if they’re not happy with Xojo performance after the initial release they can use our code as the proof of concept to the developer in whatever language they choose.  There have only been a handful of clients that have ever switched languages after release and that’s usually been switching from desktop apps to web app.

The cost of Xojo isn’t very high compared to some tools.  For $699 per year per developer you can create web, console, and desktop apps for Mac, Windows, Linux, and Linux ARM plus iOS apps.  That’s all in the same environment and same language and with the exception of iOS applications (which requires a Mac) you can use Mac, Windows, or Linux to create everything.  Many developers use third party controls and libraries and even those are relatively inexpensive.  Plus, there are no royalty fees for your Xojo made applications.  All-in-All it can be a relatively inexpensive tool.

What considerations have I missed?

MBS Berlin Developers Conference Keynote

Geoff Perlman, CEO of Xojo Inc gave his keynote address at the Berlin Xojo Developers Conference today.  The conference is hosted by Monkeybread Software.  In his hour long talk, he discussed the future of Xojo and, in particular, what’s scheduled for the rest of 2017.

In the past two years, Xojo releases have fixed over 1,000 bugs.  They’ve also add 200 major features.  This includes a new Language Reference, HiDPI support for Mac, Windows, and Web, Raspberry Pi support, 64-bit builds, and iOS additions.  Uploading in Xojo Cloud is now 400% faster and new data centers were added in New York, San Francisco, London, Amsterdam, Bangalore and Singapore.

Geoff spent some time talking about things coming up in 2017.  In Release 2, due out in July, 64-bit builds will no longer be beta status.  64-Bit debugging for Windows will be a reality.  Geoff said that it was almost available for R1 but the version of LLVM  for Windows they needed was too new.  XojoScript will be 64-bit as well.  The split and join string operations have been reconfigured to make them comparable in speed to the 32-bit versions.

For Windows, 64-bit builds will have app icons and version information.  Neither of these are available in R1 and earlier 64-bit builds for Windows.  Linux will now use GTK3 which will allow a 64-bit HTMLViewer.  A stretch goal might be HiDPI support and Geoff said that this might be later.

Later in the 2017, after R2, here are the goals:  64-bit builds will be the default in the IDE (32-bit will still be available).  The IDE itself will be 64-bit.

Also scheduled for 2017 is a new plugin format.  This new format will require Xojo Pro for creation.  It will still support libraries written in C/C++.  You can add images, sounds and other resources.

One of the more interesting things about the new plugin format is that it’s project-local.  Currently all plugins are global which means you cannot have multiple versions of the same plugin installed.  This new plugin format is project based, so it’s easier to handle different versions for different projects.  The new Xojo plugins are compiled into an intermediate LLVM format so there’s no need to ship classes with encrypted source code.

Even though the existing plugin format will be around for many years the new format is definitely the wave of the the future.  This will be the ONLY format supported for mobile.

The IDE is being redesigned.  Geoff admitted that the Navigator isn’t great for large projects and in some cases works against you.  The current Navigator is a custom canvas control and later this year it will be replaced with a standard ListBox.  This will make the next step easier and it will make tabs work as a hybrid between the old Real Studio and the newer Xojo IDE.  Geoff showed some screen mockups and design document so it felt like they know exactly what they want, they just need the time to implement it.

Next up was Interops.  Currently working with Declares is challenging.  Differing versions of OS SDK versions are hard to deal with.  There is also no type conversion.  Interops promises to make all these issues go away and use nothing but Xojo data types.

Geoff showed an example of an SDK call in Swift for iOS.  Then he showed the ugly Xojo declares for it, which didn’t look like Xojo code at all, and then showed the Interops version.  The Interops version looked nearly identical to the Swift versions.  This is the technology used to develop Android.  Interops will be developed first for mobile and then MacOS.

Finally, Geoff talked about Android.  He said a beta of Android will be out by the end of 2017.  It will be using Interops to make development easier and will create native code and controls.  Apps will be compiled into machine code which should give Xojo Android apps comparable performance as Google’s own native apps.   Support will be for KitKat version 4.4 or later which is roughly 80% of the installed user base.

Geoff wrapped up his talked with a brief look back at the competitors to Xojo when the company was first started.  Apples MPW, Microsoft Visual Basic, Delphi, MetroWerks CodeWarrior, Sun’s Java, Symantec Think C were all the rage.  Some of those tools no longer exist.  Some of those tools have been sold multiple times with different strategies.  For over 20 years Xojo has stayed with the same company and continues to evolve and change to meet the needs of users.

BKS Shorts Version 2.0

BKeeney Software (Lenexa, KS) has released version 2.0 of it’s Xojo reporting tool, BKS Shorts, today. Shorts is the premier reporting tool for Xojo desktop and web applications and comes with an integrated Designer and Viewer components to make it easy for Xojo developers to get advanced reporting in their desktop and web applications.

Within a few minutes Xojo developers can incorporate the Report Designer component in their desktop applications and create rich, dynamic reports. Grouping on a field is easy as well as creating complex queries to filter data. It’s possible to ask for query parameters at runtime so end-users can filter data how they choose. Using XojoScript it’s easy to create incredibly complex reports that can vary text, visibility, and formatting at runtime based on field values.

The Report Viewer component is available for desktop and web applications. The viewer allows users to view their reports but also can ask them for parameters for the reports at runtime. For example it would be easy to allow users to specify their own date range for their reports. Reports in the viewer are searchable and with can be configured to allow for ‘drill down’ reports.

Reports can be printed and are resolution independent. They can also be exported to PDF (requires MBS DynaPDF Starter Edition), HTML, and CSV.

Shorts supports SQLite, MySQL, Postgres, CubeSQL, MS SQL Server, Informix (requires the SQL plugin from MBS), and ODBC.

Version 2 Highlights

  • Added Report Header
  • Added Report Footer
  • Now allow database fields in Report and Page Headers and Footers
  • Rewritten SQL engine that makes reports with a lot of groups faster
  • Field aggregates (sum, min, max, average, count) are now handled by the report rather than queried.
  • Barcode Fields (requires BarcodeGeneratorMBS from Monkeybread Software)
  • Project comes with a converter for On-Target Reports
  • Numerous bug fixes and tweaks

The normal price for Shorts is $300 USD and the package is 100% unencrypted source code. Existing users receive a 50% discount and if they’ve not already received an email should contact support.

Requirements: Shorts 2.0 requires Xojo 2016 R1 and better. Windows users should avoid using Xojo 2016 R4 as there is a bug in the Xojo printing framework. Shorts works on macOS, Windows desktop environments (Linux is untested and unsupported). Shorts report viewer does work in web applications running on macOS, Windows, and Linux. Because of XojoScript 64-bit applications are not supported yet (though XojoScript can be removed to make it so)

For more information please visit the Shorts page at http://www.bkeeney.com/allproducts/bkeeney-shorts/

Xojo 2017 Release 1.1

Xojo 2017 Release 1.1 hit the web today.  This dot release contains some very important Windows framework bug fixes related to printing and is recommended for all users.  There are a few other changes as well.

For those that are trying to print reports in Xojo this release fixes some critical bugs.  First, the Printer.Landscape property is now honored whereas before it used the default printer orientation.  Second, the PrinterSetup.Setup string is now built and restored properly and works when set.  These fixes now allow reporting tools like BKS Shorts to print properly in landscape mode when restoring the PrinterSetup.SetupString.

A couple of exceptions were fixed in the IDE.  Toggling the line number display in Windows no longer disables the cursor.  You can now toggle the line numbers in IDE scripts.  Duplicating an instance of a container control no longer create an invalid control set.

It is important to recognize the value of this dot release.  For many developers this isn’t an important release but for those of us that rely on printing this was a big deal.  2016 R4 broke printing almost entirely and it was mostly corrected in 2017 R1.  Each release of Xojo brings new features and many bug fixes it’s often very difficult to revert to an older version.  So kudos to Xojo Inc. for doing a dot release.

Discoverability in Xojo

Xojo has a big API and it’s impossible to know everything. This is made even more impossible since Xojo gets updated three to four times a year and, in the past couple of years, they’ve added two new targets (iOS and Raspberry Pi) and a new framework that is going to be used more in the future.

Despite my nearly sixteen years of constant usage I find myself struggling, at times, to find things in the Xojo documentation. Don’t get me wrong, I can usually guess at the right location but I think discoverability in Xojo is lacking. I think this hurts all developers, not just those new to Xojo.

Local Language Reference: This was rewritten a few years ago and is very reminiscent of the popular documentation tool Dash. It starts with a basic landing instruction page along with the overall list of ‘sections’ and the user can either drill down in the list or use the single search field to filter the list.

The nice thing about it is that it’s fast. Type in ‘Record’ and you’ll quickly get every entry that has record in the name (it’s a lot, by the way). Each entry has a blurb on what it does, a listing of the Events, Properties, and Methods. You can click on any of these and you’ll be taken to the page for that particular item. Many entries have a notes section and example section.

Perhaps more importantly, some entries have See Also information. For example, the Recordset class entry can take you to the Database Class, DatabaseField, Database Record, etc. All things an average developer might eventually want to know in relation to databases.

What what I’ve gathered the local Language Reference is simply an extract of the wiki (below) and put into a database that the IDE accesses.

http://docs.xojo.com (the Wiki): If you’re not using the local Language Reference, you’ll be taken to the online Wiki hosted by Xojo. As far as I can tell this is exactly the same information as the local Language Reference, just shown in a web browser (or HTMLViewer if you’re using a Xojo window). This is handy for providing links to the documentation for people in the Forums, because yes, sometimes people don’t know about the Wiki.

Since it’s essentially the same as the local Language Reference it’s only real advantage is that it can be updated without a new Xojo release. The drawback, of course, is that you need an internet connection and because of this, and speed, I prefer the local version.

There were also some contributors to the wiki. If you look at http://docs.xojo.com/index.php/Special:ListUsers you’ll see the people that could modify the wiki.  I’m not sure how much this was used but I feel that this should be an important factor in documentation.  And because it’s a wiki, is there anything stopping someone from hosting a copy of this and modifying it?

http://developer.xojo.com (Xojo Dev Center): The first impression is that it’s a cleaner look since it uses a large font, has ample spacing, etc.. You have the option to save the page or the entire site as a PDF document. All of the new Xojo framework is in this format so I suspect this might be the format of the future.

Find Xojo.Crypto, for example, and the page lists a summary of the class. It lists the Enumerations, methods, related classes, platforms and project types supported, lists example projects and any related classes. Click on any of those items and you’ll be taken to the section describing it in more detail

I don’t find the new documentation all that useful. Everything about that class is in one large page rather than individual pages. It gives the documentation a cluttered and hard-to-use feel. A great example of this is selecting one of the methods and having the entire page scroll to the method. Hitting the browser back button does not take you back to the top like I expect so I’m forced to manually scroll to the top.  Not exception onerous, mind you, but harder to use than it should be, in my opinion.

I also find the notes and example sections far less complete than what I would like. And since there’s no way to add my own notes to the documentation the only option I have is to created a Feedback report to get it changed.

Creating a feedback report isn’t a great solution. There’s the right and proper way to use classes and then there are edge cases that are how real-world developers might use them. This is where the ability to ask a question and then have contributors and/or Xojo engineers answer them is helpful.

To the best of my knowledge there is no way for the community to add or modify this content. This does the experts in the community a disservice since there are times when we could add helpful information. To do this now, we need to submit a Feedback report.

New Project Pane in the IDE: The Xojo Examples directory is chock full of examples. Some better than others. Create a new project in the IDE and look at the Examples section. There are hundreds of projects to choose from but finding them is difficult. Sure, I can sometimes guess where something is, but should it not be easier? If I’m looking for FolderItem examples it sure would be nice to search for FolderItem and show me all projects that use it.  It’s a common class and I’d like to see all the examples that use it.

I found something in iOS quite by accident last week when I decided to peruse the iOS projects and found something I needed. Filter functionality would have made this trivial and it would have made my task much easier.

I don’t claim that there is an easy way to add this functionality as it simply does a directory scan. To do this type of searching you’d have to either search the projects on the fly (ew…) or come up with metadata on each project and store it in a database. This is not impossible task, and I think it would help all uses out a lot. I submitted a feedback report on this <feedback://showreport?report_id=47629>

Xojo Forums: The Xojo Forums are a wealth of information. Years worth of questions and answers make this my go-to resource for general questions. However, the built-in search is just a step above worthless and it’s sometimes easier to use Google instead to find the information that should be a simple search in the forum.

The Xojo Forum is often slow to respond and the Notifications dropdown is, for me at least, an exercise is patience as it’s so slow. It’s obvious that esoTalk does not scale properly with 314,000 posts. Perhaps it’s time to look into something more robust.
Discoverability in Xojo isn’t important for just new developers. It’s a useful and important feature for everyone since the API is too big to know everything. While there are many parts of Xojo that help you in discovering classes, events, properties and methods you didn’t know about they are scattered and disorganized. Searching is an important feature and there are times when searching doesn’t exist or isn’t as helpful as it should.

If you could make Xojo better in terms of discoverability, what would you do?

Xojo 2017 Release 1

The road to 64-bit took another step forward today with the release of Xojo 2017 R1.  This important release let’s you do 64-bit Remote Debugging for some targets with some important caveats.  It also adds the ability to Remote Debug Raspberry Pi applications.  And, as with every Xojo release there are a mix of new features and important bug fixes.

64-bit Remote Debugging

2017 R1 lets you remote debug 64 desktop, console, and web applications on macOS and Linux assuming that neither one uses XojoScript.  64-bit XojoScript is still missing in action which is preventing the IDE itself from being 64-bit.  I believe this is scheduled for Release 2.

Missing is the ability to remote debug 64-bit iOS, and 64-bit Windows applications.  Presumably iOS shouldn’t take long since macOS is already working.  From what I gather the LLVM compiler for Windows isn’t as far along as macOS and Linux so it’s taking longer to get working.

The Remote Debugger Stub has been updated to version 2.1 and now has 32-bit and 64-bit versions for Mac, Windows, and Linux, and a Linux ARM version for the Raspberry Pi.  The 64-bit version can switch between 32-bit and 64-bit correctly depending on the target setting in the IDE.

Major Changes

One of the important updates to the web framework is causing major issues with HTMLViewer controls that depend on StatusChanged events.  The web standards group decided that the StatusChanged can no longer be fired via javascript any more and the updated WebKit engine in R1 breaks code that depended on the old functionality.  For developers using Tim Parnel’s HTML Edit you will have to wait for an update before upgrading to R1.

The web framework now allows developers to use HTML in many of the controls.  WebLabel, RadioGroup, Listbox, Toolbar items, and SegmentedControl can use HTML tags in their captions.  Example:  Label1.Text = “This is a line with <raw><b>bold</b></raw> text in it.”

The Listbox has been updated for all desktop targets and now allows you to customize the disclosure widget.  This seems like an odd change.  Could this be prep work for something in a future release?

SSLv3 on Xojo Cloud services is deprecated and will be disabled on all servers in summer of 2017.

One of the new options in the Preferences is to force Standardized Format after every line.  This mirrors the contextual menu command Standardize Format which looks at the current selection and changes the case of every Xojo keyword to match it’s default.  So if you typed ‘recordset’ it will change the case to ‘RecordSet’.  It does nothing for your own variables (which would be more useful, in my opinion, and it looks like a future release may allow for that).

Also new in the preferences is the ability to change the keyboard shortcuts of all of the menus in Xojo.  If you don’t like the Remote Debugging key combination you can change it to something else.  One that I think I will change is the Build (command/control B) to something (perhaps command-option-B) since I often accidentally build once or twice a week when simply trying to paste code.

Bug Fixes

A number of Windows framework bugs were fixed.  Probably one of the more important ones is with Xojo.Net.HTTPSocket.  The socket events are now called when it is created within a thread.

Another big Windows bug fix is in Direct2D printing (broken in 2016 R4).  Font sizes were incorrectly reported by the graphics object and thus caused all printing to be messed up.  BKS Shorts (our reporting tool for Xojo) works properly in 2017 R1 when printing in Windows.

Windows received a number of important HiDPI updates.  Note that the application icon for 64-bit builds is still not being set.  One workaround is to set the associated icon via your installer.  If you want an example of how to set this via an Innosetup script, let me know and I’ll share it with you.

The IDE received a really big batch of bug fixes in R1.  The amount of them makes it impossible to list them all here, but one that’s been around for a long time is that ellipses (…) are no longer saved when creating the method signature.  That bug hits me every now and then.  For the entire list of IDE bug fixes, please see the release notes.

Conclusions

The road to full 64-bit compatibility is happening incrementally.  R1 is another step in the journey and it’s nice to see progress.  It is my hope that 2017 R2 will have Windows and iOS 64-bit remote debugging (in the iOS Simulator – I doubt remote debugging on an actual iOS device will ever happen).

Xojo has said that the Windows IDE will require 64-bit at some point in the future (even though it will still be able to build 32-bit Windows apps) and that future might be sooner than we expect.  I’m curious on how many people think this is a good or bad?

This release has some nice goodies in it.  The remote debugging for the Raspberry Pi has been awesome.  I’m working on a project right now that advanced in a number of days what had taken me months of work to do before.  The work in Windows to correct the Direct2D printing issues is most welcome and the number of HiDPI fixes is nice too.

I’ve been using R1 in regular production work for a number of weeks for macOS, Windows, Raspberry Pi, and iOS development and I’ve been pretty happy with it.  It’s been stable and I have no complaints with it.  The only thing I didn’t spend any time on in this release cycle was web.

Anything new in 2017 R1 that you are happy about?  Anything that disappointed you?

Grateful for the Xojo IDE

I use Xojo every day and it’s almost my exclusive development tool.  I’m so close to the product it is easy to see the warts of the product but in reality it’s a pretty stable and easy-to-use system that’s mostly good for beginners and experts alike.  The documentation, while not perfect is useful and the example projects are decent as well.

I came to this conclusion after a couple of recent projects have taken me into xCode and Eclipse.  Where to even begin comparing these IDEs to Xojo is challenging because they are both similar and so different than Xojo.  In xCode I was porting some iOS Objective-C code to Xojo and working with a hardware library.  Eclipse is used by my son’s FRC robotics team to develop software for their robot.  In each case I’ve wanted to pull (what’s left of) my hair out.

I guess one of the biggest differences is that sheer number of options you have in both xCode and Eclipse.  So many options, I posit, that it’s difficult to figure out what they all do, and make it hard for beginners (like I was a few weeks ago) to get going.  I don’t make any claims in knowing them any better now than I did a few weeks ago either.  I got them to work and I simply left them in that state with the hopes that no future update wipes them out.

Don’t get me wrong, I’m still not the biggest fan of the Xojo IDE in comparison to the old Real Studio IDE.  This is mainly because of the Navigator and how spastic it’s been since it’s initial release.  Thankfully it’s working pretty well in the latest releases and I find myself not swearing at the IDE much.

I also know the plan is to make the Navigator work closer to the old project tab in Real Studio.  Truthfully, I’m looking forward to it and dreading it at the same time.  I *think* it will work better than the current system but I won’t know until I use it.  And by the time we use it, it will already be too late to make any significant changes.  I dread that we’ll be faced with some awful bugs that will take time to work out and I also dread that the workflow might actually be worse than it is now.  We just won’t know until it’s put in front of us.

Are there other things that I wish the Xojo IDE did differently?  Sure.  I despise defining methods in the tiny Inspector whereas in the Real Studio IDE it took up the entire width of the Code Editor.  I also wish there were faster ways to define methods since I’m forced to use the UI to do so.  You figure after 15 years of doing this I pretty much know how to do it by now.  Alas, I have no other option than to use the UI.

Some of the other editors are like this too.  The Constants Editor requires too many mouse clicks to work right.  I want more “hands off the mouse” options.  As far as I can tell, the Menu Editor has no keyboard shortcuts as well as FileTypes editor.  In both cases, I would almost prefer a Plist type editor.

From a simplicity standpoint, though, Xojo is easy to use and doesn’t let you do too many stupid things.  I wish some other IDEs would take that approach for newbies, but then I guess their approach is to throw people into the deep end and let them sink or swim.  Xojo  tries to be helpful in that regard.

Other IDEs have some cool features.  What features would you like to see copied from other IDEs into Xojo?

Remote Debugging Enhancement Idea

Remote Debugging in Xojo is perhaps one of my favorite features in Xojo because it lets me work in the environment of my choice (macOS) and run it on any Windows, Linux, or even another Mac on my network, or in my many VM environments.  One of the things that’s always bugged me about remote debugging is the cycle time.  Every time you do a remote debug the IDE sends everything (executable, libraries, resources), again, to the remote debugger.  Even a simple change requires that the entire package is transferred to the remote debugger.  Every.  Single.  Time.

Xojo improved the cycle time for deploying web apps to Xojo Cloud in 2016 Release 4.  They did this by caching the framework and plugin libraries on the Xojo Cloud server.  When connecting to the Xojo Cloud server it tells the IDE what frameworks and plugin libraries it has and the IDE then decides what to upload.  So your first upload may take four or five minutes but subsequent uploads using the same version of Xojo take considerably less time.  In my case it’s about a minute.  It’s a welcome speed up.

In remote debugging, large projects can often take a LONG time to send simply due to their size.  I find myself debating on whether to install the IDE in that environment (along with prerequisite plugins), or to simply wait through the remote debug cycle.  Sometimes it’s a wash, but, I’ll be honest, it’s irritating to spend the three minutes transmitting to the remote debugger only to have to quit almost right away and change a label or a single line of code, only to have to sit through the transmit time again.

Why can’t they do the same thing for Remote Debugging that they did for deploying to Xojo Cloud?  Think of the time savings this change could do for someone that does a LOT of remote debugging like I do!

Time savings aside, there ARE some drawbacks.  The first is that the Remote Debugger becomes a much more complicated mechanism than it already is.  Since much of the code is (presumably) portable from Xojo Cloud to the Remote Debugger this might be a moot issue.  However, converting from whatever they’re using on Xojo Cloud (presumably Xojo) to desktop use may not be trivial.  It’s hard to say without asking that question.

Secondly, it would have to store all of these libraries and frameworks in a cache and then what would you do for cleanup?  When it quits delete these caches or keep them around?  I could argue for both ways.  Perhaps that’s a preference setting with maybe a quick calculation on how large the current cache is?

Third, it distracts from 64-bit Remote Debugging.  Maybe.  If I had the choice I’d love both, but if it meant delaying 64-bit for six months I’d rather have 64-bit now.  This is a wish list item, after all.

I created Feedback ID 46848 to get this idea into circulation.

What do you think about this idea, Xojo Developers?  What other pain points do you have with Remote Debugging?