BKS Shorts Version 1.7.0 Released

pens128BKeeney Software is pleased to announce a new release of BKeeney Shorts, their Reporting tool for Xojo.  BKS Shorts allows users to embed a report designer into their desktop applications and render reports onscreen, to a printer, as well as to HTML, CSV, and PDF formats (PDF requires a DynaPDF license). Web applications can render reports to HTML, CSV and PDF Formats.

Version 1.7 is an extensive update with a new, faster, file format.  Users with dynamic queries can now put a summary of selections in the header.  Dynamic queries that use popup list selections can now make them optional.  And much, much more.  Complete change list below.

BKeeney Shorts Product Page:  http://www.bkeeney.com/allproducts/bkeeney-shorts/

BKeeney Shorts costs $300 and is shipped with 100% unencrypted Xojo source code.

New Features:

  • Added SupressField property to Fields. This will keep rows with identical text to the row above it from displaying. Resets on each page.
  • Added ?? shortcut to Header/Footer bands to be able to put report parameters into the report. Feedback appreciated.
  • Added check upon opening reports in the designer to see if all fields in the report are still valid.
  • Now provide an error message to user if there were any errors while generating report.
  • Added a Version field to the report to make it easier for future file format changes. New file format is 1. Added a conversion routine to convert to version 1.
  • The Property List now has a dedicated popup menu for Date fields.
  • The Query List Dynamic queries can now be made optional to ‘select all’ for that field.


  • Now provide feedback to the user during report generation. This will give rough estimates of numbers of rows created.
  • When switching back to Design view we now make sure the thread generating the report is killed if still running.
  • Major rewrite to the DBWrapper class to make it much more effecient.
  • PAF_QueryCondition made part of the PAF_DatabaseKit and renamed to PAF_DatabaseKit.QueryCondition
  • Reports will save the DefaultStyle from the StylesList.
  • Added some Localization strings into the object list.
  • Removed the Contextual Menu from the Property List format item. Only used for Dates and it now has dedicated Date Popup.
  • Added a WaterMark to two of the Coded reports.

Bug Fixes:

  • Fixed issue where Grand Summary bands weren’t working.
  • Views are now properly vetted through the TableViewAddCheck.
  • Rescanning the schema will refresh the object list properly now.
  • Can no longer drag a report objects (from the Report section of the Object List) into the designer. Now you can only drag fields and report primitives.
  • Repeat Each Page and Page Break are now only valid and displayed for group headers.
  • Adding/Removing items from the Designer now updates the Report Objects section of the object list.
  • Fixed wording in the Band Editor.
  • Background Text Color now saved properly in Style editor.
  • Pressing Enter/Return while in the Properties List will update the object in the Editor.
  • Fixed issue with report time in Report Footer if user had never set format in preferences.
  • Fixed issue with line objects not calculating their top/right property properly.
  • Fixed a date conversion issue when formatting the dates to other than default.
  • Fixed mouse handling and drawing issues when the canvas width was smaller than the page width.
  • Fixed Report window Title not showing on initial save of report in designer.
  • Fixed odd random Nil Object Exceptions when updating from the property list.
  • Fixed the WindowMenu class to work with multiple menu bars used in the project.
  • Fixed issues with the IsFunction property when generating reports.

Xojo Windows Application Runtime Requirements

One of the strengths of Xojo is that it creates a no requirements executable package.  For Mac OS X it puts all required libraries and resources in the application bundle and for Windows and Linux it puts all the necessary files into the Libs and Resources folders.  This makes installing your apps on Windows and Linux pretty easy because you did not need an installer (however it’s highly recommended you use installers!).

Screen Shot 2016-04-20 at 2.58.37 PMXojo 2016 Release 1, however, has a new requirement that is biting some users fairly hard.  Some Windows 7 and 8 users get an error staying that it can’t start because it’s missing the api-ms-win-crt-runtime-l1-1-0.dll.  This error is because Xojo Windows framework was updated to use the latest Microsoft tools which means the “Universal C Runtime”.

This new runtime is shipped with Windows 10 and should be part of a fully updated Windows 7 and Windows 8 installation and because of this Xojo is not distributing the DLL when they build an application.  The past few months have shown us that many people do not automatically update their systems.  It’s pretty easy to replicate this behavior in a VM environment.  Simply do the base install of Windows 7 or 8 (doesn’t matter if it’s 32 bit or 64 bit) and without doing the hundreds of updates required to bring that version of Windows up to date, run a Xojo application.

There are three solutions to this problem.  First, have the user do all of the available Windows Updates which should install the runtime.  The second, is to have the user download the runtime installer from Microsoft.  The third option, is to add it to your installer.

