RB 2010 R2.1 Has A Nasty Windows Bug

Be aware that RB 2010 R2.1 has a nasty Windows-only bug that might affect you.  It seems that the keyboard accessibility for pushbuttons (and possibly other controls) no longer works properly.

To duplicate, put two pushbuttons on a window.  Put a message box in the Action event saying which one has been pushed.

Test it with the mouse.  Works fine.  Now tab to each pushbutton and press the spacebar.  Works fine.

Now, tab to each one and press the Return or Enter key.  Nothing.  If you happen to have a default pushbutton the Enter/Return key will activate that button regardless of where the focus is.

Nasty bug that leads the average Windows user to curse your name in vain if they rely on the keyboard to navigate.  I spent hours trying to figure this one out because it manifests itself in the MessageDialog class too.

Yeah, I’m a little pissed.   I have to revert to RB 2010 R1 where it does not manifest itself.  The hard deadline for the project I’m working on is today.  Gives me a black eye for a problem outside of my control.

For those that care, Feedback ID 12626

What Controls Would you Pay For?

I’m a big fan of the Einhugur control suite for REALbasic.  In particular, the Einhugur TreeView, Calendar, Date, and Time controls often find their way into my projects, both internally and for consulting projects.  The StyleGrid also gets some consideration for many projects as well.

A recent post on the Monkeybread Software blog mentions a number of bugs about the ComboBox control.  I agree with Christian’s assessment of the state of the ComboBox control.  I made a comment (currently awaiting moderation) that I thought that a 3rd party could sell a full-featured combobox control.

I’ve mentioned in the past that I would help finance someone to come up with a cross-platform WebKit plugin and, as of yet, no one has made one or approached me taking me up on the offer.  REAL Software has indicated that they’re looking at it.  Given their workload I’m not sure I expect it anytime soon.

I’m also a big fan of the True North Software Formatted Text Control.  I’ve used it in quite a few projects and find it to be a very nice replacement for the the TextArea control.  For now, it’s the best way to get true RTF support in your REALbasic application.  It’s also very extensible so if you need it to do something special you can modify the source to do it (though it might be a lot of work).

Other things I’d like to see:

  • A multi-column popupmenu/combobox
  • A grid control that supported container controls hosted in individual cells
  • A list view that could switch between column (Mac OS X), TreeView, List, and Icon View.

What is on your wish list of controls for REALbasic that are currently not available?  Why isn’t there a bigger market for 3rd party controls?

Guidelines

As you start to code all day, every day, you start to develop your own set of guidelines.  I’d call them rules, but since I break them often enough I have to call them guidelines.  Since I deal with my own code and Other Peoples Code (OPC) on a regular basis here are my guidelines (in no particular order):

  • Name any control you reference in code.  It needs to make sense to you.  If you have a bunch of Pushbutton1, Pushbutton2, etc. pushbuttons you are causing yourself grief in the long run.  You’re coding not only for right now, but for 5 years from now when you’re not intimately familiar with your UI and you want to make a change or fix a bug (or hand it off to a consultant).
  • If you find yourself copy/pasting code over and over again you should think about a global method or perhaps a subclass.  I’m talking about the MessageDialog alerts, the ComboBox helper code, etc.  The reason this is a problem is that if you have the same code all over the place and you have to change it, you then have to change it everywhere.  The chances of missing one hase big bug implications and your clients/customers may not appreciate the bug.  This is called, by the way, refactoring and it’s not a bad thing to do.
  • Big, huge, monolithic methods/functions are not good.  My general rule is that if my method is over a screen length I start looking at ways to break it up into smaller chunks.  This makes it easier to debug too since the runtime exception doesn’t have line numbers on where a bug occurred.  All it can give you is what the error is and where it occurred (and even sometimes that’s not reliable).
  • Name your variables something that make sense to you.  You need to come up with your own guidelines, but the reason is the same as naming your controls.  You should, at a glance have some level of understanding of what the variable is for.  I don’t name loop variables (i, j, k, x, y, etc) unless I have nested loops.  Some would argue that prefixing your variables is a dumb idea because RB is very strongly typecast and if you change the type you then have to change the prefix.  Um…sure…that’s what global search and replace is for.  But I can tell at a glance what type the variable is.
  • Name your methods/functions something that make sense.  Same reasons as above.  If you can’t figure it out at a glance what it does, then you might need to rename it.
  • One that keeps haunting me (in other words I haven’t always learned the lesson on this) is to use a thread whenever there’s a tight code loop.  It always seems that during testing I have far less data than I will in real life so that tight loop that only takes a blink during development takes seconds in production and causes the app to ‘freeze’.  Threads are a natural way to solve that problem.  I urge you to not use refresh statements in your loops – instead use a thread.  Of course threads aren’t perfect in that you then have to worry about how you update UI but if you have the Thread in the window you’re generally pretty safe.
  • Test your cross-platform apps on each platform.  Don’t assume that your Mac OS X application created in RB will look good on Windows and vice versa.  Trust me on this one.  Depending upon what you’re doing, Windows can be hugely different performance-wise than the Mac and Linux.  Double-buffering is standard on Mac OS X and Linux but NOT on Windows so that really great looking custom control on Mac/Linux looks just awful on Windows because of flickering.
  • Project organization is important.  As your project gets bigger and more complicated having the big monolithic list of objects becomes harder to find things.  I generally start with Application, BKS, Others, and Assets folders in my projects and put everything in those folders.  The assets folder is icons and any other graphics for the projects.  The application folder has all app object, all the windows and application specific objects.  The BKS folder contains my own toolset of classes, subclasses, extensions, etc that I’ve written and use in most projects (I generally try to retain rights to any code in this folder).  In the others folder is my toolset of objects that are from others and I don’t claim that I wrote.  Some of these are encrypted and others are not.  Keeping your project tidy is a good thing.
  • Code first for functionality and once it’s working you can test for efficiency.  I’ve found that some things I thought would be slow weren’t and some things I thought would be ok weren’t.  Get it working first and THEN worry about it.

