What Developer Components/Utilities Do We Need?

BKeeney Software has been doing Xojo development for a long time.  Our clients span continents and industries and when we’ve needed something that doesn’t already exist we’ve created it.  This is how ActiveRecord/ARGen and Shorts came into existence.  In both of those cases we used them internally for quite a while before making them available for others.  Some products, like Formatted Text Control, were purchased when the developer left the community and since we depended on the product we decided to keep up development on it.

The question of the day is this:  What components does the Xojo developer community really need/want that we don’t have yet?

To me, the clear winner is a nice grid component.  At one point I recommended the Einhugur StyleGrid and DataGrid controls but it was never updated for HiDPI and there are no plans to do so.  As far as I know there aren’t really any good replacements for them.  Add any suggestions to the comments below.

We use a ton of plugins but it makes no sense to have every plugin installed for every project.  We also don’t update plugins unless we have a need so a minor update to a three year old application probably doesn’t need the latest plugin.  Managing plugins across vendors is a real pain.  Likewise managing Xojo versions for client projects is a chore because one project might be on Xojo 2015 R4.1 for some technical reason while another is at a newer version (but not the latest) and some projects are on the 2017 R2.1. While it’s not hard to manage all this it’s harder managing that across multiple developers. I’d love to have a utility to manage Xojo and its plugins by project.  As far as I know there’s nothing out there that does all of this.  Do I need to write this myself?  And really, how many developers need this level of Xojo/plugin management?

What else do you need/want to make your Xojo development life easier?

Xojo.Core.Date Revisited

Geoff Perlman wrote a blog post https://blog.xojo.com/2017/11/04/get-better-dates-with-the-new-xojo-framework/ on how the new Xojo.Core.Date gives you a better date.  Better in that it does a superior job of handling timezones.

I will concede the point that the new Xojo Date class is better at timezones.  Timezones are icky and there are various areas of the world where they observe only partial increments of timezones.  The existing, global framework simply can’t handle those geographical timezones properly.  In addition to that, the global framework can get it wrong.  So the new framework is inherently better with timezones:  got it.

Where Geoff’s blog post goes sour, in my opinion, is when he talks about how the new Xojo Date and DateInterval classes cause more code but then goes on to show how it can made shorter.  I think his shortened example is indicative of the overall problem with new framework.

He starts with this example (note I am not implementing the Using keyword on purpose):

Dim d As New Xojo.Core.Date (2017, 11, 5, Xojo.Core.TimeZone.Current)

Dim di As New Xojo.Core.DateInterval

di.Hours = 3

d = d + di

MsgBox(d.ToText)

The results is a message dialog displaying:  2017-11-05 02:00:00.  This is what the old Date.SQLDateTime method returned and what many developers need for database SQL operations.

He then goes on to show that this code can be reduced to:

Dim d As New Date (2017,11,5,TimeZone.Current)

Dim di As New DateInterval(0, 0, 0, 3)

d = d + di

MsgBox(d.ToText)

Sure, it’s reduced, but now we’re passing parameters into the DateInterval constructor that we have to just know what they are.  Granted, it’s not hard to figure it out but when I’m reading code I don’t want to have to ‘figure it out’.  Whereas the first example was pretty explicit (add three hours) now I have to parse the number of parameters to figure out it’s three hours and not three days or three months or three seconds.  If when writing code I accidentally leave out a 0 it wouldn’t be immediately obvious that I’m not adding three hours but three days.  Ambiguity is never a good thing and I can’t tell you how many errors I’ve found in methods that have multiple parameters with default values because someone (usually me) missed a parameter.

I’d also argue that the documentation for Xojo.Core.Date is using, at worst, wrong example code or, at best incomplete documentation.  Using the variations of ToText results in some counterintuitive results.  If you use Xojo.core.Locale.Current (as all of the Xojo examples do), you get results based on YOUR system settings.  Really what you should be using is Xojo.core.Locale.Raw.  Below is a table that shows the differences for the following line of code when run on my macOS machine:

Dim s1 As String = d.ToText(Xojo.core.Locale.X, Xojo.core.Date.FormatStyles.Full, Xojo.core.Date.FormatStyles.None)

