What’s Your Real Studio Story? (Part Three)

In the first part of this series I talked about how I got involved with Real Studio.  In part two I talked about some of things I’m currently doing in Real Studio.  In this post I’ll talk a little about the future and what I think where Real Studio will be in the future and my needs and wants as a professional user.

For many people, using Real Studio is a Love-Hate relationship.  Mine is no different.  I’ve been using it for over ten years and while I find it easy to use and very powerful, there are times I feel like putting my fist through the monitor due to frustration.

Real Software releases a new version of Real Studio roughly every ninety days as part of their Rapid Release Model.  From one aspect it’s nice since I know when a new version is going to get released and plan for it.  I know that there will be some new features and a whole bunch of bug fixes.

Unfortunately getting a new version is often an exercise in futility because new releases can sometimes break existing functionality.  Since I work on so many projects I’m often waiting on a particular bug fix in the next version so I’m forced to upgrade.  The frustration of finding yet another bug upon trying the new release is sometimes too much.  If you find me grousing about Real Studio (see last summers Windows rants) it’s generally after one of these types of upgrades.

I’ve been very critical of RS in past because of new features that just plain don’t work.  Rightly so, in my opinion.  New features don’t get tested in the beta process because there’s usually no documentation and usually no example projects showing how it’s used.  Either case is bad and it has to get better.  The perception that Real Studio is buggy, wether right or wrong, has to improve.

Look, I know that every release has significant bug fixes and only a few new features.  I know because I’m part of the beta program and have been for a long time.  But as a beta member I don’t feel like the program lets me help Real Software very much.  I can’t tell you how many times I report a bug, it’s gets marked as fixed and then I have to scour the release notes looking for bug reports that look like mine.

The feedback system and releases aren’t designed to help me verify the fix.  I feel that a bug isn’t fixed until the bug reporter has verified the fix.  From my aspect it’s very inefficient and I wish it was better.  But since it’s not my system I can’t do much about other than offer suggestions.

The future on Mac OS X is Cocoa.  I expect that in the next release or two, the Mac OS X IDE will be built for Cocoa.  When that happens, you’ll know that Cocoa is really ready.  Building for Cocoa will give RB users the ability to harness some of the Cocoa goodies that Mac users come to expect from their applications.

Unfortunately, Cocoa isn’t going to help Windows or Linux as it just makes the platforms that much more different.  However, I do know that much of the work that has gone into Cocoa has involved rewriting major portions of Windows and Linux to fit the newer event models rather than the old Carbon/Classic model.  I don’t know the specifics but it wouldn’t surprise me if almost all of the frameworks was rewritten accomplish this.

I’m not sure where Windows is heading in the future.  Real Software is a Mac heavy company and it’s hard to know how serious they are about Windows.  Last summer there were some very easy and very serious Windows bugs that bit me very hard (because of the upgrade cycle) that very nearly cost me a big project.  I just don’t see much going on for advanced Windows support but perhaps that is just a byproduct of the march to Cocoa.  After ten years they still don’t have full COM support and without it there’s just a bunch of stuff that Real Studio won’t be able to do.  It’s also unknown when 64bit support is coming and when Microsoft will switch over to a full 64 bit OS.  I think this is as every bit as important as the switch to Cocoa on the Mac side.

I have reservations about Linux support.  I wonder if the time and effort is worth it in sales for Real Software.  As a consultant I get no one asking for Linux apps but perhaps that’s anecdotal evidence since I’m heavy into Mac and Windows development.  Also anecdotally my blog and website just have a few percentage points of Linux users that visit on a regular basis.

We know that a User Interface change is coming.  Geoff demoed it at the Atlanta Summit but no pictures have surfaced yet.  From what I can remember, it should reduce mouse clicks as the Project Tab will be easily accessible all the time.  Unused events will not show in the Events list until you add them (I believe the most common event(s) will automatically be added).  A new tool palette was revealed that reminded me very much of xCode/Interface Builder.

I would also expect a lot of the Web Edition editor features will make it into the new IDE.  The in-line editors are generally okay but I’m not a huge fan of them.  I really hate the new Tab Order Editor as it’s confusing once you get more than a dozen controls on the window.  I’m also not a big fan of the object handles (that allow you to resize controls) since they’re a major pain to use – they disappear when you’re resizing.  This means that controls have to have special visual modes to show their sizes unlike the current Window Editor where controls have a visible outline.

One feature that I do like is the pasteboard that is automatically populated at the bottom of the WE page editor when placing non-visual objects (like timers).  This probably means that Dialogs will be rewritten to act just like the new WebDialogs.  One can hope that they will retain the existing methods.  I also expect the Radio Button control to be replaced by the RadioGroup – again, similar to what Web Edition did.