Those are mine off the top of my head.  What guidelines would you share with someone new to coding and/or REALbasic?

Beta Program Ruminations

Earlier in the week I mentioned that I thought the REAL Software beta process is broken.  I’m a passionate user and I use RB all day, every day, so I have some strong opinions.  I happen to know a thing or two about testing on a commercial software product.

Earlier in my software development career I was the lead tester for a printer utility (for a very large printer company).  I was in charge of the test scripts (imagine the same test on 30 printer models for each beta release – yeah it was mind-numbingly dull) that each tester used to report bugs.  We’d find a bug in Test 3.13b (how to reproduce), explain what the error is and sent it to the developer in charge (via the bug tracking system).

The developer would fix it and then the build developer would put together the list of changes for that build and the system would then send the bug back to the original tester for verification.  If it passed our test (with the next build) we told the system that the fix was verified.  If not, it got sent back to the developer.

Then, when the developer made a public release, the fixed and verified bugs were put into the change list.  Depending upon how late in the process we were, verified bugs were listed as known bugs so the public testers didn’t report the same bug a billion times.

It’s a tedious process but it’s the only way to really do a beta program.  If you assume that you really want a quality (good enough?) product you need to slow it down and be tedious about it.

So why do I think that the RS beta program is broken?  First, in this release, several bugs were listed as fixed and were clearly not.  This, to me, says that there is no verification process on fixed bugs, or if there is, it’s not a very stringent one.  I understand how this happens because on small teams everyone is maxed out.

It could also be that the bug, as described, was fixed but it didn’t fix the overall problem.  I could easily see this happening.  The developer has a long list of things to do, looks at the bug report, fixes it, verifies it to his or her satisfaction and marks it as fixed.  This, all without a deeper look at why the bug is occurring.  I understand because it’s happened to me.

I would also posit that that the beta program, as it exists, doesn’t work the way that benefits REALbasic (and us end users) the most.  Bugs are getting introduced into the product.  Bugs aren’t getting fixed.  New features don’t get tested properly and take several releases to get working properly.

The beta program asks members to test each build against their projects.  Here’s the ugly truth:  When you ask me to test ‘everything’, it’s like asking me to test ‘nothing’.  There are a couple of dozen of controls that can be used in millions of different ways.  There are hundreds of REALbasic classes that can be used in an infinite number of ways.  Telling me to test my project against the new version only catches in-your-face, or easily noticeable, bugs.

Yes, there is a change list for each beta version but they never tell the beta list what the changes are per new beta build.  Several developers take the time to parse through this list and then publish what’s changed, but why are the testers doing this and not RS?  They should know what has changed in each release and publish the list based on beta build not just an overall list.

ARBP did a survey late last year asking about the beta program.  Most developers said they did it for early access to the next release.  This is akin to saying, “We are part of the program to make sure it doesn’t muck with my project.”  Sure, they test, but is it what RS really needs?

My recommendations.  Not in any particular order and some are mutually exclusive:

1)  Since the beta program isn’t producing the feedback RS needs/wants early enough, scale back on bug fixes and new features and do more internal testing for each release.

2)  Provide guidance on each beta build as to what to focus testing on.  If the listbox received a lot of work, then say that.  As a beta tester I should focus on the listbox.  With Cocoa receiving a ton of changes for each build, it would be helpful to know what the developer wants tested.

