Container Control Love

We are big fans of Container Controls for a lot of reasons.  Containers, in my opinion, are one of the most powerful tools in Xojo and they are often misunderstood and under used, in my opinion.

Complex UI

Complex UI

In the first picture you see a very complex layout.  The client only wanted a single window for everything.  Each item in the family list is its own container.  Each of those containers has a tab control and you can see a fairly typical layout.  In almost every case each of the tabs has its own container as well.  The project takes it to the extreme but adding these dynamically is really fast.

Screen Shot 2014-02-15 at 2.06.15 PMThis project was a conversion from VB6 and everything really was in one window.  It was a nightmare to debug and in the process of converting it and breaking it apart into containers we found numerous errors they had never been able to find due to the shear amount of code in this one window.  To load the container we simply create a new instance of one (if it doesn’t already exist), give it the database file and the container literally does everything else.  The Xojo window has about 200 lines of code for everything.  The old VB6 window had over 10,000 lines of code.

Containers let you create really complex UI layouts and treat it as a single entity.  I see this a lot with projects with tab controls where each tab has 30 controls on it and you have 10 tabs.  That’s a LOT of controls and logic to load and save the data to them.  What we do is create a container for each tab and the container has the load, validate and save logic.  Then we place the container on the tab control or page panel.

Doing things like this does a couple of things for us.  First, it makes the coding of the Window very simple.  Instead of having 300 controls you have 10.  When the Window is opened or when the user presses the tab to expose it to the user we tell it to load the data (this is where using ActiveRecord comes handy).  The window itself doesn’t know or care about the individual controls.  So all the code for the container is where it makes the most sense – in the container.

The second thing this does is simplify what the IDE has to display.  I’ve made no bones about it that I do not like the Xojo Navigator.  The more objects you have in it the worse it gets.  Finding stuff is hard and I find it to be a royal pain.  Using containers reduces this issue.

The only real drawback to using containers at this point is that they draw really slow in the Layout Editor.  This appears to be addressed in the latest 2014 R1 beta but until it’s actually shipped you never know if it will get pulled for some as yet undiscovered show stopper bug.

Containers are also the only reasonable way to make repeating rows of controls.  Many people bag on Xojo for not having a powerful grid component but I think by using Containers you can do a lot of the same things.  To make a very sharp repeating rows control you need to have at least 4 different containers.  The overall container, an inner bounds container, the overall list of rows, and finally the row itself.  This is for desktop apps only since you can do the same thing in Web with only two containers.

Doing this type of repeating row control is not possible in carbon apps since the controls do not respect the container bounds but it works in Cocoa apps.  In Windows there is no issues but in Linux you need to use the new transparent property on all of the containers so the controls will respect the bounds of the container.  Xojo just did a blog post on this.

The drawback to the repeating row strategy is that you don’t want to have hundreds or thousands of rows.  Each container consumes memory and they can quickly make your UI slow and unresponsive.  At that point it’s much better to page your data so that your user can only see x number of rows at a time.  We usually settle on 50 as a nice starting point.

As I said earlier, Web Edition repeating row lists are even easier.  You simply add the container row to the container list and it knows to add a scrollbar.  It also knows how to scroll when the user uses the mouse scroll wheel.

One caveat about this is WebDialogs.  There is a super nasty bug in the framework where WebDialogs don’t get events like they should.  If your web dialog, and subsequent container, happens to be over a WebListbox and you try to scroll, the underlying listbox will receive the scroll events.  If you find this happening to you, you can try disabling the listbox.  Still, this bug sucks.

There is huge overhead using the EmbedWithin method in web apps.  Every time you use it the app has to serve up a new page and send it down the pipe.  I saw an example project the other day that had 50 rows and each row had 10 container cells on it.  With very little data and no style information it took almost have a second to display the repeating list in the browser on the same machine.  Add some additional time going over a slower connection and your app looks slow and unresponsive.

The answer for now, is to not do that.  The performance of the embed within command is simply too big to use it a lot.  We had one largish web project where we used containers for each of our tabs and were adding them at runtime.  It was not good.  The lag time was simply too big so we ended up embedding the containers into the page at design time.  Now we take a little bit of a hit when the page is first displayed but the user doesn’t notice anything when they switch tabs.

