OpenBase Adds RealBasic Stored Procedures Support

In the wee hours of this morning, while I was sound asleep, my server received an email from OpenBase announcing that OpenBase 9.1 will be released on September 14th.

Usually I’d just delete such an email as I’ve yet to use OpenBase in anger, and haven’t really played with it for a couple of years now, when I first had a dabble with WebObjects. However, in their list of new features for this version was support for RealBasic Stored Procedures, which caught my eye.

This sounds great, I’ve spent the last year writing RealBasic code, and so am slowly getting more and more comfortable with it, to the point that I miss it’s features when working in other languages. So this announcement along with the much anticipated “Swordfish” web application framework from Real Software is starting to make my investment in time and money in RealBasic a good bet.

Of course, I haven’t got OpenBase, don’t as yet have a really good use for it that would warrant spending that kind of money (I’ve always felt it costs just a little more than I can afford), but with all the other improvements and new features that are in v9.1, I’ll certainly be looking at it again soon. It’s maturing nicely.

No comments.

  1. RealBasic looks like a smart move for a desktop development language. Windows, Linux, and Mac support all from 1 code base.

    What is the Mac version like? Is it indistinguishable from the Cocoa apps?

  2. Yeah, RealBasic is great, it’s getting better and better at creating apps that look and “feel” like a native app on Windows, Linux and Mac.

    If you look at my screenshots you’ll see it’s not a bad simulation of a Mac app!

    In the end, it’s up to the developer to adheare to the UI standards of the platform, doesn’t matter how good the widgets look, if you size them wrong or put them in the wrong place, things just look a little off.

    I’ve actually got to make a few changes to CaseDetective inn this regard as my OK/Cancel buttons are round the wrong way on Windows.

  3. One more question for yeah about RealBasic.

    Does it pick up the latest look of OSX? I know the Aqua look has changed in every release of OSX, and I was wondering if the RealBasic apps automagically use the latest look.

    ok, one more ;) … Is there an option for that brushed metal look?

  4. Yes is the answer to both questions.

    You should think of RealBasic as a framework, it allows you to write code to the framework, and then compiles native applications for your target apps that use those OS’s APIs.

    So the Windows EXE file that gets compiled from the same source that also makes the Mac and Linux binaries, will look different on Windows 98 to how it looks on Windows XP, simply because the OS does the “skining” and so on.

    I expect Real Software have to do some stuff under the hood to allow your apps to take advantage of some of the different OS versions your app might run on, but I don’t know for sure.

    You also have #IF for conditional compilations:

    #IF TargetWin32 Then
    // Do Some Windows Specific Stuff.

    #IF TargetMacOS Then
    // Do Some Mac Specific Stuff.

    and so on for various targets, even TargetHasGUI for if you’re doing a service/command line app and DebugBuild for when you want to do some extra logging and so on during debug runs.

    It’s a pretty rich environment, I’m looking forward to RealBasic 2005r3, when I think I’ll be able to switch from v5.5.5. There were a lot of changes for v2005 with a whole new IDE, I think v2005r3 will be stable enough for me to use full time, although 2005r2 hasn’t been a major problem for me during testing there were too many problems reported on the mail lists for me to feel comfortable moving my project across.

  5. That’s pretty damn cool. If I ever finish my app for my microISV attempt I might sit down and build a little test app in RealBasic. I’m such a huge fan of 1 code for all platforms.

  6. Then you’ll really enjoy RB — it’s the best write-one-deploy-everywhere solutions out there. I don’t like Java or GTK, et al simply because the look and feel is never right (or even marginally close).