Xojo and UTExportableTypes

The folks a Ohanaware wrote a blog post a few days ago that all Xojo developers creating Mac apps should read since it involves the UTI (Uniform Type Identifiers) created for your Xojo applications for Mac OS X.

The basic summary is that there is a bug in the 2015 R2.x series (possibly older versions are affected too) that can mistakenly lump all of the UTI’s into the Exportable Types that goes into the application’s plist file. This error can cause the Launch Services database to get corrupted and in Ohanaware’s case, prevented Quicklook from previewing PDF’s.

Thankfully, there are some simple things you can do to prevent this from happening. The first and best solution is to open the FileTypes Editor in Xojo and make sure its settings are correct. Under Build Settings in the Navigator choose OS X. Then press the File Types button that’s in the Inspector. This opens the Editor. The checkboxes on the left should ONLY be checked if your app is creating the file otherwise those files will get lumped into the Exportable Types.

Screen Shot 2015-09-30 at 9.14.09 AM

At this point I’ll take a step back and let you know that I’ve never even really thought about this editor – ever. The user interface is very simple but it lacks information on what these things do. The heading on the dialog does say “Select which file types your application will accept as file drops under OS X” which is pretty clear. However, as Ohanaaware found out it’s exporting it incorrectly.

I did a quick search in the Xojo User Guide and there is a brief blurb describing the roles in UserGuide-Fundamentals PDF. Otherwise, I’ve been unable to find any documentation on the exact use of this dialog.

The second method of fixing this problem is to use App Wrapper utility. This Ohanaware utility has been around for a few years and is a great way to code sign your applications as well as get all those little nasty bits set in your application for release. Have a Retina capable application? It can verify that the assets are all there. Releasing for the Mac App Store? It can help you set the entitlements and also strip your project of verboten items that will cause automatic rejection. And now, after their experience, version 3.4.1 of App Wrapper will do check these settings and can move them from the Exportable Types list to the Importable Types (which is what they should be doing).

Because this was such a disastrous problem Ohanaware also released a free utility called “Preview Reset” for Shine customers that were bit by this bug. I’ll give Ohanaware credit for owning up to it and working diligently to find the solution.

Ohanaware reported this bug to Xojo: <feedback://showreport?report_id=40907>. The good news is that it’s marked as fixed and should be in Xojo 2015 Release 3. However, it’s still in beta so until it’s released take extra special care with your Mac builds.

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?

JavaScript Error (or Banging Your Head Up Against a Wall)

In one of our big Web Edition projects I recently added a new dynamic WebContainer option to the home screen.  It generated a JavaScript error on occasion but because it was under active development I wasn’t too worried about it.  Sometimes those errors fix themselves given some time.

I figured that I was doing something to a control before it was being shown.  I went round and round with the bug adding timers to add delays and changing the order of when things were shown.  It was really bugging me and I even contacted Xojo support because it was happening on the Xojo Cloud server during the alpha period but yet I was seeing different behavior on my VPS host.

Eventually, we really looked at the javascript error:

document.getElementById(‘EK7iZlsZ’).style.overflow = ‘hidden’;

If you go into the Web Inspector in Safari and in the console paste in document.getElementById(‘EK7iZlsZ’) it resolves to a Style.  It was confusing because that style is used everywhere and all styles are static meaning that I’m not replacing or changing that style on any control, anywhere in the project.  We all assumed it was an order issue with the web framework.

The bit that finally tipped us off to what the real problem was the ‘style.overflow’ part of the JavaScript error.  That is NOT visibility of a control, that’s the JavaScript for ScrollbarsVisible and it’s a property on all WebContainers.  This is the property that will let you change how scrollbars work on the WebContainer.

Of course, once we knew what the error was it was trivial to change it.  The line of code I had in an initialization routine of the WebContainer was self.ScrollbarsVisible = 2.  As soon as I moved this to the shown event the problem went away.

If you are a heavy user of WebContainers this might bite you at some point in the future.  Perhaps you’ll remember this blog post and remember how you thought Bob was a silly old programmer for missing something so obvious.  🙂

Gotta love hours and hours of work for moving one line of code.  Of course, along the way things got more efficient and I removed a bunch of time delay code that was no longer needed.  I love programming some days.  Now to repair the dent in wall from banging my head….

Bat Shit Crazy Fix