If you are not using containers you really might want to look at them again.  They really are powerful tools.  With a little time and practice you can make your coding life easier while developing some incredibly complex layouts.

Xojo Guesses for 2014

2013 was an interesting year for Real Software, Real Studio and the resulting Xojo company and IDE. After a long wait the new Xojo IDE with new branding and company name change was announced at the developer conference in May.

Xojo Release 1 occurred in June. It was buggy and the controversial Navigator was at the top of everyones list (mostly the naughty list but a few people liked it). The new Cocoa framework largely worked as promised and people rarely complained about it. Subsequent Xojo releases fixed most of the worst of the bugs in the IDE but even after the 4th release there are bugs in the IDE that obviously are not easy to fix (or they would have been fixed by now).

The change in licensing for Xojo affected everyone and mostly for the better. You can now use Xojo for free but you need a license as soon as you want to build for a platform. This made Xojo cheaper for many but a bit more expensive for folks like us that build for all targets. The only real issue that we had with the licensing change was that the licensing terms require non-builders to have a license if you want to save in the version control format http://www.bkeeneybriefs.com/2013/10/when-a-license-isnt-a-valid-license/.

2014 promises to be a huge year for Xojo. Many of the things they announced at the Xojo Developers Conference should be coming to fruition this year.

Xojo Cloud: Originally scheduled for June 2013 (as stated at the keynote address in May http://www.bkeeneybriefs.com/2013/05/xojo-cloud/ ) it looks like it will finally be released in 2014 Release 1. It promises to greatly simplify the deployment procedures for web apps. We already know it will be missing database server support in the initial release but it appears we will be able to purchase additional RackSpace options for that. I will be curious how this works for consultants like us that have multiple clients we’re writing apps for. Chance of it happening in 2014? 100%

64 bit apps: At the developers conference they said http://www.bkeeneybriefs.com/2013/05/xojo-64-bit/ it would be ‎summer 2014 for 64 bit applications. It will be an option to compile for 32 bit or 64 bit applications and eventually 64 bit becomes the default. This will be an interesting transition. At the conference they said they were 70% done with Cocoa and for Linux and Windows they just needed to do testing. Chance of it happening in 2014? 75%

.NET Framework Usage: Developing Windows apps is always an interesting experience. Since the Win32 API doesn’t have double buffered windows like Linux and Mac OS X has,  what looks good on those platforms can often (usually?) look awful in Windows because of flickering. There are ways to minimize flickering but it’s next to impossible to eliminate it entirely. I hope something can be done this year. One of the possible solutions is to hook the Xojo framework into .NET libraries. I am by no means a Windows expert but one of the possible issues with this is that Windows XP doesn’t have .NET libraries shipped with it by default (though Vista and above does). Does this mean the end of Windows XP support or appropriate error messages? Chance of it happening in 2014? 10%

iOS applications: http://www.bkeeneybriefs.com/2013/05/xojo-for-ios/ ‎ Using Xojo to develop and compile native iOS applications should easily be the biggest news item of the year for Xojo. To say that this might be huge for the company is an understatement – assuming it works as advertised and Apple accepts the built apps in the App Store. With the exception of a couple of demos we really haven’t heard much about iOS other than it’s progressing. If memory serves they are saying a beta will be available around the Xojo Developers conference in March with a summer release date. Chance of it becoming usable in 2014? 60%

iOS is going to introduce a new NameSpaced framework http://www.bkeeneybriefs.com/2012/05/new-frameworks/ that will eventually make its way into web, console, and desktop applications. iOS is a completely different beast which requires a different framework and their goal is unify the framework so that it can be used universally for all targets. There has already been much teeth gnashing over the proposed changes but I’m not too worried. First, it will only affect iOS (for now) and then maybe web by the end of 2014 and who knows how long it will take for desktop to get it. Second, the old (global) framework will be around for a while for a (hopefully) smooth transition. Until it starts affecting us I refuse to worry about it. Chance of it happening in 2014? Same as iOS – 60%

For a company as small as Xojo this list is rather daunting but they’ve been working on some of these items for years. I would expect something to slip into 2015 but we’ll find out more in March at the developers conference. What are your predictions for 2014 from Xojo?

We’ve Acquired the Fireye PDF Classes

Lenexa, Kansas, USA (December 27, 2013) — BKeeney Software Inc. has acquired the Fireye PDF classes for Xojo and Real Studio.

We are very excited to bring the FireEye PDF classes to BKeeney Software.  The PDF classes represent years of quality work and fill a need in the Xojo developer community in regards to the creation of PDF documents.  We will spend some time modernizing the classes to conform with the new requirements for Cocoa and rerelease for sale once we have completed the work.  We also plan on using these PDF classes to enhance our Xojo related developer products, particularly Formatted Text Control and BKeeney Shorts.

Asher Dunn, the original developer of the Fireye PDF classes said, “I am happy that my work was highly valued by the community.  I think Bob and his staff at BKeeney Software will do a great job maintaining and enhancing the PDF classes for years to come.”

All existing customers will receive version 2 for free.  An email will be sent to all registered users with instructions on how to upgrade to the BKeeney version.  Once a new version is released existing customers will be able to upgrade at a discounted price.  At this point, pricing has not been determined.

The new home for the FireEye PDF Classes is at: http://www.bkeeney.com/allproducts/pdf-classes/

For more information visit http://www.bkeeney.com or send email to support@bkeeney.com

2014 Training Day Early Registration Price Ends Next Week

Bob KeeneyThe early bird pricing for our 2014 Xojo Training Day ends on December 31st.  Save $200 off full price for our full day of training.

Join us in Las Vegas, Nevada on Tuesday March 25th (the day before the Xojo Developer Conference), at the Monte Carlo Hotel and Resort, as the BKeeney Software staff walk you through creating desktop and web applications using Xojo.  This is a great opportunity to ask questions about your own projects and project needs.  Join the BKeeney Software staff as we share our experience using Xojo (and Real Studio) for the past thirteen years.

More information can be found at https://www.bkeeney.com/xojo-training-2014/.  More information on the Xojo Developer Conference can be found at http://www.xojo.com/xdc/

Place a sure bet with BKeeney Software.  See you in Vegas!

Xojo 2013 Release 4(.1)

Xojo 2013 Release 4 hit the internets this week.  And they promptly pulled it after they discovered a crashing issue when it tried to verify licensing on their servers.  Release 4.1 was released today which fixes the issue.  As far as I know, it’s the only fix in 4.1.

I would characterize Release 4 as a maintenance release as it has several hundred bug fixes and just a few new items. I’m okay with this and if I had any say in the matter I would alternate releases with new features and bug fixes. One thing this release does NOT include is the Xojo Cloud that has been in development for over a year.  I expect Xojo Cloud will be released for the 2014 Release 1 (so it will probably go into beta soon).

The big change in this release is that the IDE and applications built for Cocoa require Mac OS X 10.7 (Lion) or later.  I think this is a pretty good move though it will make life harder for some.  Apple updates their OS regularly and many update their OS when they can because the upgrades have been safe.  I can’t find the statistics but it appears that a vast majority (in the neighborhood of 80%) of Mac users are on 10.7 and above now.  Obviously, if you have clients and customers that require 10.6 (Snow Leopard) you’ll need to stick with Xojo 2013 Release 3 (or continue building in Carbon).

New in Release 4 is new cryptography functions using the Crypto class.  The new class adds RSA encryption to the Xojo framework.  It has functions that allow you to generate public and private keys, verify the keys, encrypt and decrypt data, sign data blocks, verify signatures, and generate a random block of data.

For desktop users, the Canvas and ContainerControls now have a transparent property.  The default is true to maintain current functionality.  This change is particularly important in Linux as child controls on an opaque (not transparent) canvas or container control can be clipped.

The IDE can now use constants for the application identifier which can be useful if your application has multiple names or versions.

Release 4 has a ton of bug fixes and tweaks to the IDE.  This includes many fixes and changes to the Navigator and some of the copy and paste bugs that have afflicted the IDE since its first release.  It’s still not perfect, but it’s getting better.

Better is subjective, of course, but one of the bigger annoyances to many users (including me) is that changing text values in the Inspector (such as a control name) didn’t actually stick unless you tabbed out of the field.  This has been fixed and just this one change alone is worth getting and using Release 4.

There are a few debugger changes that are worth mentioning.  First, the debugger now catches exceptions raised in computed properties.  Before it wouldn’t, which could cause navigating in the debugger to actually change the control flow of the program.  Second there are some specific fixes to the debugger for Windows and Linux users, and finally a new DebugIdentifier property was added to the Thread class to make it easier to debug code that’s running in a thread.

One item of note that came through late in the beta cycle.  Several developers had issues with rejections from the Mac App Store (MAS) due to using QuickTime API calls (or the framework linking to them).  It appears that Apple, while only deprecating QuickTime in Mavericks, is actively rejecting apps that use it.  Release 4 no longer links to QuickTime but according to the Beta list testers this is still an issue.  In my opinion, this is more an issue with Apple, suddenly and with little warning, rejecting MAS submissions than it is Xojo doing anything wrong.

While I like Apple, sometimes getting apps into their store is like hitting a moving target.  Apple giveth and Apple taketh away.  <insert favorite negative Apple cliche here>  If you know more on this, please add comments below.

What are your thoughts about Release 4?  Are you happier with the IDE after 4 releases than you were initially?  Are you looking forward to Xojo Cloud?  What about the eventual iOS support?

[Edit:  Changed wording on the debugger changes for computed properties so it was more accurate.]

Network Link Conditioner

If you’ve been using Xojo Web Edition for any length of time you’ve probably run into this problem:  You code your app and debug it on your local machine and you’re very happy with it but when you put it on your web server it’s slow, unresponsive, or generates some random javascript errors.

Welcome to web app programming.  What’s happening is that on your local machine there is, for all practical purposes, zero latency between the browser and the application.  You can do amazing things wish no latency issues.  I once had a working D&D Mapping helper for Dungeon Masters that used drag and drop on a web page.  That is until I put it on the web server and then it practically ground to a halt.  The end result is that it was a very hard lesson to learn (thankfully it was a ‘for fun’ project).  Drag and Drop in a Web Edition application really doesn’t work due to this latency (not even sure why the events are even there).

Latency is an issue all web apps have to deal with and since Xojo apps do nearly all of their processing on the server this can be of particular concern.  Short of putting the apps on my web server there wasn’t a lot I could do to test this until I found out about The Network Link Conditioner for Mac OS X.

Screen Shot 2013-12-14 at 5.32.53 PMThe Network Link Conditioner is available through Xcode and allows you to simulate network conditions on your Mac as if you didn’t have the super speedy connection you really have.  It’s quite instructional to do this.  You can simulate speeds from Edge, DSL, 3G, Wifi, and Cable Modem with varying degrees of lossy conditions in the wireless options.

To get The Network Link Condition open up Xcode and select the Xcode -> Open Developer Tool -> More Developer Tools and log into your Apple Developer Account and in the Downloads area search for Hardware IO Tools for Xcode.  This package includes a number of things, including the Network Link Conditioner preferences pane.  Download the disk image and mount it.  Simply double click on the Network Link Conditioner prefPane file and the Finder will install it in your System Preferences panel.

Then it’s simply a matter of starting it and selecting the network type you want to test against.  This tool is very cool and I highly recommend it if you are developing for Xojo web applications.  What it will show you is how slow your app is over these types of network connections and will most likely show you where you need to do some optimizations.  Perhaps you need to preload some things on your first page so they’re slower later on.

In one of our current projects we were loading a number of WebContainers dynamically.  This made sense since we felt we didn’t want to load everything when the user logged in and only load the container when they selected it.  This was great but this made the initial selection of the user slow as the server had to create the objects and then push them down to the browser.  The perception was that the app was very slow.

Of course, during development on our local machine we never saw that issue.  Everything was fast and speedy.  But when we started using the Network Link Conditioner we could see it rather well.  We also were able to replicate a few sporadic javascript errors that only occurred on the server (doing things in the WebContainer open events is bad too).

The solution was to load the pre-load containers when the user first logs in.  It takes longer at first, but when the user makes a selection the app has to only issue visible commands to the browser which is very fast.

A word of warning is in order.  Remember to turn Network Link Conditioner off!  It’s easy to forget that it’s on.  If you forget, though, your entire machine will seem slow if you’re doing anything over the network or internet!

What other tools and tips have you found for helping you debug your web applications?

Visual Basic 6 on Windows 8.1

Not a month goes by where we don’t get a prospective client asking about the possibility of converting their old (but working) VB6 application to Xojo.  They always tell me that their project is working great in Windows 7 and Windows 8.  Then comes the but.  But, they feel that they’re living on borrowed time and it’s only a question on WHEN Microsoft pulls the plug on compatibility not a matter of IF.

Let’s face it.  VB6 Service Pack 6 was released in 1998 and official support ended in 2008.  I think it’s a testament to its power and popularity that developers are still using it five years after support was ended.  It may also be an indictment of how many felt abandoned by Microsoft in the move to .NET.

So the questions I end up answering for many are these:

Can we convert their VB6 application to Xojo?

The answer is generally yes.  I’ve come across few projects that can’t (or shouldn’t) be done in Xojo.  There are some caveats, though, because Xojo is a cross-platform programming tool.

If you’re looking for fancy grids that you rely upon in Windows you’ll be disappointed.  As a cross-platform tool some controls are the least common denominator simply because Mac OS X doesn’t support or encourage the same types of grid components.  Apple encourages simplicity which forces different design considerations.  Linux has differences too that force compromises.

Reporting isn’t nearly as robust in Xojo as in VB6 either.  While it’s true that Xojo has built-in reporting components most developers I know find it too weak for anything beyond simple reports.  There are a number of third party reporting tools (including BKeeney Shorts, our particular solution) but none of them are as easy, mature, and integrated as Crystal Reports.

Can we easily convert their project to Xojo?

This answer is a definite no.  I don’t care what anyone says, running your VB6 project through any of the available converters will not result in good Xojo code.  From experience, you’ll end up spending more time fixing the things that it didn’t convert properly than if you had just started from scratch.  In our opinion it’s much easier to rewrite the application in Xojo rather than convert it.

That’s not saying you can’t reuse major portions of the VB6 code in Xojo but, as a developer, I want to analyze it and choose what I want to port rather than having it bring over everything.  There are a couple of reasons for this.

  • This first is that Xojo is really good at subclassing controls.  VB6 was horrible at it and many developers have extensive classes and modules to work around this fact.  Little to none of the code that’s in those classes and modules is necessary in Xojo.
  • The second is that Xojo is pretty good at threading.  Much of the app.doevents code you’ve had to add in your VB6 project because of tight loops to avoid the UI from freezing you’ll do away with and put into a thread in Xojo.  There are some caveats with threads in Xojo but generally it’s a better way to deal with time consuming operations that might otherwise freeze the user interface.
  • The third is that the VB6 best way to do something may not be the best way to do it in Xojo.  A number of years ago we converted a simulation application from VB6 to Xojo (then called Real Studio).  The project used an insane number of control arrays  with various levels of overlapping controls.  The logic was very convoluted.  Rather than try to duplicate the exact same functionality in the same way in Xojo, we were able to greatly simplify the logic and put everything in simple classes.  The ‘unit’ in the simulation handled all of its own actions and generated events for the UI to respond to.  The UI simply passed the user action into the appropriate class instance.  Everything was encapsulated in the classes and in the long run they could have used the same UI front end for any number of different simulations.  It wasn’t the VB6 way and it took some convincing that it was a better Xojo way.  In the end they were happy with the results with a solution that ran on Windows and Macintosh (and Linux if they had requested it).

Windows 8.1

So why bring all this up?  For some reason a lot of people have hit a previous blog while searching about Windows 8 and VB6 during the past month.  I did some checking and while Microsoft has said Windows 8 would still have VB6 compatibility built-in, some developers have had issues in Windows 8.1  The workarounds seem to be fairly simple, but I think most people still using VB6 are wondering if this will be the last version of Windows that will still have that.  VB6 does work in Windows 8.1 but will this be the last version?  Only Microsoft can answer that but given their stated intentions of doing annual updates like Apple it seems likely at some point they’ll jettison some backwards compatibility.

Also a consideration for many of them is Mac compatibility and to a lesser extent Linux.  Ten years ago the Mac version was an afterthought for many of our clients.  Now, not so much, in that they need a Mac version to satisfy their customers or personnel.  The past couple of desktop projects have actually been Mac first and then Windows.  How times change.

Finding Xojo Developers

I’ll put a plug in for ourselves https://www.bkeeney.com/bkeeneyconsulting/.  We’ve converted dozens of VB6 projects to Xojo.  Contact us if you’d like a quote.  You can even put your application through our VB6 Analyzer (https://www.bkeeney.com/vb2rbconversion/) so we can get some metrics about what all is in your VB6 project.  The beauty of the analyzer is that we never have to see your project to give you a rough estimate of the cost to convert.

You can also request the Xojo Developers Network to get in touch with you.  Simply fill out the request at http://xojo.com/support/consultants.php and Xojo developers will contact you if they’re interested in your project.

Support for VB6 ended a long time ago but based on the number of contacts I get it is certainly not dead yet.

When a License Isn’t a Valid License

I will preface this post with the usual disclaimers:  Not everyone will have this issue nor will it even apply to a vast majority of Xojo developers.  Take it with a grain of salt and if you disagree, that is your prerogative.

This week we had a little lull in the development of one of our bigger consulting projects.  It’s a Web Edition project that has 300+ web pages, 250+ WebContainers, 97,000 lines of code and compiles down to about 43 MB of code.  It’s a monster and we’ve been maintaining it in Real Studio 2012 R21.  This week we decided to upgrade it to Xojo 2013 Release 3.

We have 3 full-time developers and a DBA/QA person who is familiar enough with Xojo programming to fix some of the simple stuff.  We already had 2 Xojo pro licenses and bought a 3rd for our other full time programmer that had been working on this project.  The 4th team member won’t ever compile but will need to be able to save in the version control format that we use on all projects into Subversion.

Being a responsible and conscientious user I read the Xojo End User License Agreement (EULA).  Here is what it says:

• A Xojo License Key is required to save a project in Text or XML formats.

With that fairly plain English we bought a desktop license because it would be the most likely be relevant in the future for our 4th team member (since most of our work is desktop apps).  When our team member applied the license and worked on the Web Edition project every time she tried to save the IDE kept doing a Save As in binary format.  Obviously something was wrong with the licensing.

After checking with Xojo Inc. we discovered that the licensing text was incorrect, or at best misleading.  You need the target specific license key to save a project in Text or XML formats.   In other words, to save in Text or XML for a Web Edition project you need a Web Edition license, to do the same thing for a Desktop project you need a a Desktop license and so on.

For us it was not a huge deal.  We needed it so we bought another Pro license and Xojo Support quickly lupgraded our license.  I understand the reasoning behind it but the fact that I looked it up in the EULA just to make sure says the EULA language needs some additional clarification.  I was pretty mad at the time because it wasted my time and a team members time for a half day while we got it all straightened out.

So be aware of those restrictions when you buy Xojo for your team.

Xojo Developer Conference 2014 Sessions Announced

The Xojo Developer Conference (XDC) session list was announced today at http://www.xojo.com/xdc/sessions.php.  The list of topics and people leading them is always impressive and if you’ve ever been tempted to go to a Xojo developers conference it’s shaping up to be a good one with new speakers and new topics.

Of course, BKeeney Software will be there and we’ll be leading a few sessions.  Seth will be leading a session on intermediate database development.  I’ll be doing a session on Xojo Consulting and then Seth and I will be sharing the stage to talk about the state of reporting in Xojo.

New this year, Carol (a.k.a. the database goddess) will be leading a session titled Database for Developers/SQL 101.  For those of you that haven’t met Carol yet she has over twenty years of database development experience and has been a DBA on many big projects in the corporate world.  “Her DBAness” will share her experiences in trying to get us knucklehead programmers to design our databases properly for use in Xojo.

Besides the usual Desktop and Web Edition sessions, keep in mind that Xojo for iOS will most likely be a huge topic at XDC even if there are no specific sessions announced yet.  One can assume from timetables given by the company that it will either be in beta or close to release at that time.

XDC is going to be held in Las Vegas at the Monte Carlo Resort and Casino on March 26-28.  Early bird pricing is $750 and is good until November 30.

See you there!

What Pro Developers Need Out of Xojo

I’ve been a REALbasic/Real Studio/Xojo developer since REALbasic version 3.5.  I’ve been through a lot of versions, UI changes, and have made a fairly successful business using the product.  I am a huge supporter of the product and count a lot of the current and former Xojo Inc employees as friends.  I am also a critic in that I always want a better product than what I have right now.  This post is a laundry list of things that we find lacking Xojo.

The first thing that we want is stability in the product.  Xojo 2013 Release 3 is better than the 2 previous releases but we can still get it to create exceptions fairly reliably (yes, we’ve submitted Feedback reports).   Granted, Xojo has not been out for very long but we also had a year long wait from when it was promised to when it was released and we expected more.  For example, Xojo still hasn’t fixed bugs reported years ago in Real Studio.  Autocomplete still doesn’t work properly with shared methods and properties and namespace objects and there are a few other instances where autocomplete just doesn’t work.

The second thing we want from the product are power features (i.e. things that make my life easier).  The debugger, while powerful, is still essentially the same debugger it was when I started using REALbasic many years ago.  Many people want debugger watchpoints, and a better way to view application data while debugging (tooltip variable values are a common request).  Plugin management is a royal pain for developers like us that have projects spanning a decade.  We’d love to have a complete source code view of an object without having to click on each property, method, event, constant, etc.  In my VB6 days I was a huge fan of MZTools which was an add-in for the VB IDE that provided additional functionality that we’d love to have in Xojo.  In other words, we’d love to have the ability to have IDE add-ons.  We’d also like to have the ability to compile applications via the command line and the ability to create libraries and plugins via Xojo itself.

The third thing we need is better RAD tools.  For a tool that claims to be a RAD tool it has a surprising lack of RAD options.  Despite many years of users asking for it there are still no good options for a data grid control.  Sure, many things can be done with the listbox but it’s not quite what users are asking for (think embedded native controls).  The fact that Xojo does not ship with a basic date, time, or calendar control for many is the kiss of death for using the product.  Make them so basic (like Microsoft did) that any power feature has to be satisfied by a 3rd party developer (like Einhugur).

The last thing we need is better database support.  We see no reason why the recordset can’t have an AddNew function.  Why can’t the DatabaseRecord code be merged into the Recordset?  Currently, the classes are close enough in functionality to be easy to figure out but just different enough to be highly annoying (for example, field vs column terminology).  We’d also love to have a Batch Update function with the recordset and the ability to have Disconnected Recordsets.  Both of these features lead to some interesting and powerful database applications.  Another thing that we find lacking is that there are no built-in options to help the user with database operations as there’s zero error checking on table and field names (other than checking the database error property).

These are things that are on our short list and things that we’ve been talking with other developers since about 2008 when we helped found  the Association of REALbasic Professionals (ARBP).  This list does not include 64 bit support, LLVM, or SSL for Web Edition applications because those are already scheduled to be implemented.

Let me be clear, Xojo works for us – we just want it to be better.  We spend an awful lot of money on licenses and going to the developer conferences because this is what we do for a living.  Doing Xojo development pays the salary for all of our employees.  We depend on the tool on a daily basis and even though we think it’s already pretty good, we simply want it to be better.

So what is on your list of things you really want/need in Xojo?