See You in Frankfurt

Join me at the Real Studio Database Days training in Frankfurt, Germany on November 3rd and 4th.  I am looking forward to talking to the group.  Speakers include:

  • Stéphane Pinel from Real Software
  • Geoff Perlman from Real Software (via video chat)
  • Jens Boschulte from DynaForms GmbH
  • Simon Larkin from QiSQL
  • Thomas Tempelmann
  • Christian Schmitz from Monkeybread Software
I love going to developer conferences.  I get to meet people that are passionate about Real Studio and those that are just learning about it.  What’s best, though, is the cool stuff I learn from those that haven’t spent ten years working with it like I have.
In my recent trip to Nigeria, someone totally new to Real Studio taught me a new technique with web apps.  I can’t wait to try it out on a project.  So you never know what you’ll learn!  See you there!

Visual Basic 6 TIOBE Index

The TIOBE index for programming languages is an interesting visual perspective on programming languages.  Take a look at the graph for the trend of Visual Basic since 2002.

Visual Basic seems to have taken a big hit at the end of 2004.  I’m not entirely sure of why this happened because .NET had been released in February of 2002 in Visual Studio.  Visual Studio 2003 was released in April of 2003 and the next update was Visual Studio 2005 which was released in November of 2005.  Vista was released in January of 2007 so I don’t believe it has anything to do with the operating system either.

Perhaps what’s interesting is that it nearly regains its former popularity in about two years.  Could this have been a reaction that people found .NET to not be as easy to use as VB6?  I know that some people were dismayed that VB.NET wasn’t much like VB6 and abandoned it – especially since Microsoft operating systems weren’t breaking their old VB6 apps.

Since the midway point of 2009 it seems like the bottom has dropped out in VB6 popularity.  Could it be because Microsoft officially ended support for VB6?  Again, speculation on my part, but that is about the time that I started seeing an influx of requests for quotes from people wanting to convert their VB6 apps to Real Studio.

Another huge drop happened in early 2011.  Was this due to the confusion of whether or not Windows 8 will support VB6 applications?  Perhaps.  I have seen another increase, in the same timeframe, of people looking to convert from Visual Basic to Real Studio.

Is Real Studio (i.e. REALbasic) the right choice for your Visual Basic 6 application?  The answer is a qualified maybe.  If you want one code base that works the same on Macintosh OS X, Windows, and Linux and perhaps a similar code base for a web app (Web Edition has separate UI classes than the desktop) then Real Studio might be a good fit.

If you’re looking at converting to Real Studio please do your homework.  Learn a little bit about the language (<shameless plug>Like my training videos<\shameless plug>) and work with it a bit.  Do NOT depend upon any VB6 to RB converters working – there are simply too many things that REALbasic is better at.  You’re better off rewriting your app to take advantage of moderns things like subclassed controls and threading rather than try to force a Real Studio app to behave like a VB6 app.

My final bit of advice is to forget about your ActiveX controls you’ve spent so much money on.  They probably won’t work and they won’t work on the Mac or Linux anyway.  Find and switch to an equivalent, if possible, but you’ll probably create some of your own subclassed controls.  In the long run you need to think in RB-speak rather than VB6-speak.

Real Studio, in the long run, is pretty inexpensive compared to Visual Studio, in my opinion.  I know people that thought of nothing of dropping over $1000 per year per developer on control suites.  Real Studio is much cheaper from that perspective since subclassing controls, canvas controls, and container controls eliminate the need for much of those expensive suites.  The drawback is that you end up doing the work yourself rather than some other developer.  And some things just can’t be done in RB that you might have come to expect in VB6 (like specialized controls in a grid cell) simply because on the Mac or Linux there is no equivalent.

If you want to convert your VB6 app to Real Studio, you can take a look at our conversion page at

Developer Referral Program

We’ve been Real Studio consultants for ten years now.  We also belong to the Real Studio Developer Referral Program.  We get a fair amount of consulting business from the referrals.  It’s probably safe to say that over 50% of our business is a direct result of the Referral Program.