Every now and then the Xojo IDE/compiler does something that just makes zero logical sense.  By all accounts some bit of code should work.  But it doesn’t and no amount of debugging and code changes solves it.  It’s easy to spend hours and hours chasing these bugs

Most times when something like this happens a simple Xojo restart fixes it.  But not always.

After that, I delete the Xojo cache files and restart Xojo.  Most of the time that will fix it.  But not always.

So I came up with the “If you think you are bat shit crazy fix”.  Do all of the above and simply restart your machine.  This has always fixed those situations.

Fine, call me bat shit crazy but I have at least 3 other developers that can attest that this works.  After hours and hours of trying to debug an issue I was out of options and that was the my last bit of advice.  Guess what?  Their problem mysteriously disappeared.

I have no idea what the problem is or even how to report it to Xojo.  All I know is that if I’ve exhausted everything else in my arsenal, the clear cache and restart seems to work.  Who’s crazy now?

Xojo Release 3

The third release of Xojo hit the internet this morning.  This release continues the incremental improvement and bug squashing that Release 2 did.  In addition, some nice new features were added that should make everyone happy although there is one major item that’s bound to give many users (or at least those not building for Cocoa) some heartburn.

The big change is that Windows and Linux desktop app developers can no longer access user interface elements from within a thread.  The behavior was always discouraged but not outright banned.  Now it is.  Just as it does in Cocoa, accessing any UI element from within a thread will cause a Thread Accessing UI exception to be thrown.  To workaround, you will have to have your thread fire a timer on your window or class which then updates the UI.  To see an example, look the Examples/Desktop/Threading/Threaded UI Update project.

Some good news for Web Edition users.  WebFiles can now point directly at FolderItems and can download incrementally in 64k chunks rather than having to load everything in RAM first before downloading.  The WebFileUploader can also take advantage of this new functionality as long as it has permissions to write to the temporary folder.

Another change that might affect a lot of developers was to the database server plugins.  Large queries could sometimes hang your application (because it was blocking the main thread).  I’m not sure when the Multi-threaded flag was added (Real Studio 2011-ish?) but it proved to be unsafe and caused occasional hard crashes.  In Release 3, if you call a large query on the main thread it will block (i.e. freeze) your application.  If you call it from a thread it will ‘just work’ but in a safe way so crashes don’t occur.

The number of IDE bugs squashed in this release is huge.  There are dozens of changes that fix some of the more annoying habits of the Navigator.  The entire IDE feels more solid and the Navigator much less twitchy.  Deleting children items in the Navigator no longer moves the focus back to the top of the Project tree.  Instead, it will try to select the next level up.  Converting methods to and from shared updates the Navigator properly now too.

Due to bugs caused by Navigator animation, it’s now been turned off until those bugs can be squashed.  The animations seemed useless to me by wasting cpu cycles.  Sure, it looked pretty but it didn’t DO anything for me as a developer.  Good riddance, in my opinion, and I hope they don’t come back.

The main IDE toolbar can be hidden and shown.  We still don’t have the ability to change the icon sizes, but it’s a start.    For Mac OS X users that like to run in fullscreen mode, hiding the toolbar seems to be impossible.  I’m not sure if this is an OS X issue or a bug but it seems pretty minor to me.

The Library filter has now been moved to the top to match the location of the Navigator filter.  I always thought it was silly to be on the bottom and I’m glad they’ve moved it.  In addition to that, both the Library/Inspector and Navigators can be made much smaller now.  The labels in the Inspector aren’t perfect but this a much needed improvement, in my opinion.

Also new is a new Run tab is opened when debugging an application.  When in the debugger and you select Edit Code it will take you to another tab so you don’t lose the Run tab.

A long term debugger issue was solved in this release.  If you stepped through code quickly (I call it spaz clicking) the debug app would usually crash.  This is no longer the case.

Windows users received some love in this release.  Windows flicker appears to have been reduced by being smarter on when to refresh the window.  Typing in the Code Editor seems to be much improved.  Memory leaks in graphics that use transparency are also fixed.

All in all, this release gives us some nice improvements for Desktop and Web Apps.  The IDE, Navigator and all, are shaping up (it still needs improvement but that’s a different post).  This is a recommend update to Release 2.

The full revision list is at  http://docs.xojo.com/index.php/Changes_2013r3

What’s your favorite addition/fix for Release 3?  Do you know of any bugs that made it through beta?

