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?

19 thoughts on “What Pro Developers Need Out of Xojo

  1. Reasonable PDF support… Yes i know about MBS/Dyna PDF, but since i don’t make a living with Xojo (wish I could!) , maintaining 3rd party + Xojo Licenses gets expensive particularly if you want/need more than just desktop.

    I agree about more controls for RADness…

    Yes cell based grid control would be nice but I’ve been able to make the listbox do everything I’ve needed. Years ago the listbox did frustrate me, but between features added over time and learning the API, it’s not at the top of my list now.

    About a decade and a half ago I was using filemaker… They had a control where you laid out controls for record and that became a “listbox” (scrolling list of container controls for each record) that could be seen/scrolled on the screen or printed with good quality… You could mark controls NOT to be printed IIRC.

    Explicit support for something like that (though from any data source not just a DB) would be nice. I keep thinking about doing something like that in Xojo but am not sure how to make it general (the API)

    DB support could be better.

    From the talk pre Xojo I had the impression that with Xojo there were going to be major additions in that area in the IDE to coincide with the DB license… I don’t consider the new editor to be that.

    • Reasonable PDF support… Yes i know about MBS/Dyna PDF, but since i don’t make a living with Xojo (wish I could!) , maintaining 3rd party + Xojo Licenses gets expensive particularly if you want/need more than just desktop.

      Minimal PDF support, I believe, is already scheduled. If I had to guess, it won’t do everything we want it to be but perhaps it will be ‘good enough’ for what most developers want.

      Yes cell based grid control would be nice but I’ve been able to make the listbox do everything I’ve needed. Years ago the listbox did frustrate me, but between features added over time and learning the API, it’s not at the top of my list now.

      So have I, but getting native controls into the cell would be really nice.

      From the talk pre Xojo I had the impression that with Xojo there were going to be major additions in that area in the IDE to coincide with the DB license… I don’t consider the new editor to be that.

      I know they have ‘plans’ but I think the new IDE (and it’s multiple iterations we never saw) took way more time than they anticipated. Add in that iOS and LLVM are fast approaching and my guess is that we’ll have to wait for a while to get the major additions. Oh, and add in that they were short a developer for a couple of months and the new guy isn’t completely up to speed yet.

  2. My needs are simple: I need a debugger that doesn’t crash.LLVM would a great so that I don’t have to fear into running into plugin problems every time I update the MBS plugins.

    I had to look up what a disconnected recordset is and it sounds like a view. Your database wishlist needs a bit more perspective IMHO. Therefore, I would like to see a robust ORM framework for working with databases.

    For newbies the lack of GUI controls is annoying. But for us Pro’s this isn’t a big problem.

    • I would like to see a robust ORM framework for working with databases.

      A few developer conferences ago they showed off some ORM concepts but, if memory serves, it was going to only be for SQLite which lessens its appeal for me. It’s part of the reason why we’ve continued development of ActiveRecord.

    • I’m not sure that LLVM will help with plugins. If I had a bit of advice to offer on the MBS plugins and that’s to not update every single release. I only tend to update when I run into a problem and I’m sure it’s MBS related.

      Well, we have our own ORM (ActiveRecord) that supports quite a few different databases (or will when we release it). The ORM that Xojo Inc has mentioned will probably only work for SQLite. The disconnected recordset is much more than a view. It allows users to query the db, add new records, edit exiting ones and then send them to the database.

    • I need a debugger that doesn’t crash

      I know they recently fixed a bug when stepping through code quickly (I think this was part of R3). Are you experiencing other crashes? Have you submitted Feedback reports for those instances? I know I was contacted recently for a very specific bug that crashed the debugger.

  3. I generally need quick solutions to database problems. I don´t want to be sitting there populating listboxes and coding data entry behaviours and validation in detail. Often I just want to stick a datagrid on a form attach a record set to it and then tweak it to my needs. Delphi on Windows does this well (unfortunately just on Windows) and in my world good support for SQLServer and Oracle databases would do nicely.

  4. I think all the issues boil down to the fact that REAL Software is severely resource/manpower-restricted. I think the algorithm in use is:

    a. Is there a workaround of _any_ kind for a particular bug? If yes, ignore the bug.
    b. Does the bug affect the IDE code? If no, ignore the bug.
    c. Is the bug older than a year? If yes, it’s stale and can safely be ignored.
    d. Will a new feature or platform gain more users, or get existing user to renew in the hope that the feature will appear before their license expires? If yes, announce its imminent release.
    e. Is a bug merely an annoying IDE one that slows down development by less than 80% and/or causes hair loss? If yes, ignore it.

    Joking (sic) aside, I renewed for two years assuming that the new IDE would be usable for large projects. Bzzzt. I’m hoping, probably fruitlessly, that the major annoyances in 2013r3 will be fixed in 2013r4 (or probably 2014r1 as things are progressing now).

    Meantime, it’s back to 2011r3 t get some real work done.

  5. To me, the debugger is the most deficient thing in the IDE. There is the expectation that they will fix the current bugs that have popped up in the new IDE. And hopefully the Navigator will get to the point where the things that bug me are outweighed by things I like in it. But the Debugger just doesn’t seem to get any love, any traction, and sense of visibility with the Xojo staff or feedback. “Yeah, we know it is lacking” is pretty much all I hear. Next to coding and testing, debugging is the thing many of us do a lot of. And coming from the VB6 world of watch points, bookmarks, single key step debugging, watch points, edit-and-continue, and tool tips to quickly show variable values, the Xojo debugger is stuck in the Stone age in comparison with a tool that hasn’t been updated in 15 years. Now that is bad. And what makes it REALLY bad, is I don’t think there are any near term plans to address its woes. The Debugger just isn’t given much love, and that is a shame.

    • From conversations with former Xojo developers, the debugger is a huge, big, messy project. The fact that a long-time debugger bug (crashing when quickly stepping through code) was recently fixed it’s obvious that it’s receiving some attention. Just thinking out loud but I would think that 64 bit and LLVM would force some debugger changes which might facilitate the need to update portions of it. And if they’re changing one thing perhaps they’re changing other things….

  6. > And if they’re changing one thing perhaps they’re changing other things….

    … and breaking them in the process 😉

    My needs are simple. I just want basic functionality to be rock solid. If (for example) StyledText is broken and has 20 reported bugs then I want StyledText to be fixed – and not one bug fixed and 19 left in there. Make it a consistent whole. Some bugs (especially those regarding non-ASCII text like Umlaute or accented characters etc) are just embarrassing.

  7. @Bob: I just meant the general crashyness of the debugger when stepping through code. The one from at least 2006 or 2007 and this baby is NOT fixed in 2013r3. Or do you mean for the next version? I never bothered to report this because I never was able to get this crash reliably. The crash log is always the same:

    Thread 8 Crashed:
    0 rbframework.dylib 0x01590340 0x1565000 + 176960
    1 rbframework.dylib 0x0159c853 0x1565000 + 227411
    2 rbframework.dylib 0x0159aa38 0x1565000 + 219704
    3 rbframework.dylib 0x0159a61e 0x1565000 + 218654
    4 rbframework.dylib 0x0158f508 0x1565000 + 173320
    5 rbframework.dylib 0x0158fca1 0x1565000 + 175265
    6 rbframework.dylib 0x0158fd7b 0x1565000 + 175483
    7 rbframework.dylib 0x015a24da 0x1565000 + 251098
    8 rbframework.dylib 0x01586b86 0x1565000 + 138118
    9 rbframework.dylib 0x0158fa65 0x1565000 + 174693
    10 rbframework.dylib 0x0159bc6c 0x1565000 + 224364
    11 rbframework.dylib 0x0159b4aa 0x1565000 + 222378
    12 rbframework.dylib 0x0159b3df DebuggerHook + 319
    13 Mail Archiver X.debug 0x00bc5c7f MoveToTrashOutlook.doDate%%os + 1870
    14 Mail Archiver X.debug 0x00bc530a MoveToTrashOutlook.doIt%%o + 690
    15 Mail Archiver X.debug 0x00ba051c MoveToTrash.doIt%%o + 264
    16 Mail Archiver X.debug 0x00b82448 ArchiveThread.ToTrash%%oA1o + 1094
    17 Mail Archiver X.debug 0x00b815ef ArchiveThread.DoWork%%o + 5847
    18 Mail Archiver X.debug 0x00b7feb0 ArchiveThread.Event_Run%%o + 64
    19 rbframework.dylib 0x0158ac54 0x1565000 + 154708
    20 libsystem_c.dylib 0x977225b7 _pthread_start + 344
    21 libsystem_c.dylib 0x9770cd4e thread_start + 34

    • If you’ve not submitted this bug via Feedback then how do you expect it to get fixed?

      The one from at least 2006 or 2007

      Can you be a bit more specific? I’ll add it to my Top 5 list if that will help….

  8. a nice wish list, Bob. However, would you mind to add the corresponding feedback links to the individual requests, so I can quickly add items that affect me as well to my watch list or add some of my valuable feedback points to cases I like to support?
    I assume you do have reported these things in feedback, haven’t you?

  9. Bob, Big thank you for your reviews and posting honest non-bias pros and cons on Xojo. I was searching just for such a review before buying Xojo and starting Mac application development. As a Delphi developer since version 1 in 1995 I am a huge critic of all other development tools for Windows platform and the utter primitive capabilities when compared to Delphi. And I still work with a 6 year old version of Delphi. While Embarcadero is FINALLY working on cross platform development it’s a frustrating process just to get it installed so I’m going to embrace Xojo in hopes of mature tool to get our Mac development projects off the ground. Thanks again.

    • You are very welcome, thank you! I can be a guilty as anyone on getting caught up in bugs and annoyances but I *try* to be as balanced as possible. I’ve been using REALbasic/Real Studio/Xojo for around 12 years. It has many strengths, a few weaknesses, and a few areas that downright stink. At the end of the day, all I want is a product that helps make money for us and our clients so I guess it just needs to be good enough in all areas.

  10. Chart Control
    DataGrid Control
    Debugger
    X64
    Bring back the Database license to all platforms. If Xojo want to be a modern RAD Tool a separate license for db connection is like selling a new car but without the fuel tank.

Comments are closed.