We answer most posts that potential clients add at the Find a Developer Page and while we don’t get an answer from everyone we do talk to quite a few.  What amazes me is how few developers are responding to referrals.  A potential client told me today:

You were the first (and so far, the only) to reply.

This was a fairly straightforward project that was for a cross-platform app.  The client even knows what technologies they want to use.  How hard can that be?

The Developer Referral Program cost $495 for 12 months and $295 for 6 months.  This isn’t a lot of money (it used to be a lot more when it was bundled with priority support plans) and it can easily be made back on a single project.  If you’re looking for Real Studio development work, this is a good way to get into it.

What’s great about the Referral Program is that the people asking for developers already believe they need Real Studio.  There’s no selling them on the benefits of Real Studio – they’ve already decided on it!  Talk about shooting fish in a barrel.

Anyway, I just thought I’d share this with you.  Every Real Studio consultant I know (and I know more than a few) is busy.  There is enough work for more Real Studio consultants.

The Plugins/Libraries We Use

We do a lot of projects every year.  Every project is different but we have a core set of third party controls and plugins we use on a regular basis.  Here’s our list.

Monkeybread Software

I know a lot of people complain about the Monkeybread plugins but we find them to be most useful.  Time is money and chances are good that if there’s a system declare you might need they’ve already done it.  Plus, they are very responsive to bugs and changes to Real Studio.  They’ve been very proactive in developing Cocoa compatible plugins.

The Chart Director plugin is a wonderful charting tool.  It has a ton of features and is very fast.  We’ve used it on a number of projects now and we’ve been very happy with it.

Automatic Updater Kit:  This set of classes and utilities is must have for Mac and Windows apps.  On Mac OS X it uses Sparkle to do automatic app updates and on Windows you can set it to use an installer file.  We’ve automated this (using IDE scripts) to the point where we only need to run one command line function to finish everything (and that only because we haven’t automated the Inno Setup process yet).  We recently modified the code to do some data file updating as well.


We use much of this suite as well.  Real Studio does not ship with Date and Time or Calendar controls.  The Einhugur set comes with nice versions of those as well as a wicked fast TreeView and StyleGrid controls.  They have a number of other libraries and controls that are very useful including their E-CryptIt plugin that offers many encryption, encoding and hashing techniques.  Einhugur has also been very proactive in developing Cocoa compatible plugins.

Formatted Text Control

If your app needs true RTF file support or need inline graphics then this is a must have tool for you.  This is a set of pure RB classes (unencrypted) so you can dig into the guts and make your own modifications (or fix a bug or two as we’ve done over the years).  This is good code to learn from as well.  They recently added masking which is a nice replacement for the crappy masking that Real Studio provides with the TextField control.


If you need anything other than basic (and I mean REALLY basic) reporting the built-in reporting tool isn’t all that impressive.  We’ve moved almost everything over to RSReport.  It’s great because you control everything.  It’s awful because you control everything.  Reports take a little longer to design and get running but the drop-in report viewer and the export to PDF capabilities more than make up for it.  They do have a Report Designer component but I’ve never gotten it to work well in my own projects so I’ve not used it.  Their lack of support is a little disconcerting but so far I’ve been happy with it to take the risk.


We use the eSellerate plugin for our own products.  It handles licensing and registration and though they take a cut off the purchase they’ve been fairly proactive in updating their service over the years.  Their RB plugin has NOT been updated for Cocoa so we really have no idea what we’ll use if they don’t update it.

What are you using a lot that’s not in our list?

ActiveRecord for Real Studio

We are Real Studio consultants.  It’s what we do and we do a LOT of projects.  If I had to put a percentage on the projects that are database driven I’d have to say that it’s above 95% for the past ten years.

Real Studio doesn’t have database binding like Visual Basic 6 but it’s not a real big deal.  If anything, the lack of binding makes the code more explicit (i.e. easier to read) and you don’t have to go hunting through control properties to find table and field names.  The Real Studio database classes are generic so it doesn’t matter, generally, what database you’re connecting to.  The drawback to the lack of binding and the generic classes is that it does lend itself to creating the same code over and over and over again.

