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.


Windows Printing Broken in Xojo R4

We’ve done a lot more testing with Shorts and R4.1 this week.  Wow.  Where to begin.  I guess the first thing to say is if you need to print in Windows stick with Xojo Release 3 for now.  R4, with its switch to Direct2D has completely messed up printing.

Using Shorts, and Xojo R3 this is what a normal print looks like.  (Forget about the colors and stuff, I’m testing things out and the ugly colored blocks help).  Looks like it should:

Exact same code in 2016 R4.1 and this is what it looks like.  Note:  the picture makes it worse than it is, it’s not slanted like that on the page, my camera angle is just weird.  But, you can clearly see that while the lines and rectangles printed properly, there’s no text!

It’s obvious that the Direct2D from GDI+ in R4 were not properly tested.  Part of that is on us, the beta test community, but it seems, to me at least, that Xojo didn’t do enough vetting themselves.

The good news is that the Shorts display works fine as well the output to PDF.  So if you don’t actually print directly from your Shorts application you’ll be okay.

I expect better of Xojo.

The Xojo Community is Awesome

Have I told you how much I love the Xojo community?  I’ve been part of it for fifteen years and I’ve met hundreds of Xojo developers at developers conferences and probably exchanged emails with thousands more.  I am amazed at how much this community helps each other and I wish there was a way to promote that as a key feature of the product.  It’s a big deal.  Really!

If you’re just starting out using Xojo know that there are a bunch of people, myself included, that are willing to help out, if we can, on your journey.  Programming is hard.  Well, I don’t think it’s hard because I’ve been doing it for so long, but it is complex at times and that makes it hard.  Just ask your question in the Xojo forums and you’ll almost always get an answer within hours.

Even Xojo pros, such as myself, have need of help.  Xojo covers Mac, Windows, Linux desktop, console, and web apps.  It does iOS apps for iPhone and iPad.  It now does Raspberry Pi for heavens sake!  It works with dozens of different databases.  There is simply no way any one person is going to know everything there is to know about Xojo.  It just can’t happen.  So yes, I go to the forums, all the time, and ask for help.

Just the other day I asked for some help with WooCommerce.  Not Xojo related, really, but certainly related to a project we’re working on for a client.  Within a few hours I had half a dozen developers private message me saying they might be able to help.  Subsequent contact narrowed that list down a bit but the point is that I have probably shaved off several days worth of work simply by asking for advice.

I am biased towards Xojo, naturally, as it’s been my primary development language for fifteen years.  I think I’d be hard pressed to find such a friendly community.  I call many on the forums my friends even though I’ve never physically met them.  The few that I’ve met in person have lived up to their forum reputations and are really friends for life.

So maybe this is my belated Thanksgiving post.  I am thankful that so many years ago I jumped both feet first into the tool.  I asked questions – many of the silly and redundant.  I became more proficient and then made another jump to start blogging about it, making products for other developers, and training the next generation of developers.

So if you are in need of a cross-platform development tool I highly recommend Xojo.  It ain’t perfect but no development tool is.  If you jump in I think you’ll love the community.  I know I do.

What say you fellow Xojo developers?

Xojo:  The Best Secret in the Programming Industry Part 2

In Part 1 of Xojo:  The Best Secret in the Programming Industry we talked about some of the capabilities of Xojo and why it’s such a great software development tool.  We finished it with the question on why isn’t Xojo more well known?  If it’s such a good development tool why doesn’t everyone know about it?  There are no easy answers to this but I’ll identify some of areas of concern.

Entrenched IT Departments

The first issue is the BASIC language.  Xojo uses a form of the basic language.  However, it’s nothing like the gwbasic many programmers learned in high school.  It is a highly evolved, object-oriented language that happens to use a form of basic as the syntax.  Unlike other forms of basic, Xojo compiles down into a self contained executable needing no outside libraries.  It is not an interpreted language.  It’s not a ‘toy’ language.

Yet, the stigma of Basic still persists.  I think in many cases it’s because Basic is very approachable for new developers.  Many of these developers are not programmers by education and are coming at the language to get something done.  If you’re trying to introduce Xojo to your corporate IT department filled with programmers, that have spent thousands of dollars on their eduction, Xojo doesn’t fit any of the checkboxes of any of the current, hot, and yet soon-to-be-obsolete development tools they’ve learned.

