REALbasic 2009 Release 3

RS released RB 2009 R3 today.  I won’t go into any big detail here as I wrote a fairly lengthy review of the changes over on ARBP.  I will hit on one change that I’m particular happy about.

Back in May is posted about the stupid error message and problem that occurs when you load a version control project with missing files.  I am happy to report that it’s much better now.  The IDE will ask for the missing file and if you click cancel it will load as much of the project as possible.  Before it would just stop loading the project and you’d get a mysterious File Error 0 message.  Now you get this error message:

MissingFiles

This is great but in one project due to file corruption issues I clicked cancel over 25+ times.  So at this point this dialog isn’t exceptionally helpful because it tells me something bad has happened it just doesn’t give me a clue as to which ones were bad unless I happened to write every one of them down at the time the dialog was shown.

What would be more helpful is having a log file of missing files generated or list the files in System.DebugLog.  Either way it would more helpful.  Ideally I’d love to have the option to have it stop asking for the missing files and just create the log file but I understand that the IDE might have to undergo some significant changes to allow that.

And before anyone says it, of course it’s my fault, if the files weren’t corrupt/missing to begin with I wouldn’t have this issue.  Stuff happens – get over it.  Regardless, this one improvement will make my life a little saner.

Is there one fix/new feature that is really good news or bad news for you?  What do you think of the EditField deprecation and subsequent replacement with TextField and TextArea controls?

6 thoughts on “REALbasic 2009 Release 3

  1. I think the EditField split is a great idea (one I had been hoping to see happen for years now). These grand, monolithic controls are horrible and it’s great to see them pared down into more manageable sizes. I hope the ListBox gets beaten to death next.

  2. If I had one complaint is that the deprecation of the EditField came as a complete surprise to everyone (that wasn’t part of the alpha/beta lists). Just like the announcement that Cocoa would be delayed past R3 I think it would have been beneficial to start the discussion earlier rather than get the immediate WTF! responses when people saw the news.

    It would probably happen anyway because the EditField is such a common control. The change affects most projects. Manage user expectations and not their reaction.

  3. Yeah, it was a good technological decision, but an incredibly poor way to force it on users. Trying to maintain backwards compatibility with something like this is basically impossible. So RS is damned if they do, damned if they don’t. I guess I’d prefer to see a breaking change like this happen in a group where a bunch of things are fixed up at once. For instance, split EditField and ListBox at the same time, along with some other breaking changes. If you’re going to make it so I can’t move between versions of the product, at least make the pain only happen once. But who knows, maybe this will be the only time it happens…

  4. Took me most of a morning to sort out the EditField thing, but at least it was doable. Unfortunately, some of the 3rd party software I use no longer works, so I have to wait on the vendor to fix it. I’m guessing he’ll now have to have separate versions for 2009r2 and before, and 2009r3 and above.

  5. One thing I think they should also do is to take the methods that are common to both kinds of new text controls and make them an interface that both will implement.

  6. @silverpie
    I disagree with the interface idea. It just adds more cruft to the product without serving a reasonable purpose. Yes, it would ease a small amount of the pain in the short term. However, the interface would still require support for years and years to come. Who else would be able to get any use out of it?

Comments are closed.