Screen Shot 2016-04-20 at 2.59.02 PM

We use InnoSetup for creating our Windows installers.  Xojo has conveniently added the redistributable to the Xojo download package so we can use it.  Look in the Extras/Windows Runtime/Installers/ directory to find these installers.  Adding this into your installer is relatively painless.

In the [Files] section of your Innosetup script, add the following line:

Source: “VC_redist.x86.exe”; DestDir: {tmp}

Then, in the [Run] section, add this line to have it installed automatically:

Filename: {tmp}\VC_redist.x86.exe; Parameters: “/install /quiet /norestart”; StatusMsg: “Installing 32-bit runtime…”; Flags: waituntilterminated

This is a no fuss way to add it to your installer.  It only adds about 14 MB to your installer.  Most users will never see it because they’re up to date.

I highly recommend that you peruse the PDF provided by Xojo on this topic at Documentation/WindowsUniversalRuntime.pdf.

In our testing installing the new runtime has not caused any issues.  The clients that have had this added for them have reported no issues either so I think it’s pretty safe.  Some Xojo forum users, however, have reported that their Windows installation will hang when trying to install the Runtime.  Have you experienced any issues with the runtime?

Changes at BKeeney Software

BKeeney Software, Inc. is proud to welcome Tim Parnell as the newest addition to our full-time staff.  Tim will be working on several high profile client projects for BKeeney in addition to lending his skills to all of the BKeeney products.

Tim has been writing software for nine years and is known for his work on MacDust and with TinyGrab and MacHeist.  He has also been active in the Xojo community with his HTML Edit and Answers products and is an active contributor in the Xojo forums.

Bob Keeney, Vice President of BKeeney Software said, “We’re excited about bringing Tim on board.  His experience with web technologies in addition to his Xojo skills enhances the mix of services we can offer to our clients.”

BKeeney Software, Inc is a consulting and software development company that has been around since 2002, specializing in Xojo application development.  BKeeney offers Xojo training, tutorials, source code and developer products.  www.bkeeney.com

Views are Your Friend

One of the challenges I see regularly in my work as a database administrator is finding a way to bridge the gap between the well-normalized physical implementation of a database behind an application and providing a way to make the data available in an easy-to-use (and understand) fashion for the end user.  For many clients this means letting them design their own reports.  Database views are my go-to method for making a complex database structure easy to use for end-users and even developers.

Views have a number of advantages.  For one, they are available in all SQL databases, including SQLite.  Views allow you to reduce the complexity of the end user experience by managing and limiting the data presented.  This might mean taking a very complex query joining multiple tables and presenting it in a single table with the end user (or developer) not needing to know the gory details of the SQL behind it.

This last point is important for the developers too.  Having the programmers figure out the complex joins for a query pulling from multiple tables is sometimes challenging and not always a good use of their time.  Having the Xojo application do all that work for a complex query is sometimes painfully slow.  Views not only speed up the development process but make the Xojo application more efficient since the database has already created the view and optimized it internally.

Views are more secure since you can limit the data shown and control who has the rights to view it.  By giving users and developers access to the underlying tables you may be exposing sensitive data.  Views are an easy way of sanitizing data.  We use views as read-only constructs so the user cannot update the data (note:  not all databases treat views as read-only).

Views can be created, modified and deleted via simple SQL statements.  The syntax of the statements (in particular for modifying views) varies a bit from database to database but the details can be easily found.  To create a view, the syntax is:

    CREATE VIEW viewname AS

SELECT (fill in your query here)

We recently used views implementing a large customer records management (CRM) system for an insurance broker.  Their database has around 100 tables containing information on customers, policies, related products, agent and commission data.  The data is normalized and it isn’t always straightforward to get related data.  The client does not have a dedicated IT staff and reporting is the primary responsibility of a part-time administrative employee, “Jane”.

Our goal was to provide Jane with the easiest means possible to write any report that was requested by management.  While Jane has some knowledge of databases and foreign keys, she isn’t technical and doesn’t have any training on the SQL language.

Our answer was to use our desktop reporting tool, BKeeney Shorts, customized to only show her views created solely for reporting.  (We did this via a simple naming standard in the database.)  She is presented with options such as:  Agent Commission, Prospect Contact and Client Policy Details.  If she needs an additional view, it’s easy to add it to the database and not impact the Xojo code behind the application. (It doesn’t require a recompile and redeployment of the software).

The view incorporates the calculations behind the data, so the reports are always consistent in terms of things such as how commission checks are calculated or who is the primary agent for an account.  By using views we ensure that consistent results are shown to the end user even if someone else is assigned to write reports