From my own personal experience we had a Xojo app working as a prototype, proof-of-concept application, for a big Fortune 100 company.  Their IT department laughed at it and then turned around and told the project owner that it would take them TWO YEARS to start working it (they were busy after all) and they estimated another two years of development time.  Um…with Xojo our small five person team spent under a year on it starting from scratch and got it mostly working!  But that didn’t matter.  Never underestimate the power of entrenched IT departments.

And, much like in the Visual Basic 6 era, just because you can create a very useful application with the tool doesn’t mean that it is a great application that adheres to all of the modern principles.  Simply put, just because it’s easy doesn’t mean anybody can magically create a great application.  Software development takes some skill and some discipline to make a good application and sometimes beginning programmers don’t know any better (regardless of platform).


Who Is Their Market?

Honestly, I have no idea who Xojo markets to.  I’ve used the term hobbyist in the past but Xojo prefers the term ‘Citizen Developer’.  Whatever.  I think we’re talking about the same crowd.  They’re people that aren’t necessarily getting paid to develop software or it’s not their primary function in their job.  While, I don’t have a problem with getting more of these types of people into the community but what I really want are the enterprise users.

The trick in either the citizen or enterprise developer is how do you reach them?  In years past you could do some advertising in magazines but that market has gone to the web so it’s much harder to identify and advertise.  What is Xamarin and the other cross platform tools doing to advertise?

Here are a few ideas:  What about sponsoring a podcast or webcast that business owners or developers listen to?  It seems like there’s a podcast for everything these days but the trick is to identify a podcast that might have a lot of listeners that fit the ‘citizen developer’ model.

The Raspberry Pi has some interesting possibilities and, I think, fits with Xojo very well.  When Remote Debugging is completed this makes Xojo an excellent choice for the platform.  I would think there is a number of marketing opportunities that open up from magazines to podcasts to websites that do nothing but talk about the mini computer.  I imagine a ‘show us your Xojo Raspberry Pi application’ contest.

One of my new developers discovered Xojo as part of a software bundle from a number of years ago.  It’s a long gestation period but giving out a free single platform license every couple of years does seem to grow the user base.  This is anecdotal evidence, of course, but it makes sense to me.  When the programming industry got started what you used at work became what you used at home.  The flip side could also be true:  if you start with a really good tool as a youngster you might end up using it later to get stuff done.

Many of our clients ask about Xojo and ask if I think they’ll be around in five years.  For a company that’s been around for twenty years already that seems like a silly question but perhaps Xojo needs to use that as a marketing point.  They’ve been around longer than most of the current, hot, software development languages and tools.  I doubt they’re going away any time soon.

Third Party Tools

This one is near and dear to my heart because this issue has been around since I started with Xojo fifteen years ago.  The Xojo community is small and there is not a big community of developers writing add-ons for it.  There are tools for almost anything you want that range from free to commercially supported.  The difference is that not all third party tools are supported equally and some developers aren’t exactly quick to support their products.  Some developers look at Xojo and are scared away by the lack of third party components.

On the flip side, developers don’t write add-ons for Xojo because the market is small.  We, BKeeney Software, have developed several components and can tell you that we couldn’t survive on component sales – a vast majority of our income is from consulting.  We cheat and spend a lot of time on those components that we use ourselves.  Either way we win.  It’s either a competitive edge when bidding on projects or we make a little extra cash with sales to other developers.

I don’t feel that Xojo does a very good job of promoting third party products.  They do sell some of those products through their web store but there are no previews, no demo’s, screenshots, or anything, to tell you how good those products are.  There’s no way to link to the developers website, how long the product has been around, or when it was last updated.

I would love to get my products in front of more eyeballs.  The store in its current form isn’t doing it.  I would also gladly pay to promote some of my products (like our reporting tool) that I think many Xojo developers might find useful.  Even better, I’d love to create a lite, free version, that could be bundled with Xojo.  Sure, it’s a bit more work right now, but in six months or year, some of the people using the lite version might buy the full version.

Currently Xojo has the ability to use plugins written in C++ and there are some incredibly useful plugins out there.  We own most of them because they save time and money on many projects.  Xojo has announced that sometime in 2017 users will have the ability to create plugins within the IDE using Xojo itself.  This has the potential of really growing the market but until it’s in our hands we won’t know for sure.  This is a critical component in 2017 for Xojo to help foster the third party market.  Hopefully Xojo helps promote them too in such a way that’s a win-win for both Xojo and the developer.