X = Xojo.core.Locale.CurrentXojo.core.Date.FormatStyles.Full 2017-11-05
Xojo.Core.Locale.Current Results
Format Result
Xojo.core.Date.FormatStyles.Long Sunday, November 5, 2017
Xojo.core.Date.FormatStyles.Medium Nov 5, 2017
Xojo.core.Date.FormatStyles.Short 11/5/2017
Xojo.core.Date.FormatStyles.None
Xojo.Core.Locale.Raw Results
Format Result
Xojo.core.Date.FormatStyles.Long 2017-11-05
Xojo.core.Date.FormatStyles.Medium 2017-11-05
Xojo.core.Date.FormatStyles.Short 2017-11-05
Xojo.core.Date.FormatStyles.None 2017-11-05

So given these results it’s impossible in the new framework to get just SQLDate as the FormatStyles.None is ignored.  <feedback://showreport?report_id=50242>  Until this fixed, to do this on your own you would have to split the Text on the space and use the first half of it.

The only reason why anyone should ever use Xojo.Core.Locale.Current is to display the date/time to a user.  Xojo.Core.Locale.Raw should be used for everything else.  The distinction between these variations is confusing even to experienced Xojo users so I can only imagine the frustration from newcomers.

Ultimately, the New Xojo framework is not very discoverable and this leads to frustration.  While writing this article, to figure out the parameters in the Xojo.Core.Date.ToText function, I had to look in the freaking documentation.  Yes, there is the tips area but it’s not very helpful while you’re typing.  To see what the tip is you have to stop and hover your mouse over the method.  And that only works if it’s not an overloaded method.

This leads to some users complaining that Xojo isn’t as much ‘fun’.  At first I pooh-poohed the idea but the more I think about it, it’s true.  The new Xojo framework is verbose and hard to discover and therefore not as much fun.  I work in this language every day and while calling it ‘fun’ might be a bit of a stretch I can tell you that using the new framework isn’t fun.  The two client iOS projects I’ve done in Xojo have been painful for a number of reasons and not being fun is a valid but minor point.  I don’t find the documentation to be nearly as easy to read and discover related topics, and frankly the new framework seems to make things harder than necessary.  Certainly there is a ‘this is the way I like it’ factor you’d get from someone with nearly twenty years using a language but I do feel that the new framework is needlessly nit-picky.

My first blog post https://www.bkeeneybriefs.com/2014/12/xojo-core-date/ on the Xojo.Core.Date class was in December of 2014.  It’s nearly three years later and we’re still dealing with bugs and idiosyncrasies and it’s not widely used despite clearly being ‘better’.  It’s no wonder why people don’t really want to use the new framework and I wonder if any parts of the IDE are using the new framework.

What are your thoughts on the Xojo framework?

Formatted Text Control 3.1.9

BKeeney Software has released version 3.1.9 of the Formatted Text Control, a canvas based word processing control for Xojo Mac OS X and Windows applications. The FTC is an alternative to the built-in TextArea control and allows for in-line graphics, hyperlinks, custom components, better RTF support and much more. The demo project has quite a few examples, including a Masked Text Field, XojoScript code editor example, Embedded FTC (in your own canvas), as well as the word processor with page view.

This is a maintenance release and is free for all version 3 users.  It fixes the following items:

