BKeeney Briefs

The other day someone on the NUG list posted a somewhat lengthy message on Web Edition bugs. They were asking “why was Web Edition so buggy after a whole year?” Here is my response (mostly the same but with some changes).

Sure, Web Edition has more than its share of bugs. Like all bugs, however, it all depends upon the beholder.  What bug causes the most pain for RS’ is the one that gets fixed first.  I’ve seen a lot of the same things the community has discovered and have just worked around them (where I can).  I was using WE in a commercial project during the first beta ( a year ago) and while we got it to work it wasn’t very good.  That one project probably generated over a hundred feedback reports.  In my opinion WE really hasn’t really been usable until 2011 R3.

Part of the problem, in my opinion, is that RS has NOT created enough Web Edition applications for themselves.  If you don’t thoroughly exercise the framework you just don’t see the things you’d see in a big, complex application (like we are creating).  There is ONE real world example of Web Edition on their website.  While I don’t know how many examples are ‘enough’, I know that one is definitely not enough.

Web Edition exposes the same problems that we all see in Cocoa, Carbon, and in the IDE on a regular basis.  Unless RS experiences the pain it won’t get fixed in a timely manner because it’s not as important to them.  The Reporting editor and generator and the database editor are but two examples of things in the IDE that RS doesn’t use in ANY of their products. It shows because there are gaping wholes in usage that make them unusable for many developers.

RS takes pride in saying they eat their own dog food because they use Real Studio to make Real Studio.  Admirable, but they tend to be on a restricted diet since they don’t eat everything on the menu.  They rarely change the menu’s for the IDE so the Menu Editor hasn’t seen many changes or enhancements.  As far as I know, they don’t use a database in the IDE so I see no reason why they’d be using the database editor on a regular basis.  They don’t do much with StyledText or Movies so its no surprise that those classes are minimalistic (at best).

Since the IDE has no need for date pickers, they have never provided one.  Likewise, the Listbox is good enough for the IDE while we’ve been asking for a more powerful grid component for years.  Full RTF support?  Forget about it because StyledText is good enough for the IDE. A better toolbar control? Well that one’s a bit of a mystery since the IDE is obviously using something different than what they provide to us.

My point is I’m not sure why anyone would be perplexed about long standing bugs.  Sure, they’re painful to you and me (and my clients), but they’re not (as) painful to RS.

Lobbying the community to get Feedback reports higher in the list is about the only way to realistically get a bug fixed. But even that is a crap shoot as there are quite a few bugs (not feature requests) very high on the list that have been there for a long time. So the only thing conclusion that I can come up with is that the bug that all the rest of us are seeing isn’t painful to RS so therefor it isn’t a priority for them.

This is my opinion as a ten year Real Studio consultant.  I know and respect most of the engineers and staff at RS and I think they do a remarkable job.  However, I think as a company they mostly ignore those like me (an Enterprise user that ponies up thousands of dollars per year) and focus, almost exclusively, on the hobbyists (that bring in a hundred dollars a year at best).  If they could make me happy(ier) the hobbyists would come along anyway (see history of Visual Basic).

Bugs happen in every software product. I remember grousing about Visual Basic bugs when I was a big VB6 user. I know that my code back then had plenty of work arounds for bugs in their API. There is no doubt that Microsoft had more developers working on the product (as a whole) than RS has working on Real Studio. There’s also no doubt that VB6 has a considerably larger user base than Real Studio. I feel that this resulted in more workarounds being posted and more alternate solutions.  The reverse is that our smaller community doesn’t have as many solutions and documented workarounds so it feels worse but I feel that it isn’t.

Anyway, that’s enough on my opinions about bugs and such.  Have a good New Year and be safe. Happy coding!

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 http://www.bkeeney.com/consulting/vb2rbconversion

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 http://www.bkeeney.com/realbasic/activerecord

Will VB6 Apps Continue to Work in Windows 8?  That single question has driven more traffic to this website in the past month than nearly any other question.  I believe VB6 still has a very large user base so it’s very pertinent question for many organizations and developers.  Perhaps Real Studio is an option for them, but we’ll get to that at the end of the post.