No Books/Lack of Training Material

One issue that some people have with adopting Xojo is that you can’t go to Amazon and find a Xojo book.  There are some older REALbasic and Real Studio books but mostly they’re out of date (though still valid for much of the language).  We, BKeeney Software, offer video training and we have about 65 hours of video that has some Real Studio material in it as well.  The name change to Xojo from Real Studio and REALbasic hasn’t help them in that regard and it will get better over time.

Another issue is that Xojo is on a ninety day release cycle.  It means that if I write a book that is completely valid today in three months there is a good chance part of it becomes obsolete.  Every ninety days Xojo adds something, changes something, and fixes bugs.  There is no way a printed book ever stays up to date.

If you’re looking for written material I’d look at www.xojolibrary.com as the topics tend to be narrowly focused on a specific topic.

I’ve thought about writing a book on database programming using Xojo.  I even have an outline and some chapters fleshed out complete with code examples.  But, since I know the new Xojo framework changes many aspects of Xojo it’s not worth it to complete the book.  Why write it now and have to rewrite most of it when the new framework comes out?  The community is small and the number of people that would be willing to write a book is even smaller.  I think to get a book into Amazon and other books sellers Xojo is going to have to commission a book to give an author an incentive to complete it.

Competitive Advantage/Keep it Secret!

There are some people that are using Xojo and making a great living selling their Xojo-made applications.  They’re just not vocal about it.  I’ve heard clients tell me they don’t want their competitors to know they use Xojo because they feel it’s a ‘competitive advantage’.  It takes them about a quarter of the time to put out a new version that their competitor (who is using more ‘traditional’ programming tools) can do.  That means more sales to them.

I get it.  Remember my story about the working prototype that the IT department laughed at?  It’s five years later and to the best of my knowledge the project was never started.  Imagine how they’d be feeling now if that Xojo prototype project had gone into product?  The project owner would be a flipping hero for solving the problem quickly for far less money than they could do it internally.

They’re not Apple or Microsoft

Xcode is the standard bearer for macOS and iOS development.  Apple is tight lipped on many of their new technologies so a third party developer like Xojo finds out at the same time the public does on new API’s and technologies.  Likewise, Visual Studio is Microsoft’s preferred development tool and while they’re not as forward thinking and don’t obsolete older technologies nearly as much as Apple they do introduce new technologies at a fast pace.  There is simply no way for Xojo to keep up with either of them.

This might be one of the biggest drawbacks to Xojo.  Because they have to be reactive to the whims of Apple and Microsoft they are always late to the party.  It took Xojo a few months to quickly deprecate QuickTime from Xojo because Apple deprecated it and shortly afterwards started rejecting applications from the Mac App Store that used QuickTime.  I think they did admirably in that situation but what’s the next bombshell?  That the Mac lineup is moving to the ARM processor?

At their developers conference last month they told us about a new feature called Interops that, at least for macOS and iOS, and Linux, make future platform changes easier to transition to.  However, there’s no guarantee that something else won’t change in the future that causes Xojo to play major catch up.


It’s truly a shame that Xojo isn’t more well known.  It’s a great tool that accomplishes a lot of things that other development tools don’t even try to do.  I think the community is getting larger and one would hope that there is some tipping point where Xojo becomes synonymous with cross-platform programming.  It has some extremely important deadlines to meet in 2017 to keep the platform moving forward.

Did I miss any reasons why Xojo isn’t more well known?

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?

Xojo 2015 Release 2

Xojo Release 2 went public this week.  This release is a typical mishmash of new features and bug fixes.  So let’s dig into it!


The DatePicker was added to iOS.  This is a most welcome addition and let’s you switch between Time, Date, Date and Time, and Countdown Timer.  There’s still no generic data picker which is a shame.

The Launch Images and App Icons folders for iOS has now been replaced with an editor that allows you to drag and drop images into it.  If the image isn’t the appropriate size for the selected image a message appears saying what the dimensions of the image is and that it will be scaled to fit.

[Edit]   One thing I forgot (because I didn’t see them in the release notes) was that build times are much better in R2.  From comments I’ve seen it may be an order of magnitude faster.

Web Apps

If you are using the HandleSpecialURL or HandleURL the RequestHeaders now has a Secure property telling you if the request came in over a secure channel.  If you are using SSL Certificates they can be specified on the command line.  Another new web feature is the ability to set the HTTPOnly property attribute in the Session.Cookie.Set method.  This should work as a preventative measure against cross site scripting attacks against Xojo web apps.