Because of the nature of Real Studio many users tend to put their db code into the form (window) and tie it to controls.  This leads to spaghetti code with the database specific code all over the place and makes changes to your database harder.  Seth has done two presentations at ARBP conferences 2009, 2011 and introduced attendees to ActiveRecord that we’ve used for years now.

Active Record is a very simple, and limited Object Relational Model (ORM) system.  It allows us to create REALbasic classes that the IDE knows about.  It’s not exceptionally strong with the relational data, or large blobs, but it can be programmed to handle it.

In a new project we’re converting an existing Visual Basic 6 project with roughly 25 tables and several tables have over a hundred fields each.  Using conventional means it would mean having a database editor open so I can copy and paste field names all the time.  However, using ActiveRecord we created the classes (we have a utility to do this) and now the IDE knows the table and field names.  This makes coding very fast and they’re is no worrying about spelling errors and there’s no longer any issue of what the data type is because the class knows what it is.  This is nice since the compiler will pick up any many errors that may not usually find until runtime.

The client was ecstatic after the conversion since he figured that would have taken about 20 hours to convert the VB6 code into something useable in RB.  Instead, between our utility and ActiveRecord it took me less than 4 hours.  So now instead of spending all the time getting classes ready, we’re doing the real work of connecting up the UI to a set of data aware classes.

Another feature that was added was to flag the developer if a field is in the database that isn’t in the class.  How many times do you add a field to the database (or a coworker does) and you forget to hook it up.  This doesn’t happen using ActiveRecord.  You can have class properties that aren’t a field, but if you delete a field property that’s been used in the application the compiler will flag you on it and that’s very useful too.

ActiveRecord makes extensive use of Shared Methods so that all of the database code for that table is access from that class and that class only.  It has a number of methods built-in such as getting a list of rows (in array form) and finding a record by the primary key.  It’s easily extensible.

Like I said earlier, it’s not perfect.  It doesn’t handle relational data at all, but it can be modified to do so.  Large blobs can slow it down, but in the few times this has been a big deal we’ve implemented ‘lazy loading’ where we don’t load that particular field until we ask for it.

We have a single tutorial page up for it now at the main website.  We’ll eventually turn this into video tutorials and we’ll demonstrate it in more video’s.  It’s an MIT style license so feel free to use it.  If you have additions and suggestions, please don’t hesitate to contact us.

More information, and downloadable classes can be found at

Mockups Using Balsamiq

Our Senior Developer, Seth Verrinder, introduces us to a tool for creating simple and effective mockups. – Bob

Like most developers I’ve had to mock up user interfaces for a lot of projects.

In the past I’ve used two approaches for this: a) Get everyone in the same room and share a whiteboard or a piece of paper or b) use Real Studio to create an interface that doesn’t have any code behind it. I’ve even scanned hand drawn mockups and sent those in an email.

I hate using Real Studio (or any other IDE, it’s nothing against Real) to mock up interfaces. The problem is that the end result looks like it’s a real program, so if I don’t make it look nice then it looks like a program that sucks instead of a mockup of a nice program. The whole point of mockups is that nobody is sure exactly what should be on a window or how different parts of a program should fit together so polishing the UI is a waste of time.

Another problem is that a mockup that looks like a finished program is easy to mistake for a finished program by a non-programmer. This is a point I first heard made by Joel Spolsky over at Joel on Software. Unless the goal is to actually design the final interface for a program I would stay away from this approach.

The advantage of the whiteboard and paper approach is that nobody looks at a freehand drawing and thinks that the end program is going to consist of blue lines that aren’t quite straight. But the end result is usually kind of disorganized and it’s hard to store much less revise it in the future.

Enter Balsamiq Mockups. This is a very slick program written by Peldi Guilizzoni (originally written during nights and weekends while he worked at Adobe). It’s basically a wireframe drawing tool with a bunch of standard UI components like buttons, windows, scrollbars, and many more that look like they’re hand drawn. You can drag things around and change labels pretty much like a designer in an IDE except without any real limitations on where things can go since it’s all just a drawing.