Visual Basic 6 is 20 years old.  It’s stood the test of time and it while it’s showing its age it still functions and apps written on it still run in Vista and Windows 7.  To its credit, Microsoft has made sure that this venerable product still runs on modern computers.

But the question of Windows 8 compatibility has hit the fan, so to say, in the past month or so with Microsoft saying that apps can be written in html and javascript.  That threw many developers into a tizzy.

I don’t believe for a second that Microsoft is abandoning .NET, Win32 or COM simply because those are the foundation for nearly everything ever written at Microsoft.  It simply doesn’t make sense for Microsoft to move to another set of API’s even if you believe that Microsoft moves to a new technology every now and then to make themselves a moving target.  If anything, I believe that this might simply be a new way to develop apps but not replace anything.

While doing research for this post I ran across an unattributed quote supposedly from a person in Microsoft Support:

“We can’t make an official comment on our Windows 8 plans yet but it would be a likely outcome that VB6 applications will continue to work. “

I believe that statement but it’s not exactly a definitive statement.  The real question, I think, is how bad will it suck?  VB6 apps work in Windows 7 but without some work they look like they’re from the 90′s.  Most app developers I know don’t want their apps to look that dated.

Microsoft has stated that the Visual Basic 6 runtimes will not ship after Window 7.  This presumably means Windows 8 and beyond.  I have heard that Windows 8 will be 64 bit only and that means that the VB6 runtimes will either not work at all or will have to be run in some sort of compatibility layer.  So this means that existing apps MAY work, but only after jumping through hoops to install the runtime libraries and making sure the compatibility is set.

Let’s face it.  VB6 is an old, old development environment.  It was written in an age where computers didn’t have much memory and only one processor.  Threading isn’t impossible, but the few times I tried to get it working in a VB6 app the result was instability and crashes.  Threading is such an important thing in modern applications.

VB6 is object oriented – somewhat.  For the time it was state of the art but since subclassing controls is impossible it makes for interesting workarounds and wrappers.  Frankly it makes life more complicated than it needs to be.

Twenty years ago, VB6 was the cats-meow.  The Macintosh was around but it was considered a toy (I disagree but that’s not the argument) and few cared about it.  Microsoft was pretty much the only game in town.  Linux hadn’t been invented yet and the internet was for a few hard core geeks.

This is where Real Studio starts to look more attractive.  It works the same on Mac, Windows, and Linux.  Web Edition brings some of the same ease of developing desktop apps to the web.  In Real Studio I can subclass controls and objects (for the most part) all day long.  It’s a modern object oriented programming language.  Is it without foibles and inconsistencies?  Certainly not, but it’s way more powerful than VB6 in many ways.  Threading isn’t perfect, but it’s still light years ahead of VB6.