New Framework

The new framework is making its way to more and more of the overall package.  The Xojo.Data, Xojo.Crypto, and Xojo.IO.Folderitem are now available for all targets and platforms.  The Xojo.Data namespace includes the ability to read/write JSON (no work on XML yet).  The Xojo.Crypto framework gives you access to MD5, RSAEncrypt/Decrypt, RSASign, RSASignVerify, SHA1, SHA256 and SHA512 hash methods.  Xojo.IO.Folderitem gives  you file handling.

Xojo.Net.HTTPSocket now works for all platforms (except Xojo Cloud).  It should be noted that HTTPSocket is now ONLY asynchronous.  No longer can you wait for the response but now you have to use the events from the socket.  This is really a better way of using the HTTPSocket but if you’ve been using it in the old framework synchronously you’ll need to adjust your code accordingly.

[Edit] The new HTTPSocket supports HTTP 1.1, automatically supports proxies on all platforms, and performs proper certificate validation.  It also no longer performs polling on the socket so it should be have significantly lower CPU usage.

The Xojo.Core.Timer now works properly on Mac OS X 10.7 and 10.8.  Apparently it didn’t work properly in older versions of Mac OS X.


For many, the recent addition of the Windows ICU DLL was a major setback as they were quite large.  You’ll be happy to know that they’re now statically linking them and removed the unused portion of the libraries so the built package is now considerably smaller.

The IDE receive a large number of bug fixes including a couple of memory leaks.  They also fixed how deleting items works and how the focus works when switching between tabs with the Code Editor displaying.

According to the release notes there are 147 total items that were changed in Release 2.  This number seems a little low in comparison to some previous releases.  Given the short period between the R1 release and XDC I think this makes sense and the engineers have a lot of work to do in getting ready for XDC.

I did not get as much of a chance to run the beta as I usually do but there hasn’t been a lot of chatter on the forums about issues either.  What little I did with the beta was solid and this looks to be a decent release.

Have any comments about this release?

Xojo Desktop vs Xojo Web App Development

The question comes up every now and then on what’s the best target to develop for:  desktop or web.  The answer is sometimes pretty straightforward but, in reality, the answer should be “it depends.”  You see, each target has some very good strengths and also some bad weaknesses that you need to evaluate before you start coding.  Let’s go over some of those issues.  Let’s start with desktop apps.

Xojo has been making desktop apps for it’s entire history.  Thus it is very stable and mature and there are a lot more 3rd party libraries and plugins available.  You get most, if not all, of the goodies that come along with the desktop environment and this can mean your desktop apps can have most of the buzzers and bells that modern users demand.

With desktop apps, if you need 10 more copies, it’s as simple as installing them on new machines.  These days there’s not a lot of issues deploying to Mac OS X and Windows and most versions of Linux, but still, you need to test on all supported platforms.

The major downside to desktop apps is deployment.  Each user has a copy of the software and depending on your needs/requirements you might need to ensure that everyone be on the same version.  Example:  You’ve created a desktop app for a veterinary clinic that handles everything from pet checkin to billing.  All of them connect to the same database so when you introduce a schema change in the database you need all the clients to use the newest version.    For a small organization this might not be so bad but scale that up to a corporation with several hundred copies of your software.  A good organization might have a good IT department and can deploy your software to everyone at once, but my experience says that most organizations don’t handle this well.  So your software has to be programmed to be cognizant of database versions and check at startup and complain if it’s not what it’s expecting.  From experience it’s a pain to deal with.

Desktop apps that are part of an n-tier system also need to be programmed differently.  You can program each client with all the logic it needs, but then you have to worry about record locking issues (i.e. who wins if two users are editing the same record at the same time).  You also have deployment issues, again, since you’re back to the issue of updating every client every time there’s a little change in logic.  The better solution is to have a middleware application that handles the business logic and is the go-between between the client apps and the server.  The middleware app does all of the business logic and handles the transactions between the database and the client apps.  It’s a fair bit of work and is not what I would consider a simple undertaking.  But at least you generally only have to update the middleware app most of the time and the clients can stay the same.