[Updated:  The IDE didn’t crash when spaz clicking in the debugger it was the debug app that crashed.]

Namespaces and Encrypted Classes

There’s an unfortunate bug in Xojo (and Real Studio) that decreases the value of namespaces for those of us who sell and provide code to other developers. You currently cannot encrypt a module that contains classes due to a major bug in the IDE. You can encrypt the classes inside of the module in binary and XML formats, but if you do, then you can’t save in version control format.
The main benefit of namespaces is to avoid unintentional clashes with names in code that you don’t own or control. If it was only a matter of our own internal projects we could just change names if and when a clash arises but we’re shipping our code to other people and we can’t reasonably ask them to modify their code if there’s a name conflict.
In Xojo, we have two choices:
  1. Use modules as a namespace. It would be nice if there was better support for this but it works fairly well.
  2. Give our classes long names that have some kind of prefix or suffix (this is the approach taken by Monkeybread Software, which predates namespace support).
We’ve chosen to go with namespaces but that won’t work for encrypted classes. This is unfortunate because the same people who deliver encrypted classes are also the most likely to be creating the sort of project that would benefit from namespaces.
Right now there’s not a good work-around for this. The options are basically to stop using namespaces or tell our customers they can’t use version control format.  Either solution stinks. Not using namespaces eliminates much of the advantages of using them and we would have to name our classes so that conflicts would be rare (if not impossible).  Furthermore, we recommend that all developers use version control so not allowing it for certain licenses would be hypocritical to say the least.
This is an important bug to get fixed.  Please sign on to <feedback://showreport?report_id=28891>

Mountain Lion and Saving Real Studio Projects

We noticed a very disturbing thing over the past couple of weeks in a couple of different Real Studio projects.  Occasionally, we find that changes to code are not getting saved to disk despite what the IDE.

In both instances we had things in the code editor not get saved.  The sequence was this:

  • Open up code editor.
  • Make changes (dirty flag goes on).
  • Save (dirty flag goes off).
  • Close project and then open it back up.
  • Code changes are not saved.

There is a thread on the Real Studio NUG http://www.realsoftware.com/listarchives/realbasic-nug/2013-01/msg00188.html about this very issue and it appears that it might be a Mountain Lion issue.  I wouldn’t necessarily disagree, EXCEPT that I was using Mountain Lion with Real Studio 2012 Release 1 with Mountain Lion and never noticed this issue.  As someone working on projects all day long and using version control format I think I would have noticed it before R2.

Movie of our code loss:


For us the problem seems to occur when using the VCP project format in 2012 Release 2.  That might be spurious data as we use VCP for practically everything and most of our projects are running in R2.  This has happened in both desktop and Web Edition projects.  Only 1 of these projects is being actively used by multiple people.

In one case I did a Save As over the existing VCP files and it appeared to make everything better and I’ve not seen the issue (in that project) since.  I have not tried using Disk Utility to check permissions and other disk errors.

Is it a pure Mountain Lion issue, is it a Real Studio issue, or a combination thereof?  Regardless, this is a very serious issue that the community needs to help figure out.

Have you seen this issue?  Was it using the binary or VCP file format?  Did you do anything to try and fix it?  What and how did that fix work?


As seen in the comments section it appears that Norman from Real Software found the issue we were seeing and has it fixed.  To recap: my bug only manifested itself in 2012 R2 version control format projects.  You had to change source code in the event of a control on a web page and not change any property anywhere else on the page nor any code in any of the methods.  It should be fairly rare to see this bug and we only found it because we hit that exact sequence.

Anyway, good news that it was found and fixed.  I don’t think it’s the same bug as reported in the NUG though it might be distantly related.  Only RS will be able to discover that.

Remote Debugger Issue

One of the changes in Real Studio 2012 Release 2 was an improved Remote Debugger Stub.  It compresses the files it’s going to transfer which results in a significantly faster transfer to the remote machine.

I’ve been happy with it until today when I kept getting this error when trying Remote Debug into Windows in VMWare on my machine.

VMware FusionScreenSnapz001


Not a very helpful error message.  This occurred as soon as the first data packet reached the Debugger Stub.

After banging my head of against the wall for about an hour (and starting to panic a bit because of a deadline) I started poking around.  The stub has worked for me, without issue, for years.  Why now?  What changed?  I tried using an older stub, older IDE versions, and all sorts of things.  Since I had the older one, newest one, and even a new beta version I had renamed the folders so I could keep them in one folder.  Last week I consolidated and moved folders around so I could manage them batter.