We’ve seen an uptick recently with people asking us to convert their VB6 application to Real Studio.  Our VB6 Analyzer utility (found at http://www.bkeeney.com/consulting/vb2rbconversion) has been downloaded a lot recently.  It allows users to scan their VB6 project and sends us a simple report detailing the number of forms, classes, libraries and OCX’s in use and lines of code and some other simple metrics.  It’s no substitute for seeing the whole project but it gives us a nice way to guestimate the costs of rewriting the app in Real Studio.

Notice that I said rewrite the application.  The only thing that Visual Basic and RealBasic have in common is that they have ‘basic’ in the name.  It’s like comparing a computer from twenty years ago to a modern computer.  Real Studio does things so much easier, better, and faster than Visual Basic that it’s really not worth trying to convert it line by line or even form by form.  Believe me we’ve tried – the end result is that you end up spending as much time fixing VB6 code that has a better equivalent in RB than it would be to just rewrite it from scratch.

Is Real Studio a suitable replacement for every app?  The answer is simple:  no.  Real Studio makes a really good cross-platform app, but that doesn’t always mean it will have all of the buzzers and bells available in development environments meant for each platform (grids in Windows come come to mind).

We are Real Studio consultants.  That’s what we do and we’ve been doing it for ten years.  Most of us spent a fair amount of time in Visual Basic before moving to Real Studio.  If you decide to do the transition yourself you will hate it at first because Real Studio is different than VB.  We all went through it and for a while you want Real Studio to be just like Visual Basic – trust me it’s not – and after you stop trying make Real Studio function like VB6 you’ll start to like it and get it.  Transitions are never easy.  For training videos, we have over 30 hours available at http://www.bkeeney.com/realbasic-training-section plus you could always hire us to come on site for training.

If you have VB6 project you want to transition please drop us a line and we can talk.  If you want to get multiple Real Studio developers looking at your project, make a post at http://www.realsoftware.com/support/consultants.php which gets sent out to the Real Studio developers network.

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?

 

Converting from Visual Basic 6 to REALbasic is no trivial matter.  When Real Software offered the Visual Basic Project Converter (VBPC) I lobbied long and hard to get it removed from their website because it gave a really bad first impression of REALbasic.  In many respects, it made the conversion process worse because it tried to, and failed miserably, to convert code that couldn’t be converted.  To their credit, Real Software pulled the free application and went back to the drawing board.  Now they’ve come back with a new product called the Visual Basic Migration Assistant (VBMA).  Did they get it right this time?

To test VBMA out, I found a simple calculator control on Planet Source Code (www.planet-source-code.com) to convert to REALbasic.  The project URL is http://www.Planet-Source-Code.com/vb/scripts/ShowCode.asp?txtCodeId=32575&lngWId=1 and you can download it if you want and follow along.  I’m doing this using the Mac OS X version so your results may be slightly different.

When first opening VBMA you are presented with a simple window.  Its minimal design is somewhat confusing but given that you’ve just started the VB Migration Assistant you should probably know that you’re here to try to migrate your VB6 project to REALbasic.  Clicking on the Import Project button allows you to select your visual basic project.  You may also attempt to convert individual items by using the Add Item button.  You may also choose which VB project encoding to use from a simple popup menu in the lower right portion of the window.  Clicking the Next button takes you to the control mapping panel.

The control mapping panel is pretty important if your project uses non-standard controls.  This is your chance to choose the REALbasic control to use.  For example, if your VB6 project uses a TreeView control you could choose to use the RB listbox or, if you use the Einhugur TreeView control you could easily create your own control map to convert use it by creating and modifying the control map.

One oversight in VBMA that needs to be rectified in the next release is that the ControlMap file has no file extension nor does it have a type or creator code so in both Macintosh OS X and in Windows the OS doesn’t know what type of file it is.  In reality, it’s a simple text file and may be opened and edited with any text editor.

There are two checkboxes on this panel that are important.  The first is a checkbox to change all control fonts to System.  The second checkbox is change the font size to zero.  I really recommend that you check both options.  Click the migrate button, name and choose a location for the project and VBMA will create a REALbasic project and open REALbasic for you.

Looking at the RB project it created a new App object, a menubar and a window named frmCalcu.  Opening the window shows us that it did a pretty reasonable job of converting from the VB6 form to an RB window.  In retrospect I might have changed the mapping from the buttons to bevel buttons but that’s debatable and you can play with this later.

Opening the code editor you’ll find some interesting results.  VBMA doesn’t try to convert any code for you at all.  What it does is copy all of the VB6 code into a Notes named after the VB6 object.  It also attempts to copy code into the proper RB control events.  For example, in VB6 we have the event code cmdDot_Click() and VBMA correctly places the code in the cmdDot.Action event.  In this simple project VBMA got everything correct.  Simply running the project at this point creates no errors and our window opens but none of the controls do anything.

Some would argue that Real Software cheated with just copying the code over.  I disagree because even though Visual Basic and REALbasic have ‘basic’ in the name they are not the same language.  Unless you’re going to write a VB6 compiler I don’t think there’s any easy way to convert the language with 100% accuracy so why try?  I think this balances the need to convert the form layouts quickly and getting the VB6 code into the RB project.

Converting the forms, honestly, is the easy part.  The hard part will be converting the code by hand.  We’ll start in the number buttons named Numero.  VBMA conveniently adds some comments at the top of the function that shows what the parameters are and if there is a return variable.  In this case, the Numero.Action passes in the control array index number and doesn’t return anything.  What this method does is read the number and then puts the new number into the display editfield.

If we uncomment all of the code in the project and try to run the project we get a Type Mismatch error on the InStr line because RB expects a boolean value in the IF statement and InStr returns a number.  Simply changing the line to If InStr(txtDisplay.Text, “.”) > 0 Then let’s the project compile and work allowing you to click on any of the numbers.

Then we continue on to the other buttons testing each one.  The cmdDot button is similar to the Numero.  Once we get to the cmdCancel we get to an On Error Resume Next error in VB6.  There is no exact equivalent in RB so this is where some human intervention is necessary.  In this case I’m not sure why they added this error handling in.  It’s entirely possible that the Mid function in VB6 creates an error if the 3rd parameter is negative.  Regardless, it’s a good example of trying to figure out what the original VB6 code was trying to do and then having to figure out the RB equivalent.

Other issues that commonly occur when converting to REALbasic is that VB6 is a very loosely typed language.  This means that you can assign a number to text field and it will happily convert it to a string for you and this is bad.  If you try to concatenate the string “12″ + “12″ in VB6 you’ll get “24″ as the result.  Not surprisingly there is a work around in VB6 with the & symbol.  Using “12″ & “12″ results in the string “1212″.  So when you get to the cmdEqual.Action event you’ll see this code txtDisplay.Text = answer which is valid in VB6 but not in RB because answer is a double and the RB compiler rightly complains about it.  In RB you would change this to txtDisplay.text = cstr(answer).  Alternatively you might want to use the Format function to make the display text better.

A lot of code will convert cleanly.  However, code that will almost always require additional attention are recordsets.  REALbasic’s recordset doesn’t have an AddNew function like Visual Basic.  Nearly anything to do with file I/O is going to be a hassle because VB’s file commands are pretty archaic in comparison to REALbasic’s folderitem class.

The other item of note in our very simple project is that the cmdEqual_KeyPress method should really be the window KeyDown event.  Moving it there and handling the keypress let’s the app work via the keyboard.  Instead of calling the VB click event function we have to convert to the pushbutton push method instead.

This is an incredibly simple project and probably took me more time to ‘convert’ it then starting from scratch, however it gives us some ideas on how the process works.  So let’s take a look at a more complex project.  I took an old VB6 project of my own and ran it through VBMA to see what it would do.

This project is an old MDI-type application, uses Crystal Reports and a few miscellaneous libraries.  The first thing to note is that the Crystal Reports Viewer, zip controls, and the MDI form will get converted to a REALbasic canvas object.  It’s not ideal but I could certainly modify the Control Map to do a little better job.

Another few oddities in the mapping is that the VB6 Common Dialog and toolbar get converted to canvas objects as well.  The REALbasic options don’t include toolbars so I’m assuming that it’s not possible to convert a VB6 toolbar to a REALbasic toolbar.  The common dialog is a bit tricky because there is not RB equivalent so I’m not sure if it’s better to convert it or to come up with a helper object to make it easier to deal with later.  Again, with the Control Map you could do this on your own if you convert projects with any regularity.

In my large project VBMA had issues with converting deeply nested controls (ie. a control inside a groupbox inside another groupbox on a tab).  If your VB6 project is doing a lot of this then you might have some issues (the controls are all there, just layered oddly).  Other than that it does a decent job of converting a project.

Things that I’d like to see added in future versions:  The ability to change colors to a default color and the ability to set a default height for controls.

VBMA is not perfect but I like it.  It doesn’t try to do everything for me and in the long run  converting your BASIC code manually is the easy part since the really time consuming part of migrating to REALbasic is converting the forms to RB windows.  VBMA lets you do this quickly and easily.

If VBMA is a bit too ‘lite’ for you, you can always try VB Convert! from AYB Computers.  It has many more options for form and code conversion.  It has some quirks in code conversion but it might be a good alternative for you.  VB Convert! Pro costs $65.

Today someone gave me a reference to Jabaco at http://www.jabaco.org.  Take a look at it and come back.

Interesting, huh?  That’s what I thought.

I’ve not played with it so all I’m doing is basing my info off of their web site.  If you have first hand knowledge please add your comments.

The IDE is unabashedly Visual Basic 6.  In all of it’s ugly glory it is definitely VB6-like.  For people thinking about moving away from VB6 to something else it looks like a potential solution.  Of course, if you have a low opinion of Java applications it’s probably not a good choice, but for many people Java apps are good enough if not a great solution.

One of the things that we don’t know about is how easy it is to customize the UI for each platform.  Based on the chatter in the forums they’re still getting the compiler working properly but I suspect that it would be easier than REALbasic’s approach because it’s compiling to one platform – Java – while RB is compiling to three.  The current version is 1.4 Beta so it definitely has some needs before it’s ready for primetime.

Compiling to a Java application and being able to use the vast array of libraries, reporting tools and other fun stuff might make this development environment that much more compelling.  Honestly, one of the drawbacks on the Mac platform (and RB by extension) is that there just isn’t a lot of choices when it comes to reporting and libraries.  Java, since it’s been worked on for over a decade, has the tools and libraries available.

Another interesting thing about Jabaco is that it opens and converts VB6 projects from within the IDE.  Having looked (a lot) at conversion utilities in the past couple of years I can’t imagine it being any better than bad for anything other than simple code.  All Windows declares would have to be rewritten and in their demo on their website it looks like Jabaco doesn’t make any attempt to convert system calls.  In that respect it’s no better or worse than any of the utilities to convert VB6 to RB.

So what do you think?  Do you think Jabaco has some potential?  Is it a worthy competitor to REALbasic?

Many of my Windows-only clients are coming from Visual Basic 6 where they’ve invested tens of thousands of dollars in specialized libraries and controls.  And because REALbasic doesn’t fully support COM I have to tell them that the chances of their library or control working in REALbasic is not good.  Forget about ActiveX controls – my luck in getting them to work in RB is almost non-existent.

I know I’ve talked about this specific problem to anyone from Real Software that would listen at the past three Real Worlds.  I can’t be the only one that has this issue.  It is my opinion that this might be the single biggest deterrent to adopting REALbasic if you’re dealing solely with the Windows platform.  It makes it seem that RB is half-baked and awaiting completion.

I can only guess at the reasons for not implementing it so far.  One, they feel it does them no good in gaining new customers.  Two, the effort to implement isn’t easy and resources are scarce.  Three, no one’s asking for it.

I can’t see how having COM support hurts getting new customers.  I maintain not having it loses customers but, whatever, I have no data to back it up.

I feel partially to blame about number three.  In the December 2008 ARBP survey we listed 25 items that RS could work on and when I compiled the list, COM support didn’t make it to the list.  My bad.  I suggest that if you want COM support like I do, send them feedback.  It seems that the more people scream about it the more attention it gets.

Resources ARE scarce at RS after laying off a developer in late 2008.  I know they are working at getting Cocoa support in the first half of 2009 and so far it seems that the release is on-track.  Is COM support waiting for Cocoa support to be finished?

Am I missing another reason?  Do you think COM support is necessary and needed?  Does it hurt RB by not fully supporting COM?  Does anyone care?

We have an application available on the BKeeney website that lets users analyze their VB6 projects file and send us the analysis via email.  We then do some magic calculations and email them back with an estimate of between X and Y dollars to convert the application.

This is all without seeing a line of code so it really is a lot of guesswork.  However, you can tell a lot about a VB6 application by the controls that it uses, how many forms, number of lines of source code and so on.  If the application uses Crystal Reports it adds another layer of complexity to convert it to REALbasic.  Likewise with any special ActiveX controls and DLL’s.

I originally came up with this topic idea right after the first of the year because it had been months since anyone had sent in a VB6 project for analysis.  Then in mid-January we had three in one week (don’t you love the law of averages?).  One we never heard back from and the other two said the price was too high for non-saleable projects.

So it leads me to this question:  Is the Window of Opportunity Closing (or Closed) to Convert VB6 applications to REALbasic?

It was about a year ago where I lobbied Real Software to kill the Visual Basic Project Converter (VBPC) and they did.  It was an awful attempt at trying to do everything and it did none of it especially well.  At the time I thought it hurt the VB6 to RB cause and I still believe that.

At about the same time, AYB Computers introduced VB Convert! and it’s been updated several times since then.  I’ve used it a couple of times and it’s okay at some things and code conversion is, well, code conversion.

Visual Basic and REALbasic may have ‘basic’ in the name but that’s about how close they are as development languages.  Any conversion utility will fail given complex enough code.  That’s a fact.  To REALLY convert between VB6 and RB you’d need to create a syntax tree and mini-complier for VB6 and who wants to do all that work (and sell it cheaply enough to make it worthwhile)?

So in the long run it’s just easier to do it by hand.  But then you run into pricing issues because it costs more for a code monkey to convert code than it is for a utility to do it.  Then you get into Other People’s Code (OPC) problems because there are a lot of really poorly written VB6 apps out there (as well as in every other language but BASIC apps by their very nature are written by people that don’t have a lot programming experience) which takes even more time to figure out how to convert.

Let’s face it, even Microsoft’s VB6 to .NET compiler has issues.  It’s not perfect either and to have someone convert it for you it costs about $1 per line of code (the last time I checked).  Our prices are considerably less than that but in the past six months there’s been a considerable drop off of traffic.

At this point, .NET has been available for 5 years (more?).  You would think that if they wanted to convert to .NET they would already have done so.  If they haven’t, why not?  I image a few cases:  1) They don’t have the technical know-how to do so or; 2) It’s too expensive to have someone do it for them; 3) They have no need of newer technologies and VB6 apps work fine; and 4) all of the above.