Web apps, on the other hand, have several advantages over desktop apps.  First, they are n-tier by design.  Each client has its own set of logic via Xojo WebSessions even though there is only one application running.  The user runs in a browser and everything is processed on the server.    So when you need to update your web app you shutdown the old one, replace the executable and the next time someone hits the URL the newer version is there and running.  Having only one instance to update is really nice (and quick).  Web apps eliminate many deployment challenges.

Web apps aren’t perfect though.  Since they are generally exposed to more random user interaction via the web you spend way more time dealing with security and making sure nefarious users don’t get into your system or abuse it.  All of your database operations should use PreparedStatements to make sure SQL injection attacks cannot happen.

Web apps run in a browser.  That’s both good and bad.  Users can access your app as long as they have internet access.  In some areas this is no big deal and for others it’s a huge deal.  Browsers also have a lot of built-in security to keep bad things from happening on your computer.  This security also limits what your browser can do in terms of file handling local.  Xojo does not currently support drag and drop operations with the browser.

Xojo web apps are also not as stable and mature as the desktop side simply because it’s younger.  That’s not the same as unsafe but it does mean there are not as many 3rd party options for Xojo web apps.  Some controls, in particular the listbox, are vastly inferior to their desktop counterparts in terms of capabilities and may not be good enough for your needs.  Web Containers go a long way towards solving this issue but it’s not ideal.

Not all web browsers are created equal.  Some perform better than others and all of them have gone through tremendous growth in the past ten years as the internet has become ubiquitous.  This means there are a lot of different browsers, and versions of those browsers, being used by the general public.  Testing the various browser type and version combinations is critical and despite all the efforts of Xojo to get it all right, the speed of new browser releases does mean issues pop up now and then.  Mobile browsers have their own set of issues that you might need to take into account as well.

Desktop apps have a huge advantage in that they don’t have to convert text to UI like web apps do.  For example loading 1,000 rows in a desktop listbox, while slow is blazingly fast compared to doing the same thing in a web app.  1,000 row list boxes in web apps are SLOW simply because the server has to create all that html data, send it through the internet to the browser, and then the browser has to reassemble it for the user to see.  To get around this most websites do data paging where they only show you 25 to 50 records at time.  Again, not hard to do but one more thing to develop.  Also keep in mind that mobile browsers try really hard to minimize data connections over cell connections so what seems fast on your desktop might be incredibly slow on a mobile phone.

Perhaps the biggest issue with web apps (not just those made with Xojo) is scaling.  Your app will react differently when accessed by 1000 simultaneous users than when it has 10.  The way around this is to do load sharing and balancing using NgInx and works well on Apache web servers.  Finding a good web server to host your web app can be challenging too.  Until Xojo releases their 64 bit support for web apps it will be increasingly difficult to find and install 32 bit compatibility libraries that work with Xojo web apps.

As you can see, there’s is no right answer.  Both desktop apps and web apps have their place in the world since they each have strengths and weaknesses.  Before you start development work you need to think through the implications of doing each.

Happy coding!  Was there anything I forgot to mention in the debate of desktop vs web apps?

BKS Spell Checker 1.0.2

picBKS_SpellCheckerWe released a new version of our Mac/Windows spell checker plugin today.  Version 1.0.2 works better with foreign language Hunspell dictionaries that are in different encodings.

The Spell Checker plugin has two different spell checking modes.  In the first mode it  works with the native spelling dictionaries on each platform.  On all versions of Mac OS X (that Xojo supports) and Windows 8 and above it uses the built-in spell checker dictionaries.  If you can’t, or don’t want to, use the native dictionaries you can use the Hunspell dictionaries.  There are hundreds of Hunspell dictionaries available for use in a variety of languages and speciality industries.

There is no Linux version at this point due to lack of interest.

More information, including downloadable demo, pricing, and usage is available at http://www.bkeeney.com/allproducts/bks-spell-checker-plugin-for-xojo/

Debugging Your Xojo Applications

Your customers and clients expect your Xojo applications to be as bug free as possible.  What mechanisms do you have in place to handle an error and report it?  Bugs occur – that’s a fact of life – and even the best error handling in the world can’t prevent bugs from occurring.

Thoroughly testing your application is your first and best line of defense.  However, it’s very time consuming and without good testing procedures it may even be a waste of time.  I would also add the it’s very hard for the developer to be a good tester of their own code.  You programmed it to do a certain task in a certain way.  Someone else will have a different set of expectations.

