Note that REALbasic also has an "integer" datatype that defaults to the native size for a given platform. Currently, Integer also resolves to an unsigned 32-bit Integer at compiled time, but in the future it may resolve to an unsigned 64-bit Integer when REALbasic expands its support for 64-bit operating systems. Use of the Integer type today will enable current applications to add full 64-bit support with just a recompile in a future release of REALbasic.

As I've mentioned, REALbasic is a modern, fully object-oriented and structured language. As such, REALbasic data typing is more stringent than Visual Basic. This is a real benefit, especially for shops that have more than one developer writing code. REALbasic syntax is easier to read, understand and maintain because of this structure. Of course, this means certain "sloppy" Visual Basic code will not import and run. For example, the following Visual Basic code "runs fine":

Dim bVar As Boolean
If bVar = 0 Then Beep

In REALbasic, the above code will fail since 0 is a numeric data type and not a Boolean!

Unlike Visual Basic, in REALbasic False ≠ 0 and True ≠ -1.

Again, Visual Basic makes it too easy to write "bad code," so cleaning up your Visual Basic code before importing into REALbasic is a must.

Remember that the Visual Basic Long data type is a REALbasic Int32. Currency is not yet supported by REALbasic, but there is a reasonable work-around using a 64-bit integer divided by 1,000.

Language Structure

The language structure of REALbasic and Visual Basic are similar, but not quite the same. This is due again to the richer REALbasic deployment environment and the elegant means of writing one line of code that works in multiple operating systems—with wildly different hardware and software architectures.

Some examples include File I/O, Method structure, Constructs, Error handling, and Object instantiation. Most of these issues arise from the Windows-centric nature of Visual Basic versus the portable object-orientation and object design approach taken by REALbasic. In general this object orientation is good in that you don't learn "bad habits." If Visual Basic didn't have a history to bring forward, it would have been easier to drop a lot of things Visual Basic does that are not quite correct. However, history aside, some things are quite different in REALbasic until you get familiar with it.

Case in point: File I/O

In order to have cross platform file I/O, you cannot use Windows-centric file structures and conventions. For example, Windows filename and paths use characters like \ that are not used, for example, on the Mac. If your goal is to write a more compatible Windows program than you can with Visual Basic, then you can use OS-specific structures in REALbasic. But if your goal is portability, then you need to use object-oriented methods, also possible in REALbasic.