Views provide a level of abstraction between the database and the end user and we find  them very useful.  For the developers, it means they don’t have to figure out the complex queries and have the Xojo application create inefficient and complex queries.  Views are your friend!

Shorts Report Designer 1.6.2

pens128BKeeney Software is proud to announce Version 1.6.2 of BKS Shorts with Report Designer, our reporting classes and tool for Xojo.  Shorts allows you to integrate a report designer into your own Xojo desktop application.  Desktop and Web applications can generate reports.  Both versions can export to PDF if they have the MonkeyBread DynaPDF plugin.

This is a free update to all existing users.  This version fixes a couple of important bugs and is recommended for all users.  In this version we also added a CSV Renderer that allows you to export your reports to CSV in addition to HTML and PDF.

Product Home Page:  http://www.bkeeney.com/allproducts/bkeeney-shorts/


  • Added a CSV Renderer that can export reports to CSV format ignoring page headers and footers.  (Note: CSV Export isn’t perfect. We’re just taking the text and putting it in a file.)
  • Added CSV Export into the File->Export Menu to give example.
  • Added Chinook Invoice Database Example.
  • Added ability to get exception messages back from the Report Thread.


  • Tightened up the spacing in the dynamic DateTime container.
  • Did some prep work in the Designer and in ReportPF to allow fields in the header in a future release.

Bug Fixes:

  • Fixed Formatting of page numbers so it can go up to 4 digits.
  • Fixed loading of Schema and Views in the report viewer.
  • When opening a report the view switches automatically to the Design View.
  • Fixed an issue where adding ? to the Filter Data (thus making it a dynamic runtime variable) would not get saved without unchecking and checking the dynamic checkbox in the list.
  • Fixed issue with Lines line staying put in proper location in the Designer.
  • Fixed issue where adding a Field in the Header of the report would cause what appeared to be an infinite loop (really was an exception in the thread). Now it will finish the report.

There is No Easy Button

Most of us want an easy button when it comes to software development.  Out of the dark ages when you literally had to code everything yourself came the frameworks that did a lot of the dirty work for you and all you needed was to figure out what those framework calls were.  Tools like Xojo make this even easier because the framework has been around a long time, well known and documented, and mostly complete.  Add in the rise of internet searching and it’s quite possible to find huge chunks of code that do what you want.  Be wary, though, because that convenient piece of code you just found might have bugs in it.

The reality of programming is that any code that you didn’t write should be considered suspect.  That’s not the same thing as saying Other Peoples Code (OPC) is wrong, it might be perfectly safe to use, but you really should vet the code and thoroughly test it before putting it into your application.

I’ve seen it on the Xojo forums where someone whips out some code from memory and it contains a bug or simply doesn’t work.  The person asking the question then gets mad that it doesn’t work.  Normally the bug is simple to fix but it’s obvious that in many cases the developer getting mad didn’t even attempt to read any documentation.  Come on, people!  If it was that easy, we’d have created AI’s to do the programming by now.

Really, in the long run, you need to understand what you’ve copied.  Maybe it looks right on screen but it is horribly optimized, or worse.  Maybe it calls into the netherworld and summons Cthulhu.  Anything is possible, right?  Do you want to be responsible for the software Armageddon in your company?

Much of the example code given on the internet is lacking defensive coding for the sake brevity.  This can lead to runtime exceptions that can cause needless headaches.  If I had a $1 for every Xojo programming that’s wondered why their Recordset is coming back nil and not checking for database errors I’d could probably buy an enterprise license of Xojo every year.

It’s been my experience that any code you find you will have to tweak it (either a little or a lot) to fit the business requirements of your application.  If you don’t understand the code you’ll never be able to figure that part of it out.  Learn the individual bits of code and learn how to use the debugger for heavens sake.  The Xojo documentation has some great information.  The debugger is your friend!

When it’s your own code that you’re copying and pasting (especially in the same project) it’s a very strong indicator that you should refactor your code.  Perhaps making a global method or making a helper class makes sense.  That’s actually a good time to ask the forum on the best strategy because you’ll probably get two or three different responses.  Learning new techniques is good and in the in long run those will become new tools in your arsenal of programming tricks.  And remember that in a year or two you’ll look back at your coding today and be embarrassed (this is natural) because you’ve learned SO much since then.

There is no easy button when it comes to software development.  Even with RAD tools like Xojo you need to learn the language and the framework to bend it to your will.  Sure, use OPC as a way to learn how parts of it work but copying and pasting verbatim without learning why it works is a recipe for disaster.

Happy Coding!

Xojo 2016 Release 1.1