3)  Scrap the program entirely and rebuild it by invitation only.  This ensures quality testers and a good mix of hardware, operating systems, projects types, time commitment, etc.  Perhaps even do groupings of people to focus on different aspects of the product in each build.  Group A does controls in this release while Group B focuses on a framework or whatever and in the next release you reverse it.  It ensures that there are always different people looking at different things.  The key here is having as many eyes looking at as many things as possible.  This gets rid of the tire kickers too that provide no valuable feedback.

4)  Have a single person in charge of the beta and build process.  Give that person the authority to delay a public release if beta feedback is too negative or bugs are found at the last minute.  Don’t push the product out the door “just because”.  If there is a legal commitment (for whatever reason) to release on a certain date, then there must be proper time for the testers to vet out problems.

5)  Enforce a proper feedback loop.  Proper discussion needs to take place, both internally and externally, before major things get worked on.  We, users, have a certain set of expectations about features and when no one gets our expectations on record then we end up being overly disappointed in a feature we can’t/won’t use.  We, the users, are the biggest marketing arm of REAL Software.  Keeping us happy makes for happy reviews and comments in public forums.

6)  Don’t ignore beta feedback by saying we’re not the typical RB user.  Um…yeah, we are.  We care enough about the product to give you our time – for free.  Yes, we’re in it for our own interests but don’t dismiss our thoughts as not being representative.

Thoughts?  What would you change to the beta program, if anything?

REAL Studio 2010 R2 Review

I posted my REAL Studio 2010 R2 review on the Association of REALbasic Professionals website.  All-in-All, a decent release (with a few issues) that should please most Windows developers.  Still no Cocoa, though.

What I didn’t say in the review (and will probably be in another post) is that the beta process does not appear to be working very well.  A number of minor (to everyone but the feedback reporter I’m sure) issues were marked as fixed and were clearly not.  I can’t complain too much because I didn’t get a chance to do ANY testing for R2 (because I’m crazy busy with RB work).  Ironic, no?

REALbasic Developer Magazine May/June 2010

REALbasic Developer Magazine’s May/June 2010 edition is now out.  A couple of things of note:

1)  They reviewed the BKeeney Software REALbasic training videos.  It received a rating of 4.9 out of 5 cubes!  As a celebration, we’re offering subscriptions for 20% off list price.  Use the coupon code RBDEVELOPER.  This discount is valid for the next two weeks.

2)  In my regular column I talk about the role of consultant and the jobs you probably should turn down.  Sometimes the client has unreasonable expectations and if they can’t accept REALbasic’s limitations then REALbasic isn’t for them and their project.  Accepting a project like that is just asking for trouble.

3)  Christian Schmitz, of Monkeybread Software fame, gives us some food for thought with an article on how to figure your hourly rate.  All good points.

[Updated 04May2010 16:23] Added link to get to the videos.

RB Feedback Item 3218

We all have our pet bugs and the proper mechanism to express our desire for any particular item is to edit the priorities in the Feedback application and put it in your top five.  A few people can make a significant impact by adding a Feedback item in their top five.  I’m here to today to lobby for a particular bug.

<feedback://showreport?report_id=3218> Save as Version Control format kills external encrypted items with subclassing:  Because this one struck me this morning in a very, very bad way, I put this as my #1 priority.  If you use version control and if you have encrypted items (I use RSReport from Roth Soft) you sometimes get an encrypted file that becomes blank upon saving.  So when the IDE tries to open the project a second time it throws an error because the file was blank.  The trick is to keep a copy of the original file somewhere and replace it, or retrieve the good version from SVN.  Normally it’s a 30 second procedure but today it was an hour diversion.

Needless to say, it’s one of my hot buttons.  Since this one affects me every single friggin’ project I hope you would make it one of your priorities too.

Since we’re talking about Feedback items.  What’s your hot button item that causes you no end of grief?  I’m willing to use one or two of my priority items to put your Feedback item towards the top of the list.  So what is it?

Learn REALbasic With Video Training

We (BKeeney Software) updated our REALbasic Training Videos today with H.264 video as the default rather than Flash.  This allows access for iPad and iPhone users.

We have over a hundred videos and around 20 hours of training videos.  Our Journal Entry project, a simply diary application, goes through the process of creating a REALbasic database application from start to finish.  While we do all of the development on Mac OS X, we regularly go into Windows and Linux and explore the differences between controls and how to workaround those differences.

If you’ve ever wanted to see how other people use REALbasic, this is an excellent opportunity.  We have around two hours of free video (with registration).  Subscriptions are available and if you’re a student or educator, contact us to get up to 40% off full price.  ARBP paid members can get a 20% discount.

So far we’ve been getting excellent reviews!

[Updated]  Part of my motivation to moving to H.264 was to view the videos on my iPad.  The iPad is a really good medium for video training because it can run beside the desktop/laptop computer and you can do the same things in REALbasic while I’m showing it to you in the video.  Video on the iPad is gorgeous!