Regression testing is the only way to really make sure that changes in one part of your code doesn’t change other parts of your application (or a new version of Xojo doesn’t affect you either!).  An excellent way to do regression testing on your software is to use the open source unit testing module called XojoUnit (it’s now part of Xojo).  It allows you to test your code with known inputs and test them against the actual output.

A common question from the forums is that people get an error message saying, “The application has encountered an error and must now shutdown,” and they have no idea what the error is or where the error happened.  They need to learn as much as they can about the Exception class and in particular the Stack property.  The stack was introduced way back in 2006 and is a string array that contains the methods that have run from the entry point into your code until where the exception occurred.  Be aware that the Include Function Names property has to be true in your application for the stack to be human readable.

Use the UnhandledException event in the application class to capture any errors that weren’t handled elsewhere.  The exception stack allows you to determine where the error occurred and from there it’s a simple matter to send an email, post to a web form or write the error out to a log file that includes important details such as platform, operating system version and the version of your application.

Some applications will require files be in a specific location and when debugging your application those files might not be in the proper (final) location.  Use the DebugBuild constant along with conditional compilation, #If,  to handle things differently at debug time and runtime.  For debugging purposes you can have the required files in the local project directory for convenience sake.  A feature added in 2007 allows you to place your debug build in a particular location which eliminates the need to have non-project files in your project directory.

Cross-platform applications require additional handling but now that Xojo with (or without) a desktop license can do remote debugging and it’s very easy to do.  I run the Xojo IDE on Mac OS X on an iMac and use VMWare running various versions of Windows and Linux so I can debug my applications in those environments.  The remote debugger works exactly like the regular debugger except that the debug application is running in another environment.  It’s a little slower to initiate since the app has to be transferred to the other environment but otherwise it’s the same process.

I highly recommend testing early and often on the other platforms you’re developing for.  Don’t wait until the end to do extensive testing.  While Xojo does a great job on cross-platform applications there ARE platform differences you need to be aware of.

New developers coming from Visual Basic 6 are often irritated by the perceived lack of database error in Xojo.  An incorrect SQL statement when opening a recordset results in nil recordset objects instead of a throwing a runtime error.  The unexpected nil recordset then causes NilObjectException errors.  You must get in the habit of checking your database object for errors after every database operation.  Once you catch the error you can at least be more graceful on how to recover from it.

That’s a lot of information so do your research.  Debugging your application isn’t as hard as you think.

What things do you do to make your life easier hunting down or preventing bugs?

Happy Birthday, Macintosh!

There have been a number of trips down memory lane this week regarding the Macintosh so now you’ll have mine.  If you’ve been living under a rock you may not know that the Macintosh was introduced 30 years ago this week.  It truly changed computing and it certainly changed my course in life.

I entered college in the Fall of 1985 to become an electrical engineer.  While PC’s weren’t unknown at the time they were still expensive enough where they weren’t common.  In the fraternity that I joined, they had two(!) IBM PC’s sitting in the basement ‘computer room’.  We were praised by the national fraternity for having all of our books on Lotus 123.  Looking back how quaint.

As with any fraternity we had our various committees and in the Fall semester of 1986 I ended up being the chairman of the Parents Committee and it was one our charges to send a newsletter out to parents to inform them of all the great things their kids (and money) were doing.  For many years we had people that worked at the newspaper and had access to the Linotype machine where we could print out the text at high resolution, lay it out on boards for printing.  That semester we had no one on staff and I was scrambling to figure it out.

One of the older Brothers worked at the school computer lab.  He mentioned they had these new Macintosh computers and this thing called a LaserWriter printer that was ‘very cool.  He handed me a copy of MS Word and Aldus PageMaker and told me to go figure it out (ah the days before anti-piracy solutions).  I was reluctant but curious and got to play around with the two apps on a Macinoths plus.

I was intrigued and hooked.  I had used quite a few different types of computers, TRS 80, Apple II, IBM PC’s, Atari to name a few but the Mac was something special with its 9 inch black and white monitor and its mouse where you pointed and clicked and dragged things in a What You See Is What You Get (WYSIWYG) environment.  It was SO intuitive.  If you didn’t know the exact command you could find it in the menu’s.

My parents newsletter went out with relative ease and our chapter won an award for innovative newsletter.  The following semester I was in charge of the Alumni Committee and we won an award for the newsletter we did then too.  From then on I can’t tell you how many newsletters I did for the fraternity.  Again, looking back on 30 years they’re pretty cheesy but superb for the time.