Some of these changes make a lot of sense from a beginner perspective.  They are common questions from new users and are a solution to aid them.  From a power user perspective I’m trying to be as open as I can to the changes.  Some will grow on me I’m sure with usage.  Others, I’m just as sure, will make me pine for the ‘old days’.

We can only hope that Real Software has a feature complete IDE when it makes it into the beta program and lets hope that they’re not adding major functionality to it during the beta.  Otherwise I expect a chorus of very vocal naysayers and boo birds.  A User Interface change is a big deal and should not be taken lightly.  I hope they do their own (very strenuous) internal testing on it before foisting it on us.

Eventually, Real Software will switch the back-end compiler to LLVM.  RBScript is already using LLVM and while that was a significant step, it’s probably going to be a lot of work to switch over all of Real Studio to it.  If my sources are correct, they’re going to writing their own linker for Windows which I have no doubt is more work than they expect (Cocoa was only going to take 18 months remember?).

Will LLVM lead to Real Studio being able to compile for iPhone and other mobile devices?  My answer is a big maybe.  I have a hard time figuring out the marketing for including mobile devices in the current product other than to saying you can reuse much of the same code, but just like with Web Edition you really have a separate product with separate editors and separate compilers.  I have no problem with a mobile optimized IDE that leaves the cruft of desktop and web apps behind.  I think it could be brought to market faster that way too.  Like much of the rest of this post, it’s pure speculation on my part.

One thing I wish was improved was the Real Studio debugger.  Anyone that’s come from the Visual Basic and .NET world understands what I’m saying.  The Real Studio IDE debugger just isn’t easy to use.  No watchpoints and always having to refer to the listbox to view variable values is huge pain (wouldn’t it be nice to hover your mouse over a variable and get the value in a tooltip?).  Many Real Studio users don’t even realize that you can view the call stack since it’s a popup menu (poor UI choice, in my opinion).  Many also don’t get the whole breakpoint and exception handling either.

There is still a bunch of essential controls missing from the standard control list.  After ten years there’s still no date, time, or calendar control.  While the standard listbox is fairly powerful, it’s a beast and you just get to a certain point where it’s too slow and cumbersome to use.  For those needing them, they’re forced to use a 3rd party set of controls.

I think much of these limitations is all based on how Real Software uses the tool themselves.  The IDE has absolutely no need for grid, date, time, or calendar controls.  You could certainly argue that the reason why the TextArea RTF support is so weak is because the IDE has no need for it.  The same with the lackluster support for TextField masks.  Likewise, to the best of my knowledge, the IDE does not use the built-in reporting tool and, it too, suffers from having no strenuous use from the company that designed it.  Modern toolbars?  Need I say more?

I’ve argued for years that RS could really use a consulting group that bids and works on projects just like the rest of us consultants.  A lot of the projects I work on run into the same constraints time and time again and I’m forced into less that optimal solutions.  I can submit Feedback reports until my fingers bleed, but until RS has to fulfill a need for themselves it probably won’t happen.  Personally, I’d welcome them into the consulting business.  Sure, it means more competition for me personally, but I’m okay with that as it will make the product better.

Sorry for the rambling post as there are lot of things that I’d love to see RS do a better job at and improve in the product.  I really do appreciate the work they’ve done as it pays for my, and my employees, salaries.  As a professional user my needs are vastly different than a majority of Studio users but as someone who spends a considerable amount of money on yearly license updates and the referral program, and spend a lot of effort selling the product to clients I feel that my needs should be aired publicly.  My time with ARBP has shown that many of you agree to varying degrees.

Those are some of my wants, needs, future predictions, fears, worries and gripes.  What say you?