What’s Your Least Used REALbasic Control?

I was reviewing my list of REALbasic training videos the other day to see what I had missed.  At the top of the list were the DataControl and DatabaseQuery controls.  Technically, the DBQuery isn’t a control, but you can put it on  the window like one, but for the sake of discussion we’ll include it.

I think I gave up on those controls about the same time I gave up on a binding (which is no longer part of REALbasic).  While I think they have their place, I sort of look at them as being too basic and too simple for most of my needs.  There’s nothing about those two controls that is favorable in my mind.  I duplicate their functionality using my own code and have far better control over the results.

Will I do training videos on them?  Probably, because it makes the set more or less complete.  As with some other controls and classes that I haven’t used much in RB career I’m sure I’ll learn something by doing the videos.  Perhaps I’ll change my mind.

Some controls, like the OpenGLSurface, the various sockets, and RBScript objects aren’t used very often either, but when you do they are very powerful and can do a lot of things.

Here’s my list of controls that I’ve never used in any REALbasic project (that I can remember):

  • DataControl
  • DatabaseQuery
  • ImageWell
  • NotePlayer
  • Placard
  • Spotlight

I was tempted to include the Microsoft Office objects, but I’ve used them in a couple of Windows-only projects.  My only beef with them is that their documentation and examples are unbelievably bad.

What is your least used or least favorite control in REALbasic?

REALbasic and LLVM

In my previous blog, one of the commenters asked me about my thoughts on the new LLVM backend compiler that RS is implementing for REAL Studio.  I’ll first start by saying that I am not a backend compiler expert, nor want to be.  Much of what I’ll write about I’m getting from sources that are in the know, as they say.

What exactly is LLVM other than a fancy acronym?  It stands for Low Level Virtual Machine and is a compiler infrastructure.  It was started in 2000 at the University of Illinois and in 2005 Apple hired some of those original authors for their development system.

RB currently uses a custom written backend compiler.  As you can imagine, maintaining a compiler is a lot of work and writing optimizations is not easy.  LLVM was designed for multiple layers of optimization including compile-time, link-time, run-time and even idle-time.

What does LLVM mean for REALbasic applications?  It means that applications should be smaller and faster.  Code that isn’t used will be removed (dead-stripping code).  Currently RB can do this but it’s not exceptionally efficient (but really not all that bad either) as it which leaves some unused code compiled into your application.  For most of us this isn’t a big deal, but for many that start a project with a standard toolset, they might be introducing some inefficiencies into the final product.

Switching to LLVM is great news, though.  Smaller, faster, better are all things to strive for.  Without giving away too much information, the RBScript compiler is being reworked to use LLVM.  It’s a good first step.

But that’s all it is.  If you’ve not used RBScript, let me tell you, it’s not REALbasic.  One of the most powerful features of REALbasic is the cross-platform debugger.  Run in one environment while debugging in the other.  Even when you are debugging locally (on the same machine in the same environment) you’re ‘remote debugging’.  If my source is correct, switching to LLVM will require rewriting the entire debugger because the LLVM metadata system is different than RB’s debugger map system.

Since LLVM uses different metadata properties the current introspection system will break and have to rewritten.  Plugins will also break.  The IDE, the plugin system and even the reporting engine are a heavy consumers of introspection.  So going to LLVM means a huge portion of the product needs to get updated.

Rewriting the debugger is not a trivial task.  To do this the RIGHT way is a huge job that could take a couple of strong backend compiler developers 6 to 12 months to fully implement.  Even hacking it together is probably a 4 to 8 month project and it would still take some time getting the remote debugger to work properly.

If all this sounds daunting and kind of scary, well, it is.  Switching backend compilers is not something to do on a whim.  It has to be well thought out and resources have to be allocated properly.  The roadmap for features that will not be added during the transition time need to be thought out properly as well since limited resources are a fact of life in all organizations.  A small organization needs smart long-term planning.

Make no mistake, though, the backend compiler switch promises to be take a while.  It basically rewrites major portions of the product which will lead to some subtle and not-so-subtle changes.  The risk is high and it will affect EVERYONE.

There’s been some talk about all the ‘freebies’ we will get when using LLVM (such as 64 bit support).  Not true.  Using LLVM gets you ‘closer’ but it still won’t be free.  Switching to LLVM removes one of the many tasks involved with such support.

With all that said, I think moving to LLVM is a must.  If RS wants to support different platforms it’s a smart move going forward.  The optimization capabilities look very promising and will be welcome to many users.  It IS the right thing to do.  Just be prepared for some bumps along the way.

One final word.  I’m a passionate RB user.  I’ve also been a project manager where I think about the bumps in the road before they happen.  I’m not an expert at this stuff, though, so any misconceptions or mistakes are entirely my own.