Have you guessed what the problem is yet?  I finally went to options and that’s where I discovered that the Download Location I was putting the files into no longer existed.  A simple change fixed the error and I was able to use the Remote Debugger in Windows again.

Feedback report <feedback://showreport?report_id=23508> was submitted.  Ideally the Stub should check the location before a debugging session starts or if the location doesn’t exists uses a temporary location.  I suspect this one will get fixed rather soon.

So, there you go.  If you’ve been banging your head up against a wall trying to get Remote Debugging to work, you might want to check the Options/Preferences and see if the Download Location exists.  Hopefully this saves someone, somewhere along way, some time.  Happy Coding!

Beginners Don’t Stay Beginners Very Long

There have always been Real Studio users that have been critical of the company and their products.  I have been known to throw a fit every now and then when I get bit by a bug.  There are currently several users in the Real Software forums that seem to be overly critical of the company these days.  These users go out of their way to hijack threads and tell everyone what a crap product Real Studio is and how Real Software is screwing everyone over.

I get their anger.  I really do.  I’ve been using Real Studio for ten years now working on a commercial products for clients all over the world.  Some of those are private apps, some are vertical market commercial apps and some are mass market  commercial applications.  I have probably been bitten by a bug in nearly every release and on every project.  It sucks but thankfully I’ve been able to find workarounds to most and come up with alternatives to others.

Don’t get me wrong, I’m not happy about bugs.  As a developer dealing with bugs is part of the job.  When I was an electrical engineer I dealt with hardware and software bugs ALL the time.  Try explaining to the client why a 1500 degree furnace stopped working because of bad firmware or why you stopped an automobile assembly line because a PLC glitch  When I was doing Visual Basic 6 development my code was a masterpiece of workarounds.  There is no excuse for bugs but they happen.  It’s part of my job to identify them and work around them.

One Real Studio user sent ME an email explaining how crappy Real Studio is.  It was reasonably intelligent email from someone who felt very passionately about the subject.  It was obvious he had a history of using Real Studio as a consultant.  I disagree with him on most every part of his email but I can sympathize.  Am I becoming to ingrained to ‘just dealing with it’?  I dunno.

Part of the problem, I feel,  is that Real Studio is geared for beginners and hobbyists.  That’s great and it’s how many long time users started.  Beginners don’t stay newbies very long if they stick with the product.  Soon enough they get past the initial learning curve and figure out how to ask the questions they couldn’t even formulate before and this is where the experience sometimes falls apart for many Real Studio users.

It feels sometimes that RS is solely interested in getting new users (and hobbyists at that).  New users are not a bad thing (in fact they are critical to any company).  However, isn’t retaining existing customers even more important?  You’ve already done the hard work in getting them to buy into the platform.  All you have to do is find the way to get them to stick with the product and ideally find ways to get them to upgrade to a higher priced product.

The Personal license is so cheap it’s practically giving it away at $99.  The Professional version is $299 so for every Professional license you have to get three Personals.  The Enterprise Edition is $995 so for every one Enterprise license you need ten Personal licenses.  Now, I don’t know what the renewal rate is among the licenses but I would suspect that Pro and Enterprise users renew more often Personal license users.  I know from a business standpoint my toolset is part of the cost of doing business so why NOT keep upgrading until I no longer use the tool?

My point is that Pro users are valuable and Enterprise users should be the most valued customers.  Instead, many of us feel abandoned for a variety of reasons.  As an Enterprise user I really like being able to use Web Edition, and use the product on all three platforms.    IDE Scripting, Build Automation are nice, but I could live without them.  I use the Profiler maybe once a year so it’s a feature that is wasted on me.  What makes the Enterprise edition worthy being an Enterprise product?  What are the compelling features for people to upgrade to Enterprise?  Not much at this point.

I’ve been doing this for ten years and I’ve been asking for the same things over and over again:  a grid component, a calendar control, date and time controls, less flickering in Windows, and finally reporting.  I lobbied hard for reporting and I feel like a fool for doing so since the reporting tool in Real Studio isn’t what I need (nor can use).  Instead I feel like I got a checkmark on a marketing page.