11 thoughts on “What’s Your Real Studio Story? (Part Three)

  1. The only point where I do not completely agree is regarding Linux support – but I’m developing for Windows & Linux, not Mac. Apart from that +1 on the whole post.

  2. My foray into the “REAL” world has been somewhat tepid, as my product line is already successful and I can take longer than most projects could. On the other hand, my products are built on VB6 there may only be a finite amount of time afforded to me by Microsoft (windows 8 could pull the rug out from under me). The steady rise of the Mac and gradual market recession of Windows, got me to looking around for an alternative to VB. Not a chance in the world I was going to learn Objective-C and maintain 2 code bases, impossible when you are a single person, Micro ISV. REALbasic looked to fit the bill so I gave it shot.

    I cannot tell you the thrill of taking my first prototype that I had completely designed and built on Windows over to the Mac and outside of a few formatting issues, the thing worked on the Mac, interface, database and all. One of the great computing moments I have had in my 25 years as a developer, a real “wow” moment. Of course, all is not perfect in this new little world I had discovered:

    1. There is a much smaller 3rd party tool offering than I am accustomed to with Visual Basic.
    2. The REALbasic product is fairly buggy in my opinion, and I just don’t think RS is as serious about these bugs as I am. I know fixing bugs is not fun, sexy or sellable, but it sure keeps users around. Just wished it was higher up on their priority list, Big example: under XP, you cannot use it for more than 2 or 3 consecutive sessions, because some kind of memory leak makes the compile time longer and longer and you have to restart Real Studio every few iterations. I was told that several RS engineers had looked at it and couldn’t fix it. Fine, but quit saying it works on XP, because it doesn’t. (is OK under Windows 7, by the way).
    3. The tablet and Mobile environments are taking off like a rocket, so I am hoping that at some point I’ll be able to crank out iPad code our of RS, but have no idea how feasible that is. All I know is my target environments were clearly defined 2 years ago: 85% Windows / 15% Mac and all that is changing a heck of a lot faster than I want it to. I hope Real Studio is there to address this shifting market when I need it to. It has been quite an effort to investigate not only REAL Studio, but also all of the tools I need to bring my product line (3 products) from VB to Real. It is workable, but a lot of work still ahead. I REALLY don’t want to have to do this again from scratch with yet another language to address the tablet market if (when?) it puts a serious dent in my desktop market.
    4. The debugger in REAL Studio is down right primitive compared to VB6, which is a 13 year old product. And I’m not talking about edit-and-continue, I know that is not happening. I’m talking about simple things like a single key to step through debug code (control-shift-I? Really.) Viewing global or module-level variables is an unbelievable pain. A tool tip when the mouse hovers over the variable is so superior to what is offered now.

    All in all, I like the product, the people at the company, and the user community and look forward to getting as good RB as I am with VB. I think this going to fly.

  3. > The Real Studio IDE debugger… wouldn’t it be nice to hover your mouse over a variable and get the value in a tooltip?)

    Oh, how I’d kill for this. Vote for it!

  4. “New features don’t get tested in the beta process because there’s usually no documentation and usually no example projects showing how it’s used.”

    — Yes. The documentation issue has been an enduring problem for as long as I can remember.

    “The perception that Real Studio is buggy”

    Sometimes it’s the things that don’t even matter. When I last upgraded I lost a day from my previous expiration date (you’d think that adding a year would keep the same expiration anniversary date but it doesn’t. My birthday is on the same day each year but that logic doesn’t hold in the esoteric computing world of microseconds) . It’s a stupid thing that rationally I know doesn’t matter because #1 what are the odds a new release happens on that day I lost and #2 I usually upgrade several months in advance. But nonetheless I had this irrational sense that the version was buggy and I was suddenly hyper-aware of any issues that popped up. In short, the little things can matter to perception and for humans perception is reality.

    “From what I can remember, it should reduce mouse clicks as the Project Tab will be easily accessible all the time.”

    I think this is a HUGE improvement. The current tab system is easy to get lost in and it doesn’t lend itself to spatial memory because as I add tabs the “working” tab moves. I end up hunting around or just clearing the whole mess of them and then opening up what I need.

    “One thing I wish was improved was the Real Studio debugger.”

    Yes yes yes. A thousand times yes. A lot of people complained about the new interface when it came out but I was open minded and saw benefits. One thing that went backward was the debugger. It’s not as self-evident as it once was. As you note the stack in a drop down is a poor choice. It’s economical space-wise but you’re giving up the self evident nature of how the stack functions. Also I can’t ever seem to find stuff in the debugger. Well… I can EVENTUALLY but it seems to be laid out in a haphazard manner that isn’t at all intuitive to me.

    Great post Bob. I feel like I could have written it myself in many ways. Several of your points are in my top ten of annoyances. That said, I love the Web Edition and support RS moving forward with new features. I think they’ve heard the message loud and clear about NEW bugs getting introduced. Those are the ones that are the most insidious because it often means missing out on using a new version for project. Old bugs I’ve either resigned myself to simply not being features or have found an acceptable workaround.

  5. MarkP

    Did you try to convert to vb.net at all? The upgrade wizard to vb2008 is pretty good.
    The migration effort to vb2008 is a lot simpler to the one to RB I think.
    Once your code is in vb.net you can easily convert to c#, and have the use of mono tools to access other platforms. Plus visual studio as an IDE!

  6. Yes, I considered it, just not workable for me. My products rely on a lot of 3rd party controls and the early conversion efforts I tried to .NET left something to be desired in terms of the quality of the .NET version of the controls (slow and clunky compared to the VB6 versions). I’d rather do the conversion once and have standalone, native code to show for it. Besides, I know Basic inside and out, much easier for me to pick it up in RB. But thanks for the tip.

Comments are closed.