Do you think the window has closed on people converting from VB6 to some other language?  Did I miss any reasons why they’ve waited?  Is REALbasic a viable alternative to VB6?

That’s a great question!  I’ve always said that REALbasic is a good choice (for the most part) for people wanting to migrate from Visual Basic 6.  The article points out that for most applications, they should probably stay in VB6 unless they’re highly visible in the organization or if they need something specific to .NET.

And therein lies the rub of migrating from one development environment to another.  There’s pain involved.  In fact, a lot of pain.  Regardless of how good an automated conversion process is, it will always miss something and that something might be very subtle.  So subtle in fact that it might take months to find it, or even worse, after it’s been released (because after all, who has time to properly test anything these days?).

Hiring a developer or even a service can be very expensive.  One VB6 to .NET conversion service charges $1 per line of code.  A VB6 project I worked on for years had 950,000 lines of code.  There was no way that they could afford to get it converted to .NET because they didn’t have $950,000 sitting around.  Doing it themselves would have cost them a minimum of a year with a team of experienced .NET developers.  They thought they wanted to go to .NET but yet they could never give any good reasons why they wanted to go .NET other than it is the new ‘thing’ to code in.

Let’s face it, VB6 is still a capable language and while language purists might dismiss it, I’ve done and seen a lot of awesome code in it.  Sure, to make a modern looking application you have to go through some hoops but it’s not that hard.

The situation with converting to REALbasic is similar to that of VB6.  Unless you have a need for RB’s strengths, such as wanting to support Macintosh and Linux users, you’re probably better off staying in VB6.  I’ve had quite a few people amazed at how much it costs to convert from VB6 to RB.  For some reason they think it should be ‘easy’ because they both have the word BASIC in their name.  Nothing could be farther from the truth:  RB and VB are completely different languages and frameworks and only a skilled developer can convert between the two.

Converting from VB6 to .NET is always an option.  If you do that you’re stuck with Microsoft for another decade and you’re still not supporting Mac and Linux users.  REALbasic should be considered an option if you want to migrate away from VB6.

What are your thoughts?