Visual Basic File/IO is therefore different than REALbasic. Visual Basic uses distinct keywords for file I/O, often using UDTs. REALbasic uses object-oriented folder-and-object stream schema. (In fairness, I need to mention that a REALbasic application might find itself compiled to Windows, Linux, or Mac—and the file systems of all these operating systems are different. They don't all use the same disk, directory, file and path implementation. Thus, REALbasic has one schema that can work for all operating systems.)

For example, in Visual Basic, to open a file and read in its contents:

Dim file As Integer
Dim x As String
x = String(FileLen("vb2linuxrocks"), " ")
file = FreeFile()
Open "vb2linuxrocks" For Binary Access Read As file
   Get file, , x
Close file

Whereas in REALbasic:

Dim file As BinaryStream
Dim x As String
file = DesktopFolder.Child("REALbasic Rocks").OpenAsBinaryFile(false)
x = file.Read(file.Length)
file.Close

Similar, but different. Once you get the hang of the REALbasic folder/object-oriented approach, you will see how much easier it is to use than the rigid Visual Basic path structured approach.

With regard to the structure of Methods (Subs, Functions, Events), Visual Basic and REALbasic are mostly compatible, with a few exceptions. REALbasic uses the Return keyword to define the return value of a function; Visual Basic uses the name of the Function. REALbasic uses the Exit keyword to exit any sub, function or event code; Visual Basic uses Exit Sub|Function|Property.

In REALbasic, a pair of Setter/Getter methods are slightly different than in Visual Basic. Visual Basic calls these properties. Both Visual Basic and REALbasic require two methods and a property. REALbasic uses a Function/Sub pair for Properties; Visual Basic has the Property declaration. The result is exactly the same, but the code looks different. The following example shows the two implementations. In Visual Basic:

Property Let Caption (Text As String)
   lsText = Text
End Property

Property Get Caption As String
   Caption = lsText
End Property

In REALbasic:

Sub Caption (Assigns Text As String)
   lsText = Text
End Sub

Function Caption As String
   Return lsText
End Function

Both REALbasic and Visual Basic support custom Events. However, Events and raising events are handled differently. Note that both Visual Basic and REALbasic support ByVal and ByRef. However, the default for Visual Basic 5 & 6 is ByRef; and the default for REALbasic ByVal. (Also note that VB.Net uses ByVal as its default.)

Public Event UpdateTime(ByVal dblJump As Double)

Public Sub TimerTask(Duration As Double)
   RaiseEvent UpdateTime(Timer - dblStart)
End Sub

Where in REALbasic:

Event UpdateTime(dblJump As Double)

Public Sub TimerTask(ByRef Duration As Double)
   UpdateTime(Timer - dblStart)
End Sub

As often is the case, REALbasic does what Visual Basic did, and then some. For example, REALbasic constants offer platform awareness and localization awareness that Visual Basic constants do not. This itself is a major benefit over Visual Basic.

Error handling is more robust in REALbasic than Visual Basic. REALbasic offers two error-handling methods: Exception blocks, which apply to an entire method, and Try-Catch blocks, which apply to specific sections of code. Visual Basic's On Error mechanism is not supported. There are no line numbers in REALbasic, but there is error information in an error object. In Visual Basic, you use the familiar:

On Error Goto|Resume|Resume Next

REALbasic offers the more modern

Exception x As [EXCEPTIONTYPE]
Try ... Catch ... Finally

Both Visual Basic and REALbasic use Raise to raise an error, but the syntax is very different. In Visual Basic to raise an error you simply use:

Err.Raise

In REALbasic, you have to create an instance of RuntimeException or one of its subclasses, then raise it using the Raise statement:

Dim myErr As New RunTimeException
myErr.ErrorNumber = 1000
myErr.Message = "An error occurred"
Raise myErr

Another major benefit of REALbasic over Visual Basic error handling is the REALbasic UnhandledException event. If an unhandled error occurs anywhere in your application, it can be caught by this event, where you can handle it and exit gracefully. Application hard crashes are a thing of the past with a single line of REALbasic code!

For Object Instantiation, Both Visual Basic and REALbasic use Dim, New and =. Visual Basic uses Set, Let and Nothing; while REALbasic uses Nil. The major differences here are Set (Visual Basic only) vs. New; Nothing (Visual Basic only) vs. Nil, and no Let in REALbasic.

Equivalent implementations are not that difficult. In Visual Basic, as shown in the next example that raises a custom event, note how Visual Basic requires the "Set mText" line; while REALbasic simply uses "=" :

Private WithEvents mText As TimerState

Private Sub Form_Load()
   Set mText = New TimerState
End Sub

And in REALbasic:

mText As TimerState

Sub Open()
   mText = New TimerState
End Sub

In conclusion, for Language Structure, there is no way around it, you'll need to do some manual tweaking. This may be the most difficult challenge for porting. However, there are enough similarities between Visual Basic and REALbasic to make porting possible, and the rewards are great. In addition, the areas of incompatibility are easy to identify, and again, your best bet is to play with REALbasic to get the hang of it before porting your application.

User Interface

The graphical elements of REALbasic and Visual Basic are mostly the same, with a few exceptions. First of all, as you might expect given its Mac heritage, REALbasic has much richer graphical capabilities. The diagram below shows you the wealth of controls you have in REALbasic (REALbasic is on the left!).

There are identical and compatible interface controls, for example, the Visual Basic Picturebox matches up nicely with either REALbasic's PictureWell control or Canvas control.

Both support ActiveX controls or OLE (Windows only!), but REALbasic also supports cross-platform "Plug-ins." Since Mac and Linux do not support ActiveX, ActiveX controls will not port to other operating systems, even though they will port to REALbasic Windows builds.

You'll also find it really interesting that REALbasic actually handles Windows user interfaces better than Visual Basic!

Because REALbasic supports native UI widgets, REALbasic applications support the common characteristics of Windows 98/NT/ME/2000 and XP. So, for example, your Visual Basic applications, once ported and recompiled in REALbasic, automatically assume XP themes.

In conclusion, the application user interface is better under REALbasic in most cases, and this is a major benefit of porting. However, not all common Visual Basic controls are supported, and this can be a show-stopper for some projects. Both REALbasic and Visual Basic support ActiveX, but ActiveX is not portable to other platforms, so your best bet is not to use them. In addition, REALbasic does not have TreeView, ListView, etc., so you may need to "roll your own" using intrinsic REALbasic controls and stick to stock Visual Basic-intrinsic control types.

The ListBox control in REALbasic has all the basic ingredients required to create a custom control class that could mimic TreeView, ListView, etc. However, you have to code the functionality yourself. There is no drop-in-replacement that is syntax-compatible with Visual Basic for these controls at this time. (Although, this is an opportunity for a component vendor!)

Project Structure

REALbasic has a unique App module, it is similar in some ways to the Visual Basic startup object, but also different. So it would benefit you to become very familiar with it before porting, otherwise you might miss out on some neat cross-platform capabilities. For example, menus. Menus under Mac and Linux are not exactly the same as under Windows. Under the Mac, there is only one menu bar at any point it time, and there are certain menu locations that are specific and should hold specific items. For example, the Apple menu, Quit menu and others.

While Visual Basic and REALbasic both support MDI, for cross-platform, you need to move onto SDI interfaces with dialogs. Even Microsoft has started moving away from MDI interfaces, you should consider it as well.

Platform API's

API usage is different in REALbasic than in Visual Basic. REALbasic is richer due to its support for Windows, Linux, Mac OS X and Mac Classic. Just as you use a UDT in Visual Basic, you can use a Structure in REALbasic to define a custom data structure for use with the Declare statement. You will need to do some homework to ensure there is a replacement for your target OS. I suggest carefully thinking about why you are using an API call. In some cases an API call is no longer necessary because REALbasic includes support for the desired feature within the REALbasic class framework itself.

However, you should feel comfortable that you can mix and match platform-specific code using REALbasic as shown below.

#If TargetMacOS Then
   //Mac specific code here.
#ElseIf TargetWin32 Then
   //Windows code goes here.
#ElseIf TargetLinux Then
   //Linux code goes right here.
#EndIf

Other Considerations

You'll need to consider platform-specific usability and platform-specific guidelines. The following links are provided for your convenience in learning about the user interface guidelines for the different platforms that REALbasic supports. You can also search on the "Search for..." description to find more resources on the internet.

There are many tools that are helpful for making your programs more robust. You'll need to take external tools and controls under consideration as you port your code, including ActiveX, Plug-ins, Debugging Tools, Performance Analysis Tools and Databases.

REALbasic can create Windows, Linux and Mac desktop (graphical UI), console ("DOS-box" UI) or service (or daemon) applications (no UI) from your Visual Basic code. As you can see from this analysis, an experienced Visual Basic developer can port a project cross-platform to Mac and Linux using REALbasic.

The port will require some manual tweaking, so you, the developer, must determine if it's easier to port or re-write your software.

In most cases, the Visual Basic User Interface (Forms) and almost all code can be imported, and of course, once you've written a program, porting and re-writing is easier because you've already thought through the logic of the program. The biggest problem will be in the use of Windows-specific custom controls (like TreeView, etc.).

VB Project Converter

If you are a Visual Basic developer or are responsible for Visual Basic applications, you may feel left behind. .Net requires massive frameworks and significant investment in new controls and tools, in addition to making you learn a new language. You may even be surprised to find you have to treat .Net as a new language—it's so different. Then, when you are done porting to .Net, you will have, drum roll please, a Windows application with huge system requirements. This is good for some, but not so good for you nor for those who may use your software.

Choosing instead to port to REALbasic gives you full Windows support, no huge runtime, minimal system requirements, and portability to Windows, Mac and Linux.

At a minimum, before starting with .Net, you should evaluate REALbasic. You might come away as I did, with a cross-platform version of your application and a clear path to the future.

Table 3. Getting Ready—the Step by Step Process Preparing Your Code to Use VB Project Converter

1. Replace any & used for concatenation (bad programming practice anyway!); use + instead.
Left("Honk", 1) & "ank" becomes
Left("Honk", 1) + "ank"
2. Dim all variables on a single line to ensure YOU understand what they are supposed to do.
3. Use As Integer, not %, etc., in your code.
4. Be sure to remove DefXXX in each Form and Module to detect your data types.
5. Use Int64/1000 as Currency replacement.
6. Visual Basic Error Handling will get Rem'd out by VB Project Converter, but you can locate it and fix it.
7. Remove line numbers as they are not supported in REALbasic.
8. Goto supported, but only with string label (no numbers).
9. Move as much code as possible from forms into modules. (In general, VB Project Converter does a better job with modules, and you can actually open a module directly using REALbasic without using VB Project Converter at all, if you wish.)
10. GoSub not supported, so replace with functions/methods as required.
11. Database will require some re-work, but SQL logic is largely compatible.

Additional Resources

All of the resources mentioned in this document are available for download.

Please note: The Visual Basic Project Converter is temporarily unavailable for download.

• Frequently Asked Questions
• Priority Support
• Find a Consultant
• Training
• Online Resources
• Feedback

Contact Us

• Contact Sales
• Contact Technical Support
• Contact Customer Service
• Submit a Bug or Request a Feature