BKeeney Briefs

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.

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?

Visual Basic 6 is arguably the most common development language on the planet.  It’s low barrier to entry and easy-of-use and its extensibility make it ideal for many non-programmers to make a ‘working’ application that does exactly what they want.

VB6 is no longer supported by Microsoft.  This is forcing many developers into the .NET environment which is not as easy to use and many would argue that the language is no longer ‘basic’.  So what are companies that have dozens of VB6 applications to do?

Let’s also add to the mix that Apple has doubled their market share with very slick computers.  Linux has very vocal and loyal supporters.  All this means that companies that were once Microsoft-only now need to convert their VB6 code to something else.  Whether that something else is .NET, Java or REALbasic is somewhat irrelevant because every choice is going to involve pain (money, training, time, etc).

Converting from VB6 to REALbasic should be a no-brainer, right?  Wrong.  While they both have basic in the name, they really are completely separate languages, each with their own set of peculiarities.  Yes, there are many similarities between the languages but that doesn’t mean it’s easy.

REAL Software has had the Visual Basic Project Converter (VBPC) for a while and was last updated in early 2005.  It’s free for download.  I would recommend that you don’t even bother – you’re better off converting by hand.  Hey, you get what you pay for, right?

I find it inexcusable that REAL Software has taken over 2 years to release an update to software that might very well be the first thing that VB6 developers see when evaluating REALbasic.  Here’s a very brief list of what it doesn’t do:
•    Windows and controls are not converted to the proper dimensions
•    Enums not converted
•    Structs not converted
•    The converter mangles code with no errors

There is one commercial product to VBPC and that’s VB Convert! by AYB Computers.  Its price tag is a very reasonable $50.  Even if it only saves a little time it’s worth the money.

VB Convert! does a good job of converting VB6 forms to RB windows as long as you are using the standard Visual Basic controls.  If you’re using 3rd party controls you’ll at least get a canvas subclass in the proper position.

The code conversion is better than VBPC but keep in mind that there are just some things that won’t convert very well.  One such item is file I/O.  VB6 is a product of the early 90′s and is not OO in most areas.  REALbasic file I/O is pure OO.  Only a programmer can objectively convert from VB6 to RB at that point.

VB Convert! will convert enums and structs properly.  They also have a variety of options that the VBPC doesn’t have like forcing pushbuttons and editfields to a certain minimum size and converting a ADODB recordset AddNew method to using the REALbasic DatabaseRecord class.

You might think that I’m being easy on VB Convert!.  We, as a company, thought long and hard about creating a VB6 converter.  At first blush everything seems easy but then you get into the exceptions, and VB6 oddities, and all the 3rd party ActiveX controls and you start to realize that it’s a HUGE problem.  For a version 1.0 product AYB has blown away VBPC in terms of usefulness.

In the long run, no ‘converter’ will do all the work for you.  If you think you’re going to select a VB project file, run the conversion process and then hit the RUN button in REALbasic you are sadly mistaken.  The conversion process is just that – a process that takes a programmer familiar with both VB6 and RB to do the conversion.  In many cases it will be a line-by-line conversion even with tools to help.

Think about it this way:  Some companies that convert VB6 to .NET are charging $1 per line of code.  What are you paying for REAL’s VBPC?  Exactly.  At least with VB Convert! you’re funding a developer that actually cares and is willing to work with you.

In my opinion, RS should remove their converter application until (or if) they get it into a decent working state.  Until then, give VB Convert! a shot knowing that you will spend some serious time converting a lot of things by hand.  VB Convert! is a tool that can help save some time while VBPC is useless in its current state.