Xojo 2016 Release 1.1 hit the web today and this version should be the one you’re using from now on.  This dot release fixes a number of critical and important things.

First off, web app compile times just got much better.  Building a 64 bit Linux web application went from five minutes in 2016 R1 to just three minutes in 2016 R1.1 (both versions had to recompile the plugins so take two minutes off that for an average time). This is a marvelous and unexpected surprise in R1.1.

The Web Page Layout editor that was a dog in R1 is much improved.  A complex web page with multiple containers and controls is now nearly flawless when dragging controls around on the page.  This one feature alone is the worth upgrading to R1.1.

The MySQL plugin no longer crashes when a closing the database connection.

BMP’s with a mask dragged into a Linux project long longer throws an out of bounds exception when the app is launched.  Xojo.Net.HTTPSocket was also updated.

In Windows, the SaveAsDialog no longer returns the wrong name if anything in the file path has a period in it.  Xojo.Crypto.RSAGeneratePair no longer crashes.  The new Language Reference no longer has high CPU usage and the Windows IDE no longer crashes when a remote debug app quits.

Besides the web page editor, the IDE also received a few fixes.  Perhaps most important is that searching the project no longer results in a crash for some developers.

Read about all of the R1.1 changes in the release notes.

All-in-all R1.1 is a welcome version and I recommend that you update to it immediately.  What do you think?

Shorts Report Designer 1.6.1

pens128BKeeney Software is proud to announce Version 1.6.1 of BKS Shorts with Report Designer, our reporting classes and tool for Xojo.  Shorts allows you to integrate a report designer into your own Xojo desktop application.  Desktop and Web applications can generate reports.  Both versions can export to PDF if they have the MonkeyBread DynaPDF plugin.

This is a free update to all existing users.  This version is mostly a bug fix release and is recommended for all users.

Change List:

  • The Footer Constants can now also be used in the header
  • Refactored DesignCanvas and ReportPF and moved some of that code into PAF_DatabaseKit.DBWrapper where it makes more sense
  • Loading a report into the designer, or for rendering, will no longer re-read the schema and overwrite any manually created relationships
  • Added Tables and Views section into the report definition file
  • Fixed an issue with report width/height not being remembered correctly. Changed from using PrinterSetup string which is not cross platform safe to use the dimentions instead.
  • Fixed issue where landscape reports weren’t being exported properly to HTML and PDF.
  • Added breaks in the PreparedStatement creation to help in debugging.
  • Added some missing field handling to ODBC
  • DBWrapper will no longer create a missing SQLite Database.
  • Fixed UI in winDBRelations

ISA and Casting

One of the things that’s just not talked about much in the Xojo documentation unless you know where it is located is object casting.  ISA and Casting is so useful it’s worth devoting some time talking about it.

Let’s start with some common examples in desktop applications.  We all use the Window class.  Typically our new projects start with an instance of the Window class called Window1.  To put it another way, the Superclass of Window1 is Window.

The ImplicitInstance property of windows is subtly evil.  Subtle because if you reference anything in Window1 it gets created if it’s not already.  A lot of new Xojo developers will ask how can they tell if a window is open or not.  They’ll often come up with something like this:

if window1.visible then return true

If window1 is not open this line will actually create it!  So this is a bad thing and why I recommend that you turn off ImplicitInstance on all windows until you understand the implications.  I digress.

The better way to tell if an instance of Window1 is open is to iterate through global Window method.  You can do that by doing something like this:

for i as integer = windowcount-1 downto 0
   dim w as window = window(i)

This will iterate through every window, visible or not, that the application has created.  I used DownTo because many times you want to close said window and going UP will cause funky things to happen to your array of windows (I will leave this as an exercise for yourself).

If you put a public property in Window1, say, s as string.  You cannot do the following:

  for i as integer = windowcount-1 downto 0

dim w as window = window(i)

if w = window1 then
   w.s = "this is text"


The compiler will squawk with an error:  Type “Window” has no member names “s”.  This might seem mysterious, but the window returned from the Window array is a Window, not the subclass window1.  It’s an important difference.  The framework call to Window brings back a listing of all Windows even though each individual window brought back will be a subclass.  The array must all be of the same class type (Window) for it to work so the framework uses the Super.  To work with the Window1 properties you have to cast the window returned to an instance of Window1.

If you only have one window type (highly unlikely in a real app) you could simply cast any windows to window1 but that’s unrealistic.  Instead, you need to check what type it is first.  Using the ISA operator you can test what kind of window subclass it is.  If w is an instance of Window1 than you can do something with it.

  for i as integer = windowcount-1 downto 0

dim w as window = window(i)

if w isa window1 then
   //Do something here