The end result is a surprisingly attractive design that could never be mistaken for a working program or an actual UI. Mockups is developed using Adobe AIR and as a developer of native apps for Mac and Windows, I wasn’t sure it would feel quite like a native app and it doesn’t, but it also turns out that it’s been so well designed that it’s actually fun to use and there’s not really any learning curve to speak of. Overall, I highly recommend mockups to anyone who develops software for a living.

Is Windows 8 the End of VB6 Support?

I was a Visual Basic developer for many years.  Despite the perception that VB 6 made crappy apps, I know of many successful commercial apps that were written in VB6 and, what matters more, is that those apps are still in service.  Despite Microsoft dropping support for VB6 years ago developers were able to limp along and get their apps working in Vista and Windows 7 with few headaches.

Does this change with Windows 8?  I don’t know, but I’m already seeing an uptick in developers that are looking to convert from Visual Basic 6 to Real Studio.  Uncertainty is a bad thing and even the full-time Windows developers I know don’t seem to know what’s going on.  Some of them are even worried that .NET and Silverlight support is up in the air.

The only thing that’s been mentioned for Win8 is JavaScript and HTML5.  No mention of .NET, Silverlight, or even Win32.  It’s very uncharacteristic of Microsoft to be so secretive and up-in-the-air over a future product.  Are they trying to be more Apple-like?  Perhaps that’s why people are freaking out.

Do I think MS is going to drop support for .NET, Silverlight, or even Win32?  Not a chance.  They have way too much invested in each of those to abandon them.  From a corporate standpoint there would be a revolt since almost everyone has invested, heavily, in one or more of those technologies/platforms.

But are Visual Basic 6 apps still safe?  That is a very good question and from the research I’ve done it appears that the VB6 runtime will not be shipped with Win8 though some in the community suspect that a hack will be found before release.  Other comments I’ve seen indicate that Win8 will ship as only 64 bit.  The VB6 runtime is 32bit only so that will mean running in compatibility mode which adds to the possibility of it not working properly for all applications.

Microsoft, at some point, has to kill compatibility.  Visual Basic is an old development environment that doesn’t take advantage of many new technologies.  It’s also not a very good object oriented language – it just wasn’t designed to be that way.  If the MS dev tools of the future are Silverlight, .NET, and JavaScript/HTML5 (does anyone really believe that!?), then it sure seems that VB6 might be on its way out.

So while VB6 apps might work with Win8 using hacks and compatibility mode, I believe developers have every right to be worried.  They’ve invested heavily in VB6 tools and controls and now the (long) honeymoon is over and it’s time to look at alternatives.

If you are only interested in Microsoft then the options are easy with .NET or Silverlight (assuming they aren’t going away).  If you’re thinking of a Mac or Linux version than the options are limited.  You could do Java, but as a long-time Mac user I’m not a big Java fan and try to avoid them because their UI generally isn’t native (I’m a Mac snob, but then most of us are).  Qt is a possibility but it’s not a RAD option either.

I am a little biased but I think Real Studio is a good choice for those coming from Visual Basic.  They are very much alike in how they work though REALbasic is MUCH better at object oriented programming than VB ever was.  It’s newer and is on a regular update schedule.  And, with just a little work, you can easily make apps for Mac, Windows, and Linux that look the same on all three platforms.  And now that Real Studio can make Web Apps there’s a fourth platform that you could potential support (though making a web app involves different controls, editors, etc so it’s not as easy as clicking a checkbox).

Is it a quick and easy conversion?  No.  Don’t trust any conversion program and, from experience, any converter will be just as time consuming (if not slightly worse) as rewriting from scratch.  We’ve found that taking a look at the UI and making it a bit more object oriented to take advantage of the strengths of REALbasic is always worth the investment.  We like to say you’re writing the apps for the next ten years and not only for right now.  So doing the extra work now will pay off for years.