– Fixed issue with view scale < 1.0 setting up the clipping page incorrectly (#3500)
– Fixed spelling replace on TestWindow (#3581)
– Fixed Mac text AutoComplete positioning (#3574)
– Fixed Tabstop Widths (#3500, #3576)
– Updated Linux declare for doubleClickTime to include GTK3 in newer Xojo versions (#3575)
– Fixed the Draw Control border on the right side (#3473)
– Added SpellCheck configuration testing to contextual menu on TestWindow
– Added SpellCheck configuration testing to App.Close event
– Fixed resources directory location for the the Spell Checker initialization
– Added more comments in code if plugins are missing

The Formatted Text Control costs $150 and is 100% unencrypted Xojo code. Version 3 and above requires the use of the Text Input Canvas plugin (included in package) to allow for proper text handling in Cocoa builds. Product page at https://www.bkeeney.com/formatted-text-control/

Shorts 2.0.5

Today we released BKeeney Shorts 2.0.5.  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.

New:
* PreviewCC now has a ReportFinished event
* Report Designer Help menu item that goes to the documentation
* BandType constants in PAF_PrintBand
* Datestamps in the header and footer can now be formatted individually (#3572)

 

Changes:
* Ease of installation improvements
* Code demo window order of operations, design, and reports improved
* BKS_Shorts.ImageItem constructor copies over aspect ratio boolean
* Moved the PAF_PrintKit.StylesLoad call from App.Open event to winReportDesigner.Open event
* Moved Designer Constant “Page Placeholders” (Timestamp, PageNumber, PageCount) into constants of ReportBKS
* Property list uses shared disclosure triangle drawing method now
* Property list draws backgrounds for disclosure triangle and ellipsis to fix overlap issues
* Removed workaround for 64 bit text splitting as the issue has been marked as fixed in 2017r2 (#3567)
* Removed “ReportRun” notification sent through pfDispatcher, replaced with ReportFinished event on the ContainerControl
* Removed global setting for date formatting for header and footer, fields can now be individually formatted
* winReportDesigner.HandlePrint will now properly show the printer dialog for each print, as a user expects.
* winDBConnection Password no longer a required field to attempt a connection
* Added constant to recognize, or ignore, MS SQL Server (for future release).

 

Fixes:
* DynaPDF Renderer now draws images properly in high resolution
* Enum properties in the property list no longer have empty first value (causing KeyNotFoundException when selected)
* Report Designer no longer leaves on an extra “g” when finding the app name automatically (only affects Debug environments)
* Email PDF example protected against bad SSL settings
* Constants no longer get drawn several times in the designer (#3578)
* Error properly reported if no rows are returned from a SQL error
* winDBConnection will no longer show an empty MsgBox when connecting to some database types
* Image scaling no longer refuses to scale up, this improves how low resolution images are handled
* SC_GetCount works again
* Aggregates with body rows of repeating data (i.e. 2nd row data the same as the first and so on) works properly now

For more pricing, demo versions, and training videos please visit http://www.bkeeney.com/allproducts/bkeeney-shorts/

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?

Xojo 2017 Release 2

Last week Xojo 2017 Release 2 hit the download servers. This release has the usual mix of new, changes, and bug fixes. At first blush it doesn’t seem like there is a lot to mention but there is, but I’ll get to that in a minute.

Before we get into the highlights it’s worth mentioning, again, that R2 does not have 64-bit debugging for Windows. As Xojo mentioned in their blog post (http://blog.xojo.com/2017/07/26/the-best-laid-plans-64-windows-debugging/) the LLVM compiler and toolset just wasn’t ready to be included in R2.

Despite the lack of a 64-bit debugger for Windows a number of things were corrected in 64-bit Windows builds. Icons are now applied correctly and they also show the correct version information. The 64-bit MS SQL Server database plugin now works when compiled on the Mac. Game Input Manager also works in 64-bit now. Images assigned to an ImageWell are now drawn properly.

Also related to 64-bit builds, the Split and Join functions for Unicode strings is much faster and Replace and ReplaceAll behaves like the 32-bit versions. Exceptions no longer leak memory. Virtual Volumes now work. Copying a picture to the clipboard now works. XojoScript is now available in 64-bit builds.

Linux GTK3. See Xojo blog post (http://blog.xojo.com/2017/08/15/goodbye-gtk-2-hello-gtk-3/) detailing some of the changes. The switch to GTK3 was necessary for HiDPI support and now scales automatically on integral scale factors (i.e. 1x, 2x, 3x, etc). This also lets child controls clip properly on parent controls whereas they did not always clip properly in prior versions.

Be aware, though, that this switch may affect how your controls draw. While it’s always been true that default control sizes are bigger in Linux you could sometimes cheat and use the open events (or subclass the controls) and make them slightly larger in Linux and perhaps make the system font a little smaller and things would look good enough to not require a bigger UI change. With this switch to GTK3, however, it seems like some controls, PopupMenu and Pushbutton come readily to mind, in that their caption location is definitely lower than the prior version thus making them look odd without more work. For me, what worked in R1.1 just doesn’t look good in R2.

This change begs the question that if we could make a Xojo theme for Linux that would make control heights smaller, text sizes smaller, and change the caption locations to make this a non-issue. Perhaps someone with more knowledge about Linux themes could answer that.

A few other things that might ruin your day in Linux is that not all Linux distributions now allow you to remove the border of TextFields. It wouldn’t surprise me if additional issues are found in GTK3 as time goes on.

iOS has a couple of important changes. The first is that the AutoLayout Priority property in prior versions was calculated on its own. In R2 new constraints get the ‘Required’ priority. Any existing projects should get thoroughly tested on multiple sized devices to make sure nothing needs to be fixed. In our own testing we had to simply change the priority to Required to fix any issues.

Another iOS change that may affect you is that setting the CopyFileStep to the “Frameworks” destination now properly creates the Frameworks folder inside the iOS package and puts the files there. Before you had to create a manual directory for it to work properly.

Another nice fix is that a numeric suffix is no longer added to copied iOS controls unless they need it. This was an annoying bug. Not hard to fix but annoying nonetheless.

The web framework received some attention in this release as well. The WebPage width and height properties are now correctly updated before the Shown event is fired. A number of WebMapViewer errors were fixed including an annoying JavaScript error on the first refresh and where it would fail if there was more than one instance used in the app at a time.

The Session timeout now takes touch events into account when figuring out the last interaction with the app. In addition to that, web apps now try to reconnect if they’ve lost connection to the web app and will continue to do so for three minutes or until the user navigates away from the disconnect screen.

The Listbox control received some updates. For Linux, HelpTags are now positioned properly and in Windows they disappear properly when the mouse leaves the control Also in Windows the endcap is drawn correctly and headers no longer flicker when hovered over by the mouse or when clicked on.

A regression was reported for R2 that affects dragging items to the Listbox. In Windows the X & Y coordinates are incorrect. This was reported in Feedback 49190.

New Drag events were added to the Listbox. Except for a jumbled paragraph in the release notes I’m not sure anyone would notice. I would spend more time talking about it but as far as I can tell these are not documented in the Language Reference, either local or online and there is no example. I find it inexcusable to have a major change to such an important control not be documented. This seems like it should automatically make it into the documentation. Do better Xojo!

The IDE received a bunch of bug fixes and changes. New items in the Menu Editor no longer ‘fly in’ and arrow keys work now. Long error messages are wrapped and row heights adjusted in the error reporter are adjusted as needed (as a side note does this forebode variable height list boxes?) Recent Items in the Project Chooser now show size, date created, and date modified when possible. Pressing the Escape key now acts as a “Revert Now” to changes.

It also appears that a regression bug was introduced in Raspberry Pi. Button.Action events don’t fire if using a touchscreen. They appear to work properly when using a mouse. Feedback 49221.

As always, look through the release notes to see what else has changed. It’s also a good idea to test your applications thoroughly when upgrading to a new version.

Xojo 2017 Release 2 was chock full of new things and changes. I hope a dot release is issued to fix some of the bigger regressions. Up next is 64-bit debugging and remote debugging, the new plugin format, interops, and Android. Think they can get it all done in 2017?

Sorry for the delay in getting this out. Those pesky clients sometimes want on-site help and the last thing I feel like doing is writing after a long day of coding.

 

Software Development is Fluid

Software development is fluid. Some bug fixes and feature requests that seem simple are often not so simple, or, take a lot longer than originally thought. Some that seem like they’re hard are not, or, take practically no time at all. What’s worse, is that sometimes you don’t know what the level of effort is until you start the work.

Historically, the only way to know what future feature sets will be in Xojo is attend a Xojo developers conference where the CEO of Xojo, Geoff Perlman will sometimes tell us what’s coming up. These announcements are almost always preceded with a “we expect to release that feature in this timeframe.” It’s smart because he knows that software development is fluid.

The problem is that what we hear is, ‘Release X will have this feature.’ We hear a promise despite all the hedging made by Geoff. Like every user I want that feature now and there are times that I need that feature to sell some work. I think it important to remember that when selling any work you have to use the current (and proven) technology instead of what’s coming up.

64-bit Remote Debugging in Windows comes to mind. Geoff at last years XDC said that in the first quarter of 2017 Remote Debugging will be available across all platforms. In Berlin in May he said Release 2. Well, as they said in their blog post at http://blog.xojo.com/2017/07/26/the-best-laid-plans-64-windows-debugging/ this isn’t going to happen for 2017 Release 2. Apparently the LLVM compiler and toolchain isn’t ready for primetime yet. So instead of giving us a buggy (and probably unusable Remote Debugger) they pulled it.

I understand and applaud the decision. Software development is fluid and some things are out of their control. Since Xojo is not in charge of the LLVM compiler and toolkit for Windows they are at the mercy of other developers. It stinks but that’s just the way it works.

I know that some of you will jump on the ‘let’s criticize Xojo’ bandwagon and you have every right to do so. However, keep in mind that they do hedge their announcements with ‘we plan’ or ‘we expect’ to do x by this time or this release. If we want to get any information out of them about future plans we need to cut them some slack. They have zero obligation to tell anyone about their long-term plans.

What Xojo does is magic. For a vast majority of Xojo users it ‘just works’ on every platform they target. It’s been a long time since I’ve had something work on one platform and not on another (that wasn’t my own fault). Think about it: Desktop, Console, and web apps for Mac, Windows, Linux, and Raspberry Pi just work with a simple checkbox. iOS applications are different and use the new framework but I expect Android (promised by end of year) to be very similar (if not identical in most respects). And let’s not forget 32-bit and 64-bit apps just work too despite 64-bit being a relatively new target.

Software development is fluid and every year Xojo has to deal with whatever Apple, Microsoft, Raspberry Pi, all the Linux distributions, and all the browsers throw at them. I’d say they’ve earned some slack from us users. I’d rather have a release that works than one that doesn’t (I remember some that didn’t work).

Does this mean we should stop criticizing Xojo? Pft. Please. The day I stop criticizing Xojo is the day I stop using it. It is our responsibility to keep reminding them of what we need. A long standing criticism are bugs that have been reported and have been around a long time. But yet every release has many dozens of fixes so they do fix a lot of bugs. The one’s that are hard to excuse are new features that have obscure bugs that last multiple releases.

Some of the criticism must be on us users. We don’t always report bugs. Never assume someone else has reported it. Always try to give them an example project demonstrating the bug. Xojo has some responsibility for this, too, as Feedback hasn’t always worked for some users. This is part of the give and take of a software development tool company and its users. We need them and they need us.

So yes, it stinks that 64-bit Remote Debugging isn’t available for Windows yet. And you’ll note that they’ve not said when it will be available. We can hope that it will happen for Release 3 but until the next beta round we won’t know for sure. I expect that all of their other plans for 64-bit are probably delayed too. A 64-bit IDE might be a few releases away. We don’t know what this means for the new plugin format, or Android, either. Software development is fluid so go with the flow until we see something solid.

Happy coding!

Shorts 2.0.4

Today we released BKeeney Shorts 2.0.4.  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/

New:
* Super Simple Example project demonstrates the basics of using the core classes
* Checkbox field type for boolean data

Changes:
* Various improvements to the Property List for ease of use
* Updated PrintField SerializeJSON to use UInteger in preparation for 64bit
* BKS_Shorts.Settings.kUseBarcodePlugin now defaults as False
* OrderBy is now a menu to prevent malformed data (#3519)

Fixes:
* Checkboxes in the property list are now much easier to click on Windows (#3535)
* Property list text fields no longer float when the property list scrolls
* AlternatingList now draws properly on Linux, and code was simplified
* Removed Special/Any filter on select file dialogs, this fixes selection on Linux
* Removed AutoAlias from AddField method, this was creating invalid Aliases as we changed the way we use Alias in Shorts 2.0
* Multiple fields in ORDER BY handled properly in the schema identification process (#3537)
* Report Header with PageBreak no longer adds extra headers on the second page (#3538)

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.