This was an engineering school so we were predominantly IBM PC’s (this is long before Windows came into play).  Our classes expected us to use PC’s, the software was PC only and I stuck out like a sore thumb.  It was common practice at the time to do all lab reports by hand and to use very expensive chart paper to hand draw lab results and it took many hours to make nice graphs.  I pissed off more than a few classmates off by turning in my lab reports done on a LaserWriter where I used Word, PageMaker and a charting app to chart my data.  The lab TA’s were impressed with my reports despite having crap data and questionable results.  This is when I learned that making it user friendly and looking pretty counts.

The rage of the era was attending Mac User Groups, or MUG’s, where you could meet with like minded Mac geeks and talk about the software you were using, get questions answered, etc.  I started one at school.  I had my own MUG newsletter (for the 30 engineering students that actually liked the Mac).  I hooked up with other MUG’s in the Chicago area and got involved with them and because of that involvement was able to help pay my way through school doing Mac training and graphic design (okay I wasn’t very good at it but I was better than most desktop publishers of the day).

One Fall (I think ’88, or maybe ’89) I went to a MUG conference in Ann Harbor, Michigan.  The keynote speaker was Bill Gates (really!) and he spoke about how well Microsoft Word, Excel, and PowerPoint versions 1.0 were doing on the Mac.  His engineers held breakout sessions that lasted ’til the wee hours of the night listening to what Mac users thought needed improving.  I even shook Mr. Gates’ hand when I passed him in the hallway.  Despite having more money at that point than I’ll probably ever have, he was just your average computer geek.  Go figure.

That conference also happens to be the first place I saw my first 1 GB drive.  It was the size of a suitcase and cost a couple of grand.  As we all filed past we kept muttering, “What the hell would you have that needed something that big?”  Remember, operating systems lived on a 1.5 megabyte floppy drives back then.  We were so naive.

At times it’s been a very long 30 years.  I remember the mid to late 90’s.  It was an ugly time to be a Mac user.  Windows was king of the hill and every year there were fewer and fewer of us.  Even though I was using a Windows PC at work I always came home to a Mac where I was writing software for fun.  I used Think Pascal and Metrowerks CodeWarrior.  I had learned Pascal in college but learned C and C++ on my own.  CodeWarrior was a great development environment in my opinion.

When I finally was smart enough to switch careers – okay my soon to be wife told me to find a job I liked before we got married – I found Visual Basic and Access gig.  It was decent and I did learn to appreciate what Microsoft had done in terms of wiping out alternatives and becoming ‘the standard’.  However, DLL hell and compatibility problems were still issues that plagued even 100% Microsoft shops.

I landed a development job working for an exclusive CodeWarrior shop doing very early Mac OS X development work.  They did a lot of fun stuff but they wanted to do some rapid prototyping of an app idea and since I was the new guy in the office they told me to look at this thing called REALbasic.  I did and without too many issues I created a proof of concept for a photo storage and management application – the iTunes for photos if you will.  Sadly for all of us, iPhoto came out just a few months later and killed the project.  But my intrigue for REALbasic remained and I kept working on small projects and when it could do Macintosh AND Windows builds with just a click of checkbox I was sold!  It was the best of both worlds.

One thing that I recall vividly was my reaction when Microsoft was officially convicted of being a monopoly.  I was sure they would NEVER again have 95% marketshare because the only way they got it initially was to do it illegally.  So far history has proven me right.  Of course the iMac, iPod, iPhone, and iPad have had something do with it.

When I started doing REALbasic (now Xojo) consulting 13 years ago few people cared about Mac versions of their apps.  A few years later when the iMac and iPod started to reinvigorate Apple it was a common theme to do a Mac version to keep the boss happy.  Nowadays, nearly all of our consulting clients want a Mac version first and if we can do a Windows version to keep the accountant happy (who is running some accounting app that’s still Windows only) that’s great.

Thirty years is a good chunk of my life.  I can remember life before the Macintosh but working on that first Mac literally changed my outlook on life and put me in a different path.  There are a lot of things about the Mac that made me a rebel, but also set the quality bar high.  I’m still willing to pay more for things that are of better quality from cars, to tools, to hiring contractors that work on my house because I firmly belied that you get what you pay for.

The Mac inspired me for 30 years.  I’m hoping it will for another 30.  Happy birthday, Macintosh!