Granted, there are alternatives to many of the things I mentioned.  That’s not the point.  Instead of giving me the things I could use, today, in selling the product to my clients, I’m getting a new User Interface that will probably have some major bug when introduced that will make it less than ideal to use.  Did I ask for a new UI?  No.  I could think of a dozen things I’d like to see BEFORE a new UI comes down the pike.

So my hope for 2012 is some focus on features that Pro and Enterprise users need.  You can debate all day long on what those features are but the fact no one from RS has ever seriously asked me (or any other pro developer that I know of) what I need.  That says what they are focusing on instead.  Perhaps with some true Enterprise features more people would purchase Enterprise.

Well, but then again, I’m a long time Enterprise user and probably a bigger pain to support than those ten Personal licenses.  Happy coding!

Bugs Are In The Eye of the Beholder

The other day someone on the NUG list posted a somewhat lengthy message on Web Edition bugs. They were asking “why was Web Edition so buggy after a whole year?” Here is my response (mostly the same but with some changes).

Sure, Web Edition has more than its share of bugs. Like all bugs, however, it all depends upon the beholder.  What bug causes the most pain for RS’ is the one that gets fixed first.  I’ve seen a lot of the same things the community has discovered and have just worked around them (where I can).  I was using WE in a commercial project during the first beta ( a year ago) and while we got it to work it wasn’t very good.  That one project probably generated over a hundred feedback reports.  In my opinion WE really hasn’t really been usable until 2011 R3.

Part of the problem, in my opinion, is that RS has NOT created enough Web Edition applications for themselves.  If you don’t thoroughly exercise the framework you just don’t see the things you’d see in a big, complex application (like we are creating).  There is ONE real world example of Web Edition on their website.  While I don’t know how many examples are ‘enough’, I know that one is definitely not enough.

Web Edition exposes the same problems that we all see in Cocoa, Carbon, and in the IDE on a regular basis.  Unless RS experiences the pain it won’t get fixed in a timely manner because it’s not as important to them.  The Reporting editor and generator and the database editor are but two examples of things in the IDE that RS doesn’t use in ANY of their products. It shows because there are gaping wholes in usage that make them unusable for many developers.

RS takes pride in saying they eat their own dog food because they use Real Studio to make Real Studio.  Admirable, but they tend to be on a restricted diet since they don’t eat everything on the menu.  They rarely change the menu’s for the IDE so the Menu Editor hasn’t seen many changes or enhancements.  As far as I know, they don’t use a database in the IDE so I see no reason why they’d be using the database editor on a regular basis.  They don’t do much with StyledText or Movies so its no surprise that those classes are minimalistic (at best).

Since the IDE has no need for date pickers, they have never provided one.  Likewise, the Listbox is good enough for the IDE while we’ve been asking for a more powerful grid component for years.  Full RTF support?  Forget about it because StyledText is good enough for the IDE. A better toolbar control? Well that one’s a bit of a mystery since the IDE is obviously using something different than what they provide to us.

My point is I’m not sure why anyone would be perplexed about long standing bugs.  Sure, they’re painful to you and me (and my clients), but they’re not (as) painful to RS.

Lobbying the community to get Feedback reports higher in the list is about the only way to realistically get a bug fixed. But even that is a crap shoot as there are quite a few bugs (not feature requests) very high on the list that have been there for a long time. So the only thing conclusion that I can come up with is that the bug that all the rest of us are seeing isn’t painful to RS so therefor it isn’t a priority for them.

This is my opinion as a ten year Real Studio consultant.  I know and respect most of the engineers and staff at RS and I think they do a remarkable job.  However, I think as a company they mostly ignore those like me (an Enterprise user that ponies up thousands of dollars per year) and focus, almost exclusively, on the hobbyists (that bring in a hundred dollars a year at best).  If they could make me happy(ier) the hobbyists would come along anyway (see history of Visual Basic).

Bugs happen in every software product. I remember grousing about Visual Basic bugs when I was a big VB6 user. I know that my code back then had plenty of work arounds for bugs in their API. There is no doubt that Microsoft had more developers working on the product (as a whole) than RS has working on Real Studio. There’s also no doubt that VB6 has a considerably larger user base than Real Studio. I feel that this resulted in more workarounds being posted and more alternate solutions.  The reverse is that our smaller community doesn’t have as many solutions and documented workarounds so it feels worse but I feel that it isn’t.

Anyway, that’s enough on my opinions about bugs and such.  Have a good New Year and be safe. Happy coding!