Porting VB Applications to Linux and Mac OS X
Total Page:16
File Type:pdf, Size:1020Kb
Porting VB Applications to Linux and Mac OS X A how-to guide for Visual Basic developers by Hank Marquis Hank Marquis has been using Visual Basic since version 1.0. He is author of A Visual Basic Programmer's Toolkit (APress), The Visual Basic 6.0 Bible (IDG) and over 35 articles published in CTO/BackOffice, Visual Basic Programmer's Journal (VBPJ), Visual Studio Magazine (VSM) and Microsoft MSDN. He is currently CTO of SlayFire Software Co., creating optimization and performance tools for REALbasic. Reach him at [email protected] or www.slayfiresoftware.com. Table of Contents Porting Options Beginning Assumptions Porting Considerations Language Keywords Code Syntax Data Types Language Structure User Interface Project Structure Platform APIs Other Considerations Visual Basic Project Converter Additional Resources Table 1. Porting Considerations Table 2. Visual Basic and REALbasic Datatypes Table 3. Getting Ready: The Step by Step Process Preparing Your Code to Use VB Project Converter © 2004 REAL Software, Inc. and Hank Marquis. All rights reserved. Page 1 of 17 Porting Visual Basic applications to Linux and Mac OS X A how-to guide for Visual Basic developers In this white paper, I'll show how you can preserve your investment in Visual Basic by porting your code to Linux and/or Macintosh using REAL Software's REALbasic. I'll provide some examples, share some experience and give you a roadmap for how to port—and how not to port—your Visual Basic apps cross- platform. My intent is to save you some time and pain. For porting our VB projects, we will use REALbasic 5.5.3 for Windows, a modern software development environment that is quite similar to Microsoft Visual Basic® in terms of the GUI and syntax. I also don't intend to provide a full comparison of Visual Basic and REALbasic but rather to show you where they are different in ways that will impact porting your project. Porting Options With the release of Visual Basic.Net, many Visual Basic developers felt abandoned. For the first time, a Visual Basic implementation could not open and run a previous version's source code. Visual Basic.Net requires Visual Basic developers to modify their code because .Net cannot run Visual Basic code. So, like it or not, if you are a Visual Basic developer who wants to take your Visual Basic code forward into new projects, you will be porting. Porting means learning and using new keywords, and keywords that don't work the same way they used to; in general, it's a fair amount of work. So, when I was faced with this dilemma, I asked myself what benefit I would get from porting to .Net. After learning a new language (.Net), significantly changing my source code, and struggling to create programs with a massive "framework" underneath them, I would have a program that ran under Windows. I then started to look into alternatives. If I had to go through the process of learning a new language and IDE, what else could I get? I then found REAL Software and REALbasic. REALbasic 5.5.3 for Windows is a modern, fully object-oriented software development environment (IDE), quite similar to Visual Basic. It could use much of my Visual Basic code unchanged, and it could read most of my Visual Basic forms. I could port my Visual Basic code to REALbasic, and at the end, my application would work under Windows—just like .Net. More importantly however, my ported application would also run under all 32-bit Windows (98/NT/ME/2000/XP) without the .Net framework; Linux (any Intel-based Linux running GTK2.0+ like © 2004 REAL Software, Inc. and Hank Marquis. All rights reserved. Page 2 of 17 SuSE or RedHat) and Mac (Mac OS X and Mac Classic). As an added benefit, there are no runtimes or "frameworks" required for an REALbasic application. In addition, my ported application would include the native interface widgets required to look great. In Windows XP for example, I was surprised that my REALbasic app takes on XP themes automatically! To demonstrate this, see following screenshots of applications compiled with REALbasic: Windows XP, Linux and Mac OS X Screenshots The decision was actually an easy one, as I had to port either way, either to .Net or REALbasic. At the end of the port I would have either a Windows app with huge runtime requirements, or an app that ran under Windows, Linux and Mac. The choice was clear. If I had to learn a new language and port, then I wanted a much bigger bang for the buck than was available with .Net. Beginning Assumptions I'll start with a few assumptions to make sure we're talking from the same frame of reference. I assume you want to move applications from Visual Basic to REALbasic for the reasons I gave above, that you want to create cross-platform applications from your Visual Basic projects, and that you are using Visual Basic 5 or Visual Basic 6 and REALbasic 5.5. I also assume you know something about Visual Basic and/or REALbasic. Porting Considerations To begin, the topics listed in Table 1 need to be taken into consideration as you think about porting your application. I will take these important considerations one by one. Remember, before you port to REALbasic, you should consider the work and re-work that might be required. After all, Linux and Mac operating systems are very different from Windows, and, just like .Net, not all your code or controls will port. Unlike .Net, at the end of your journey with REALbasic you will have a supported, truly cross-platform application! Let's go! © 2004 REAL Software, Inc. and Hank Marquis. All rights reserved. Page 3 of 17 Table 1. Porting Considerations Language Keywords Code Syntax Data Types Language Structure User Interface Project Structure Platform APIs Other considerations Language Keywords You will be pleasantly surprised by how many REALbasic and Visual Basic keywords work identically, including Left, Right, Asc, Str to name just a few. Almost all of your Visual Basic knowledge translates directly into REALbasic. Of course, there are some keywords that do not work the same. For example, in REALbasic, Mid cannot assign a string as the Mid statement in Visual Basic does: Mid(x,2,1) = "!" 'fails in REALbasic 'but is OK in Visual Basic Mid is a function (returns a substring) and a statement (modifies a string) in Visual Basic, but not in REALbasic. In REALBasic, Mid operates only as the function, so you need a replacement statement for Mid in REALbasic. [Note: REALbasic provides a module with such replacements.] Luckily, in REALbasic, unlike Visual Basic, you can have methods and functions with the same names, which makes sense since they are not equivalent in functionality. For example: Sub Mid(ByRef As String, StartPos As Integer, StopPos As Integer Assigns SubString As string) Text = left(text,StartPos-1) + SubString + Right(text,StopPos+1) End Sub creates a "replacement" for Mid, giving REALbasic a Mid statement in addition to the existing Mid function. Once written, you can then use Mid just like you do in Visual Basic. It's easy. Visual Basic makes it easy to write sloppy code, as we all know. Dynamic variable declarations, variants, Goto's, all add flexibility, but, if not used with care, can result in ugly and hard-to-maintain code. REALbasic is object-oriented, and is therefore stricter. For example, in REALbasic, you cannot use a variable without an explicit Dim. © 2004 REAL Software, Inc. and Hank Marquis. All rights reserved. Page 4 of 17 Visual Basic, on the other hand, allows explicit/dynamic variable creation and type casting with explicit variable casts such as $, %, #, @ etc., while REALbasic does not, as shown below: Left$ 'not portable Left 'portable So, before you port to REALbasic, one of the most important things you can do is to clean up your Visual Basic code! Remove variable casts ($, #, %, etc.) from your code. Use Option Explicit to help locate all un-declared dynamic variables in use, and declare them. As with any language, reserved keywords may conflict. REALbasic has a built-in String class, and the name String is reserved in REALbasic, making the Visual Basic String keyword incompatible. In this case, you'll need to change your Visual Basic code after opening it in REALbasic. Then, you'll need to write a replacement function for String, then find and replace all Visual Basic String keywords with the replacement. REALbasic and Visual Basic each have some unique keywords as well. For example, Visual Basic has Space and Int. While REALbasic does not have these, they are easily created in REALbasic, like this: Function Int (Value As Integer) As Integer Return Value \ 1 End Function On the other hand, REALbasic has Min, Max & CountFields; where Visual Basic does not. REALbasic and Visual Basic also have different keywords for the same function. For example, REALbasic has UpperCase, while Visual Basic has Ucase. These work the same way, they just have different names. It is easy to write a wrapper around the REALbasic implementation so you don't have to change your code. However, performance will be faster if you replace Ucase (or Lcase) with UpperCase and LowerCase. As you can see, similar keywords means stepping through a few hoops for experienced Visual Basic developers. To make it even easier, be sure to spend time with the REALbasic user guide and language reference beforehand. Another tip is to play with REALbasic to get the feel for it. In summary, to port your keywords like Mid that work differently, you will need to create replacement functions.