Is Real Studio perfect?  Absolutely not.  It currently is not 64 bit compatible either though I know of many developers that have no issues with running in Windows 7 64 bit.  I do know that 64 bit compatibility is the next big upgrade for Windows after Real Software finishes up on Cocoa builds for the Macintosh side.  If memory serves they are on track for late 2011 64 bit compatibility (though that’s always subject to change).

With Win8 on schedule to be released next year (does anyone really believe that either?), you might need to be proactive and start thinking about the alternatives now.  Waiting until Win8 is released might be too late for your product.  Do you really want to be under the gun from management to get something that works on the CEO’s new shiny Win8 laptop?

If you would like to get a rough estimate on cost to convert from VB6 to Real Studio, we (BKeeney Software) have a VB6 Analyzer Tool for you to download (written in RB of course) that analyzes your project and gives us some metrics on lines of code, controls used, numbers of classes, etc, that help us give you an estimate.  More information can be found at

REAL Studio Magazine May-June 2011

Issue 9.4 of Real Studio Magazine is out.  In this issue there’s a lengthy article about the Atlanta Real Studio Conference hosted by the Association of REALbasic Professionals (ARBP) and Real Software.  The big news is that I am no longer the president of ARBP.  I have truly enjoyed my time guiding the fledgling organization but after three years of organization and two conferences it’s time for me to move on.  I’m not going away as I’m staying on as treasurer for at least a year.  If you didn’t know, ARBP paid members can access the conference videos after logging in to the ARBP website.  Direct link to the session list.

My Briefs article is titled When a Handshake Just Isn’t Good Enough – Why A Contract Is Necessary where I relate about how a recent client stiffed me out of some serious money owed to me.  Of course I didn’t have a contract with him because of the referral and the connections this client has with Real Software and the RealBasic community.  Learn from my mistake and always have a contract in place before doing work!

And, as always there’s a plethora of good information and reviews in the magazine and I highly recommend getting it.  It’s not just for beginners as there is good information for all skill levels.

Lessons Learned The Hard Way #1

This seems like a no brainer, but we’ve been bitten by it and we’ve picked up the pieces of multiple projects from others who haven’t lived by this rule:  If you’re creating a cross platform application, test early and test often on the platform you’re NOT developing on.

Real Studio is a cross-platform development tool.  It runs on Mac OS X, Windows and Linux.  In the Professional/Enterprise versions you can build for other platforms and debug on the other platforms as well while staying your native environment (using remote debugging).  It’s really an awesome experience running Real Studio on the Mac and running the executable via VMare (or even on another machine in the office) running Linux or Windows.

We see it time and time again (and we’ve been guilty of it ourselves a time or two) where someone does all their development on Mac OS X and tests on Mac OS X but their app looks awful once they get it into Windows.  Text backgrounds looks like crap and the flickering is atrocious whenever they resize the window or move controls around at runtime.

The reason?  Mac OS X and Linux have double buffered windows while Microsoft Windows does not.  Mac OS X and Linux always draw to a buffer first and then draw to the screen.  Windows does not which is the cause of much flickering.  Real Studio has some easy workarounds for a bulk of the flickering and some simple rules of thumb to reduce, if not eliminate, Windows flickering issues.  Among them:

  • Canvas objects should have Double Buffering turned on
  • Do not erase the background of Canvas and Container Controls
  • Be wary of using Refresh – perhaps Invalidate is a better choice
  • Layering of controls will almost always get you into trouble.  Putting anything over a Canvas control (that draws anything) is almost a sure way of getting into trouble

So the lesson is that you really should be testing your app in all of the environments you plan on supporting early in your development process.  If you wait until you’re about ready to ship it’s too late.  You might have some fundamental assumptions in the project that’s hard to fix now that you’re almost done.

Cross platform development is easy using Real Studio, but that doesn’t mean there aren’t differences.  You need to test for those differences early and on a regular basis.

Since I spend most of my time on the Mac side I’m assuming Windows and Linux RB developers have the same issues going to the other platforms.  What are some of the issues you see?  Did I miss any reasons for Windows flickering?

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?