The next step is to cast the window to the subclass.  This is as simple as wrapping the window variable, in this case w, with the name of the subclass, Window1.

  for i as integer = windowcount-1 downto 0

dim w as window = window(i)

if w isa window1 then
   window1(w).s = "Some Text"


If your code is wrong, or you try to cast it the wrong window type you’ll generate an exception at runtime that says Window1 cannot be cast to whatever the object you’ve put in.  For example, the following code generates that error:

  for i as integer = windowcount-1 downto 0

dim w as window = window(i)

if w isa window1 then
   window2(w).s = "Some Text"


This type of paradigm is common throughout Xojo.  We already know about the Window and WindowCount methods.  Another commonly used one is the Control and ControlCount on a Window.  Code like this happens quite a bit:

  for i as integer = 0 to ControlCount-1

dim c as control = control(i)

RectControl(c).Visible = False


This works fine as long as your control is actually a RectControl.  Not all items returned by the controls method are RectControls. Checking with the ISA operator before casting is important.

The ISA function and Casting can be an important tool in your application.  It can take what would be some tricky Introspection and turns it into a trivial piece of code.  It’s also one of those things that you don’t know you need it until you need it.

We Are Part of the Problem

For some users, Xojo 2016 R1 hasn’t been a great release.  Some Windows users are experiencing frequent crashes.  For others (myself included), working in the WebPage Layout Editor is an exercise in frustration because it’s unusably slow.  We blame Xojo, but we, the beta testers, are culpable for these problems as well.

Before you start angrily sending in comments hold your horses.  R1 had a really long beta cycle.  Clearly, Xojo had issues with figuring out HiDPI for Windows and their work isn’t finished yet (hence the beta tag for HiDPI in Windows).  It happens and some times you have to ship an imperfect product.  We always have the option of NOT using the latest version of the product.

Some will say that Xojo shouldn’t have released R1 in the state that the Windows version was in.  That’s only partially true.  Xojo uses their own product all day long to create their product.  They, more than many of us, see the warts in their product and I know they try really hard to eliminate as many of those as possible.  But they use it differently than we do so I wouldn’t expect them to find every bug.  That’s where we come in.

The beta program exists so we can bang on the product using our own real-world projects.  It’s up to us to find and report the fringe cases and use the product in different ways that what the IDE expects.  I know that in this beta cycle I was swamped with consulting work so I only fired the betas up occasionally.  So whatever problems there is on me and on everyone else in the beta program that didn’t test.

I will grant you that the only incentive we have for participating in the beta program is a less buggy product.  For some that’s enough but when you’re busy trying to get your own products out the door there’s not much incentive to work even more and find bugs for someone else.  In my opinion, this has always been the problem with the beta program.

Some of use are also guilty of not starting testing until the Final Candidate releases.  This is actually the worst time to start testing because it means only show-stopper bugs will get fixed.  We really need to start testing with the early beta’s.  That’s when Xojo needs us the most to bang on their product.  Is it fun?  No.  Is it necessary? You bet because waiting until Final Candidate is worthless to them.  To us too, because those bugs might not get fixed for 3 months.

Did Xojo help us out in this cycle?  No.  There were times they were putting out a new beta every day.  Sometimes with only a couple of changes from the previous version.  I would download a beta with the intention of working with it and before I could get to it a new beta would be announced in the next couple of days.

I don’t know about the rest of the people in the beta program, but the high frequency of beta releases meant I looked at them less.  I don’t know why but it was.  I saw the announcements rolling in and I shrugged in apathy.  Perhaps I felt the frequent releases didn’t properly value my time.  I only have so much time to devote to beta testing and the frequency was off-putting.  I like to use a version for 3 or 4 days (or until I find a major bug a report it).  With so many releases I just didn’t test.

I propose that with the next cycle Xojo limit their public builds to once a week (maybe a Thursday or Friday release).  This respects my time a bit more since my only incentive is to make it a better product.  Frequent public releases says that they’ve not vetting their product enough before giving it to us.

I also think there needs to be something in place that identifies what type of beta tester we are.  Are you mostly a Windows user?  Then Windows specific changes get highlighted for you because you’ll be most likely to see them.  Same with Mac OS X, iOS, and Linux users.  Desktop, console, and web app users might also be a designation.  I realize this doesn’t fit in with the current generic “hey, we have a new beta” announcement.  But it’s clear from R1 that the generic approach didn’t work.

We have too many major bugs in this last release to call the beta program a success.  It’s not doing what we need it to do.  So how do we structure is to so that our time is respected and we actually report bugs before Final Candidate stage?

What about you?  What suggestions do you have to help us and Xojo out at the same time?