Ladies and gentlemen, and welcome to session 636. At this time, we would like to ask you, if you would please, to turn off all cell phones, and to remind you once again, if you would please, no recording or taking pictures during this session. And with that said, please welcome now, Tyler Stone.

Thank you. Good morning. It's Friday, the last day of the conference. I hope it's been going well for all of you. We've had a very good conference, I think, this year. As Apple has started returning to the enterprise, we find ourselves encountering more and more customers, developers out there, with Visual Basic applications.

And they've been asking us for a migration path. How can they port their Visual Basic projects over to Mac OS X? So this session has been designed with that in mind. I'd like to introduce Hank Marquis from Slayfire Software. He's going to talk to you a little bit about how to port Visual Basic projects to Mac OS X.

Good morning, everybody. I know everyone was up late last night. Was everyone up late last night? Yeah, this is a resounding audience. Do your arms work? Do they move? Okay, so you're still functional. My name's Hank Marquis, as Tyler said, and I'm gonna talk about moving applications to Mac OS X. How many people in here have ever seen Visual Basic? How many people here have seen and/or used REALBASIC? Good, so you're probably in the right place.

First, I want to talk a little bit about what we're going to do. The idea is that you're a developer, and as Tyler said, you have an application written in Visual Basic, and for one reason or the other, you want to move that over to OS X, or perhaps even Linux. There's a number of different operating systems. Obviously, OS X is the one that we're here to talk about today.

What I'm going to talk about is a process you can follow to move your applications over and actually have it work at the end. You're sitting here and you say, I have Visual... First of all, what version... How many people are using Visual Basic 5 or 6? Oh, so not many.

How many people are using .NET? Do you like .NET? I get to see a lot of this going on. Well, if you're not familiar with what Microsoft did there with Visual Basic 5 and 6, and all the way back, I've been involved in Visual Basic since it was VB DOS, which was actually a professional development system in Quick Basic and things like that.

So back in '91, I got involved with Visual Basic, and every single version of Visual Basic up until .NET could open the previous Visual Basic source code and just compile it, execute it, and run no problem. And .NET was the first time where you couldn't do that anymore.

So if you're sitting here with a Visual Basic application and you're thinking to yourself, you need to move it forward, and you think about .NET, you have pain. You're going to have to go through a conversion, the language is different, things don't exactly work the same, and at the end of it, it runs on Windows.

And what we're going to talk about here is the way, if you're looking at that decision, to be able to say, well, why would I do that when I can go through a much easier process with a language which is much more similar to Visual Basic, and at the end of it, I can have something that works under Windows, of course, but as well, more importantly, other areas like OS X and others. And so that's what we're going to talk about, how to make that happen. I've been developing for a really long time. My mother was a systems analyst for IBM. She was a mainframe programmer back in the '60s. 1969 is the first time I saw a mainframe.

And I went with my mom to do key punch, so I knew what basic assembly language was. In fact, I started off as an assembly language programmer, and by the time I was in like eighth grade, I knew Fortran and stuff. So I've been programming for a really long time, and I'm going to use real world examples and experiences.

So I'm not a marketing person who has got the latest words du jour. I'm actually going to talk about the real world and real things that you're really going to hook up with. So what I'm going to do is tell you how to port your application to OS X, and I'm going to tell you how to do that.

I'm going to tell you how not to port it. And if you actually follow this process, you will be successful. And then again, if you're someone who doesn't want to be successful for whatever your vested interest is, then you could just do the opposite of this, and then it'll never port. And there's actually a pretty funny book out there that tells how to do stuff like that. So at the end of the day, I want to save you time, pain, and money.

So who am I? As I said, I've been around for a while. I've written a couple of books. I've published lots and lots and lots of articles. I was involved in the Component Vendor Consortium. I don't know if you know about that, but it's a third-party organization that analyzes components and gives them sort of like an underwriters laboratory of approval. I was the chairman of the quality committee and did the initial quality screening program, if you will. I founded a number of software companies. Most recently the one I had founded was with a company called Numega Technologies. It was then acquired by CompuWare and written other projects.

And I'm currently now completely involved in the OS X world with the product Real Basic. And we have a suite of productivity tools for Real Basic that are all about debugging. So I almost know what I'm talking about when it comes to actually doing this and making it work.

So there's some assumptions. One of them is that you have Visual Basic applications. And we saw by the raise of hands that you did. And the other is that you actually want to port them over to OS X. And you said that you did. Hopefully you know. I know something about Visual Basic and Real Basic 5.5. And for those that might not be fully aware of Real Basic, Real Basic is a modern object-oriented language. It runs under OS X or a variety of Mac OS really. Windows, a variety of Windows. And you can compile for OS X Windows and Linux.

And I don't think I'm letting it out of the bag to say that the next version will run on Linux as well probably. Maybe. I don't know. The guys at Real Basic will tell me. The guy's nodding. So I guess I won't be shot at the end of this.

I can all continue to live. So then you're going to have this complete capability to move back and forth. It's very, very similar to Visual Basic. But there are some differences as well. So I was going to tell you the top ten things. Like everyone likes top ten lists. And then I decided to throw in an extra one. So the things that we're going to. So you got 11, see. 11 for the price of 10.

And 10 for the price of none. So what are the big things we're going to talk about? Well, language keywords. The things that you use. The things that you use every day to do things in the language. How you put them together into syntax. The data types. How we structure data and work with it.

The structure of the language itself. User interface obviously is going to be a big thing. And one of the biggest challenges to having a portable application is the user interface. The structure of the projects physically. How are these things composed? Platform APIs. How many people in here use Visual Basic that use Windows API calls in it? Right. Okay. So right. So right away you got a little bit of a learning curve.

You got to go figure. If you either have to say how am I going to deal with that Windows API call on another platform? So am I going to just do a one off build that only works here? But if I want to go to OS 10 then I have to find an equivalent one. Or in some cases you'd be surprised how much you can do staying within the constraints.

We were able to build all of our Slay Fire products without using a single API call. And they run on all three platforms. So if you. Some rethinking needs to be done. But a lot of times you can do it. And real big. So Visual Basic is pretty powerful. Usability.

Things you want to do to make your application actually usable. And Mac users have an expectation that Windows users don't. So if you're moving a Windows Visual Basic application to OS 10 there's some things that you're going to have to deal with. Platform guidelines, tools, structure. Lots of cool things. Let's just jump right into it.

There are a whole lot of words that work exactly the same. The learning curve from Visual Basic to REALbasic is... I don't know, if you're a VB developer, and you're good, 20 minutes. If you're new, two, well, no, a couple hours. In all cases, it's going to look really familiar right out of the box. Things like left, right, ASCII, STIR, these all work exactly the way you think they would and they should. By the way, this presentation actually has code in it. Positive feedback. Thank you, thank you.

There are, however, just a few differences here and there that you will figure out one way or the other. One of the ways is by paying attention to this and using some of the tools REALBASIC offers, and the other way is to beat your head on it for a little while until you figure it out on your own. That's what I did, because I'm thick-headed.

But, for example, the keyword MID works just like you'd expect it to work, except in Visual Basic, MID can be used to drop an insert into a string at a point, and in the REALBASIC implementation currently today, it does not. Now, to REALBASIC's credit, as they're moving forward with this Visual Basic migration story, in fact, I've been able to have input to the product, and they're really great about soliciting input, so things like that get resolved. So, these little idiosyncrasies are slowly being removed from the language.

One of the big things that made VB great and evil at the same time was the whole dynamic nature of it. Hey, I can make a variable right now. If I don't have option explicit on, I can just make a variable whenever I want. Dynamic casting, dynamic creation, and that's actually not a good thing. I'm sure someone in here would say, no, it's a great thing because I can write good code and so on and so forth, and I can handle that.

But at the end of the day, it's not really good to have variables that aren't declared. You're not going to last forever. Someone somewhere someday is going to look at your code and go, well, how? What am I doing with this? So, REALbasic is much more modern in that regard, with regard to object orientation and making you be explicit than Visual Basic is. So, we're going to see how you can use that.

Real Basic is a very rich language graphically, as you can imagine from its heritage as an OS X or a Mac OS application. Visual Basic, you know, graphic-wise, just, you know, it isn't there. It's a funny thing. A Visual Basic application, by default, can't even pick up the Windows XP themes on its own. So, like, your VB apps look like Windows 3.1 apps when you run them on XP. You know, so it's just, graphically, it's not very cool.

But, Real Basic is really graphically rich, and there's lots of games and things like that that are probably right around here right now that are all written. They have 2D and 3D rendering graphics engines built into the language, so there's a lot of things you can do there. What that means is that some of the words that are, for example, keywords in Visual Basic are not available anymore.

So, like, the string keyword, well, there's a string class in Real Basic, and so on. So, if you're using the string keyword in Visual Basic, that's not just going to port right over. You're going to have to do a different thing to make that work. So, there's some of those things you have to deal with.

So there's words, there's keywords that are exactly the same. There's keywords that are exactly the same, only they do things slightly differently. And then there's keywords that are completely different. Visual Basic has space and int. Those two things don't exist in REALbasic. So you say, well, gee, how do I make a padded string five characters long? Well, for I equals one to five, X equals X plus CHR 32, right? Next. So that's how you do that. So you might have to go make yourself a little module, but the good news is that's already been done for you.

For example, the space keyword, there's a module of Visual Basic things that are not in REALBASIC you could just plug in and use. On the other hand, Visual Basic has some cool things that we always have to write, and I mean, if you've written in Visual Basic for any amount of time, you've got dozens of classes of reusable stuff that you just drag and you keep using over and over again. A lot of that can go away, because REALBASIC has a lot of keywords that Visual Basic doesn't.

And then there's these sort of maddening little differences. Who knows who's right? It doesn't matter who's right. But REALBASIC calls it UPPERCASE, and Visual Basic calls it UCASE. So you may say, "That's not so bad. "I can just go through my VB code, "do a global edit, replace UCASE with UPPERCASE, "and I'm happy." Or I could import it into REALBASIC and do a global UCASE to UPPERCASE. So you can deal with it. But something you have to deal with.

So at the end of the day, you're sitting here looking at a development path, and you say, can I do this? I think the answer is yes. Similar keywords, it's similar, but, you know, RTM, everyone know what that acronym stands for? No? You don't know? Someone know? Read the manual. Right.

If you're going to port, I suggest you drop a dime, or a couple of dimes, and buy a book or two. And I haven't published a book in REALbasic, so I'm not pushing my own book, but there are other books, and the REALbasic documentation itself. Read it. Become one with it.

Understand what the language does so that you know, oh, I remember reading about that, and you can move on. So, a lot of times, because you're just like me, I mean, I get a piece of software, I get the box, I never even open it, I download it, I install it, and I'm just like brute force, I'm going to make this thing do what I want, because that's how I am. But in this case, you know, like my dad used to say, when all else fails, read the directions. You know, and then my dad would watch me do something, I'd be beating my head.

My dad is a hardware guy, my mother was a software gal. And so, I'd do something all along, and my dad would watch me, and then at the end, when it wouldn't work, he'd go, you know, I probably wouldn't have done it that way. So, now that I'm getting, you know, towards middle age, I, you know, I'm starting to realize, gee, maybe it's maybe I should have, you know, not when all else fails, read the directions. Maybe I ought to read the directions up front, especially if I have to do it. So, you can read as well as I can on the rest of them. Code syntax, next big area.

These are the kind of things that will drive you batty, but they're the things you need to know about. In this case, for example, this is a real subtle kind of a bug. By the way, you can just drag and drop code from Visual Basic into REALbasic. REALbasic can open modules and just load the code right up and show it in its editor, and it actually looks pretty cool.

Here's an example of something that would terrorize you, and it's only because you were sloppy on the VB side. Now remember, Visual Basic, and I was one of those guys who, a long time ago, when Visual Basic first came out, people were like, oh, you can't do that.

It's only good for prototyping UIs, and you can't write a real program. I was like, yeah, watch this. I cracked my knuckles, and I'd do something that couldn't be done in VB, like a file on a race program that did direct disk manipulation to be able to recover deleted files. People were like, we can only do that in Assembler or C. I'm like, oh, yeah, check this out.

So yeah, you can be sloppy in Visual Basic, or you cannot be sloppy, but Visual Basic is forgiving, and that was one of the things about it. So that means it's easy to be sloppy. So let's say, for example, in this example here, you've got Visual Basic code on top, and you've got a defint A through Z, and that means that for every variable declared in the rest of this code module, if I don't explicitly declare it to be a data type, the variable will default to integer, because that's my default. So anything that starts with A through Z, that's a variable that isn't explicitly cast, defaults to an integer. That's all well and dandy, because on the second line, the first line of that form load up there, I have dim x comma y as string.

Now, you might look at that, because you know VB, and go, well, sure, X is an integer and Y is a string. Now, load that code into REALbasic and go dim, by the way, REALbasic doesn't allow you to do module level global declarations like everything that starts with A through Z is a particular data type. So, it looks at X, Y as string, and it says, oh, well, they're both strings. You want X, Y, Z as string.

See how that just kind of gets you a little bit? So all of a sudden, the code that worked fine up on top, you know, message box Y, you're going to get a tight mismatch error, you know, because X is no longer an integer. X is a string now, and you can't assign a numeric value to a string.

So the moral of the story here is that you should begin to become as explicit with your Visual Basic code as you can. And by that I mean you're going to want to clean it up. And that's kind of the moral of how to port. Start by cleaning up your VB code. We all know what good programming practice is. Just nod for me.

Good, yeah, we all know what the right thing to do is, and you need to go back and do those things to your Visual Basic programs. Now, there are a few places where the syntax of the words are different. We're into the syntax now. In Visual Basic, if you want to count down, for I equals 1 to 10, 10 to 1 step minus 1, it works backwards, right? It's intuitive. Except in REALbasic, you don't do it like that.

You say for I equals 10 down to 1, there's no step minus 1 in REALbasic. So you're going to have to do a little bit of, you know, and in fact, you can actually, you know, you can actually have that code in there. The 10 to 1 step minus 1, the loop just never gets executed. It skips right over it, because I is already 1, or less than 1 when it starts. So that's an example of something that needs to be fixed.

Here's another example, logic. Now, in .NET, they did a very similar thing to what REALBASIC did. So, the folks in Visual Basic, for the longest time, OR, AND, XOR, NOT, these are both functions and operators. You know, I can say A or B. C equals A or B, and it does the bit manipulations. And, in fact, a whole lot of API code that you write for Windows uses that kind of AND, NOT, and OR functionality to do bit manipulation.

Well, it doesn't work that way in REALBASIC. REALBASIC actually has true bit manipulation. So, you're going to have to recode those things and use the bitwise class. I mean, it still has OR, AND, and NOT for logical partitions. For example, A or B, if A or B then, but you can't say, you can't use A or B, for example, to set flags to pass to another call. One example. So the differences don't make too much of a burden. What was the main thing for you to understand the differences that I talked about? You could just say it. RTM. RTM.

You guys are looking at me, no one's going to say it. All right. Oh, RTM, good, thanks, right, very good. Yeah, read the manual. And begin to clean up your basic code. Get rid of all your def-whatevers, and turn on option explicit. You've got a nightmare ahead of you. Well, not a nightmare, but you have, you know, at least a couple hours of F5 splash, okay.

F5 splash. F5 is how you start a VB program in the IDE, and it'll, it'll like start to compile and go, and then you'll have to do it again. Oh, yeah, that's right, xdim x as integer, or dim y as string. So you're going to want to go through and do that.

You want to get rid of your dynamic typecasts. This is the dollar, the pound, the exclamation point, the ampersand at the end of a variable name. REALbasic doesn't allow you to indicate what a variable is by having a control character at the end of it. So you can't have like x$ in REALbasic.

You can have x as a string, which is what it is in Visual Basic, but you can't have the dollar at the end of it, the dollar sign. You want to remove all that. Hank Marquis Look for loops. Look for those four loops I talked about. Just remember, mark them, that you're going to have to deal with them. So that's not so bad. Let's talk about data types.

There's a whole bunch of data types in REALBASIC that don't exist in Visual Basic. Visual Basic actually has a pretty limited, well, you know, you could think it's rich, but I think REALBASIC has a much richer set, and it also has endian awareness that Visual Basic doesn't have.

Because remember, if you start going across different platforms, all of a sudden the order of bits and bytes stored on disk aren't the same anymore. So you have to be able to say, well, is this thing read from left to right, or is it read from right to left? Visual Basic has the concept of a user-defined type, and I've actually been interacting with REALBASIC to talk about maybe getting that into the REALBASIC language, because there are no user-defined types per se in REALBASIC.

What you do have in REALBASIC is this concept of a memory block, which is where you can allocate a chunk of memory, and you can read any bit of it as any collection of anything that you want. I can read the first four bits, the first eight bits, the first six bits. I can read the first 16, the first 32, sort of at my leisure, and I can do whatever I want.

So I can achieve the same result as I do with a static user-defined type with a dynamic memory block. And I actually wrote a class that allowed me to, because I kind of like being able to have the logic of something that's, you know, having a type with a name, like type.name. So I actually created a class that kind of gives that same functionality, lets you create user-defined types and access their members logically. And so if you want, you can email me, or you can contact us somehow. There's email addresses around. I can email that to you.

Real Basic is object-oriented, and it really is object-oriented, like seriously object-oriented, and it's classified. So not like for security, but you know, like if it's a Boolean, then it's either true or false, and those are the types of value that it can have. So if I was in Visual Basic, I could say, and how many people have done this, I could dim something as a Boolean, and then I can say, if the Boolean equals zero, then beep. Well, that'll work, because everyone in Visual Basic knows that zero is false, and minus one is true.

That's what Visual Basic thinks. Well, unfortunately, that's not actually technically right. And in REALBASIC, false does not equal zero, and true does not equal negative one. And true doesn't equal one either. True is true. True is a state, and there's an actual keyword operator called true and one called false.

So you want to go clean up your code. You're going to say everywhere I have booleans, and I say if this equals one or this equals zero or a boolean is greater than or less than zero or something like that, I want to go back and make it use true and false. So by cleaning that up ahead of time, you're going to wind up a lot easier. So here's an example of the REALBASIC IDE with the variety of things you can do with a memory block.

which is a whole lot of different values, so you can do a lot. So conclusion, one of the big things that kind of got me going a little bit was that in Visual Basic there's a concept of an integer and a long integer, 16 bits long, 32 bits.

Well, that's true maybe for the Wintel platform, but it's not always true on other platforms. So in the case of REALbasic, an integer is the only kind of integer they have, and it's 32 bits. There's no currency type, but again, we can emulate one of those pretty easily. And you can also create your own data types. The bottom line is you've got to use memory blocks instead of UDTs. It's easy. There's a class. It's already been done.

And so that's it. So then as we move into, say, for example, language structure, We've gone through the keywords, and we've gone through the data types, and those are kind of the constructs. Now let's see how we put them together to do something. For example, file I.O., or error handling, or object instantiation, and things like that.

Here's some code that shows how you would open a file in REALBASIC, and how you would open it in Visual Basic. Visual Basic brought forth the Quick Basic concept that you open something in the context of file I/O. You open a file. You open a channel to the file. Or you open a port, for example.

REALbasic is a little more object-oriented. It has this sort of folder-child relationship concept. And that makes a lot of sense, because not everybody has the same kind of organizational structure that you find under Windows. So the REALbasic way is a cross-platform way, and the Microsoft way is the Microsoft way.

So there's a little bit of work that needs to be done for your file I/O and things like that. It's not that hard, and I hope you're not getting depressed at all, because I'm going to talk in a minute about a tool that's available from REALbasic that does most of this stuff for you, called the VB Project Convertor.

Anyone in here ever use that? A couple people? Yeah. It's a pretty cool little toy. It'll do a good job tool. It'll do a good job for you. So as we start looking at the language structure here, we can see, for example, how the structure of the methods and functions and events are put together. REALbasic supports methods, functions, and events, just like Visual Basic does. A little bit of difference here and there.

To exit something, you would say exit function, exit sub. I'm sorry, in Visual Basic, you say exit function, exit sub. In REALbasic, you just say exit, or return is a way to do that. And the other interesting thing is that in Visual Basic, if I have a function and it returns an integer, I would say the name, like the function would be called function 7. I would say function 7 equals the result of my function, and that would be the return value.

In REALbasic, you say return whatever the value you want to return is. So you don't assign the value of the function to a function name. You actually say return that value. So that's a little bit of a difference, but not that great. But you can still do things like create properties with a set and a get method, if you will.

And it works fine. And I've had no problems taking classes from Visual Basic and moving them over with a little keying. The same thing with events. Most of the ways you raise events. Are going to be similar. Here's an example in Visual Basic, and to do the same thing in REALbasic.

Not that different. They both support biref and bival, but there is a little bit of difference in the declaration of events. It'll take you a little time to sort that out, but start small and you'll be able to do it. So, with regard to constructs, there are no enumerations in REALBASIC.

And I know a lot of folks, people in here use enums? In your Visual Basic programs, anybody? Only one or two? Ah, then you don't worry about it. But if you use them, you like them. And I've been lobbying REALBASIC to put them in there. And, you know, one of the lead development people from REALBASIC is here, so we can gang up on him and lobby him.

They all offer constants. One of the nicest things, yeah, look, Cordis is like, ah! You know, he's like, ah! So one of the coolest things about REALBASIC that I like is this whole cross-platform thing. I can create a constant, and then I can have that constant have a different value based on the platform that the program runs on.

Visual Basic has no concept of that at all. And you find these kind of things in REALBASIC all the time. Just when you think about something as a cross-platform tool and not a Windows-specific tool, some of these other really interesting things show up and have found their way into the language that are pretty awesome.

Hank Marquis So constants are going to work, and you have even more capability with constants. Like for example, you could do localization with your constants as well. Not only can you say what platform it is, but what language it is. And that's all sort of built into the language editor. Hank Marquis UDTs are going to be something that will throw you for a loop initially, but I already fixed that. It's already solved. Email me, and I'll be happy to send you a REALBASIC class that lets you do the equivalent of user-defined types. No extra charge.

One of the differences in error handling that REALBASIC has versus Visual Basic is, Visual Basic has this really arcane thing that came out of GWBASIC, which is like millions of years old for those that remember it, which is the whole on-error, go-to syntax. And they still use that, by the way. Well, REALBASIC doesn't use the on-error, go-to thing. You can declare an exception in an exception handler, or you can use try-catch, and it's your choice which ones you want to use.

There are no line numbers supported in REALBASIC, and I have used line numbers. Traditionally, you use line numbers for debugging purposes, so you can sort of get an output of where you are and what's going on, but there are no line numbers. And the interesting thing is they both use RAISE to RAISE an error, so you can create and RAISE custom errors. So your error handling subsystems, in fact, most people, let's face it, most, I'm just going to go out on a limb, okay, no one in this room, but other developers you know who use Visual Basic don't use error handlers, right? Yeah.

And one of the really nice things about REALBASIC is that... is that in the application open, in the application object, every REALBASIC application has a top-level application object, and there's an error handler in there that you can turn on so that if any of your other code doesn't have an error handler, it'll chain back to that one. So you can just write one error handler and have a graceful dump.

It sounds like an oxymoron, right? Graceful dump. That's a lot better than it just splats. So at least, you know, so there's some really good things about the error handling in REALBASIC that make it worthwhile. Um One thing that's a little interesting to get used to is the whole dim, new, as new, as concept that Real Basic has versus Visual Basic. The words are similar but not exactly the same.

It all has to do with object instantiation and in some cases you can dim something and then try to use it, it'll splat because you didn't say new, set equals a new thing. So the object instantiation is slightly different but once you understand it, it becomes second nature. It's not that difficult. There's no set statement in Real Basic. There's a new. Visual Basic uses nothing and Real Basic uses nil and there's no let statement in Real Basic at all.

So I don't know, most people don't use let anymore. That's like old school. Let a equal one, you know, I don't think too many people do that anymore. So in conclusion, You're going to do some work. You're going to do some work if you move to .NET. You're going to do some work if you move to REALBASIC.

At the end of .NET, you have this "If you go to REALBASIC, you have this thing that runs on Windows, OS X, Linux, and it's my belief that that's probably a better way to go." So, at the end of the day, the good news is it's not that hard. I've personally found it easier than trying to do .NET.

There's enough things to make it possible, and your best bet is to get the manual, read it, play with REALBASIC first, get a feel for it, learn every language has its own little idiosyncrasies. It'll take you a little while to get away from the Visual Basic dropdowns with the procedure names in it, to having a list of them on the side. So just play with it, get the hang of it, and then you'll be able to move on.

User Interface Well, you know, suffice it to say, anything that was designed and built around the Mac has a user interface that knocks the socks off of anything that came out of Windows. I'm an IBM guy, you know, from my mom, you know, for millions of years, but I just got to admit it, you know, it's heads and tails above. You know, REALBASIC has two-dimensional and three-dimensional rendering engines built into the language, and you can do some amazing things.

One of the other things I find amazing is, again, that cross-platform mentality made it so that, if I write a program, let's just even take a VB program and make it so it runs under Windows, and I compile it on Windows 2000, and it's got that Windows 2000 look, you know, that, like, Windows 3.1 look.

Well, if I take that and go run it on Windows XP, it just picks up themes, and it looks like it's a native XP app. So as far as REALBASIC is concerned, they are different platforms, and it does the appropriate thing, and it does that for Mac as well. It does the same thing for Linux.

I wrote a class. I wrote a class that will take my application interface and size buttons and move things around based on where it runs. So not only does it have the graphical look and color scheme and borders and so on, but the actual button size and position themselves appropriately, because, well, I get back to, like, Mac users have this expectation that buttons have different titles and they're in different locations, and, you know, Windows likes to do the whole abort, retry, you know, hang yourself thing, which, you know, you don't do in the Mac world and things like that. So anyway, user interface is mostly the same. except it's a lot richer.

VB has a thing called a Pitcher Box. The equivalent thing in REALBASIC is probably a Pitcher Well or Canvas. Canvas has a lot more flexibility as a thing you can subclass and make your own thing controls with. Pitcher Well just holds a pitcher. Both support, by the way, your ActiveX components will move to Windows if you use REALBASIC, but ActiveX doesn't exist in Mac OS X.

RealBasic has this concept of plugins, but the plugin is not an ActiveX. So there's these two sort of different methodologies, but RealBasic supports ActiveX, but if you're going to move to a platform that doesn't support ActiveX and COM and that whole Windows infrastructure, it doesn't work. So the funny thing is that when you get done porting your Visual Basic program into RealBasic, not only will you have, say, OS X compatibility, you'll have a program that handles Windows better than Visual Basic does. That's funny. I just think that's funny. Okay, so again, you can read as well as I can.

If you're using things like Tree View and List View, it's going to be one of the biggest issues you have. There is no Tree View and List View equivalent in the Macintosh world. Macintosh has, I forget how many, it's like 36 or 8 different constructs that you can use for user interface widgets, or I forget the exact number. So you're going to want to try to find a model, because it's generally frowned upon to create your own

I already talked about the XP themes. Project structure.

When Visual Basic first came out, it created a single big binary file. And then it used to get corrupted all the time, and people would hang themselves. And after enough developers, you know, people would just, it was terrible. You had to start over, and you had to have backups, and it was just bad. And then they brought in other formats, and now with VB 5 and 6, the text saving, except for FRX files, are pretty much the standard.

Real Basic is the same way. It's got a big binary file, but you can also save it as XML if you want, and XML is a nice format because it actually is nicer than working with text files. So from a structural perspective, you can use the XML or the binary file. The app module is unique to Real Basic, and it's pretty cool.

And once you get the hang of what it's about, the whole object, Real Basic is object-oriented, truly. And once you begin to get the feel of that, you're going to have, you know, to be able to, you're going to be able to do some things that you couldn't do in Visual Basic that are good.

Menu creation and structure is a little bit different than Visual Basic and Real Basic. They both have editors, but they're just a little bit different. And then there's MIDI, SDI, MDI issues. Not so much an issue anymore because Microsoft is pulling back from the MDI concept. If you, you know, the latest versions of Word and Excel and PowerPoint and so on, for example, aren't MDI applications anymore. They show up down as individual copies of the application. So you can make MDI applications if you want in Real Basic, but there's really no need to.

APIs. We talked about this a little bit as we got going, but one of the interesting things about REALbasic is that, kind of like, who remembers VB4? Yeah, old school guys out there. Yeah, we're still here. Well, they had this, and even in VB5, you had this strange ability to be able to say, if it's 16-bit code, do this, and if it's 32-bit code, do that. Well, it's the same kind of concept here, but it's like, if I'm OS 9 or Carbon or whatever, do this. If I'm OS X, do this.

If I'm Linux, do this. If I'm Windows, do that. And so you have these declarations. And what you can do then is you can use Windows APIs or whatever API you want. You just have to do a block of them for whatever the particular application is that you want.

So it's actually a lot more flexible. Okay, some of the other considerations you're going to have to deal with. Don't forget the fact that... There's a different expectation for Macintosh users versus "Windows users. They get the look and feel. There's the way things work, the way things look, the way things are named.

There's a process flow that you want to pick up. So you're probably going to want to go download the platform development guidelines and things like that." - Tools. How many people use tools for the, you know, in their VB world space? Like optimizers or debuggers or things like that? Nobody? Don't need them? Only a few people.

Almost all of your user interface will just come right over, just show right up and look fine. And like I said, Windows-specific custom controls will be the biggest problem you have dealing with that. So, and also, you're going to need some tools. Well, you don't need it, but wouldn't it be nice if there was something you could get for free that would translate your Visual Basic program into REALbasic for you and give you a starting point? Go like this. Oh, you guys did stay up way too late last night.

Visual Basic Project Convertor can be done given the constraints that we just spoke about. If nothing else, in some cases, things just load and work. And there's a trick to using the project converter that will make it easier for you. In some cases, it loads up in real basic and it won't work for 15 or 20 minutes while you, oh, I got to this, oh, that's right, that should be an integer, you know, and you got to do a little tweaking.

But it brings it right over. It's not perfect, but you know what? It's a lot better than not having it. So we're going to talk about exactly how it works. So before you use visual basic project converter, you need to clean up your VB code. And this is where, like, how many people, I don't know how many times I've done this, but it's like, you know, especially newer VB developers got sloppy, you know, using variants and using ampersand instead of plus and not casting things and just generally being sloppy and writing code that C programmers always laugh at us for.

Well, it's, you know, it's easy to be sloppy, as we said. If you didn't do that, you're way ahead of the people who did. Because now, you're going to have to go back and unslop your code. And, for example, you want to get rid of ampersand for concatenation of strings. That's wrong in the first place.

It's really slow. It's, you know, use plus. You want to get rid of all those, you know, dollar signs and other things we talked about. You want to dimension all your variables, hopefully on a single line for your own sanity. Dim X as string, dim Y as integer. That would be really good.

Get rid of all your def X, def int, def long, whatever you've been using, get rid of it. And just remember that whatever you have cast as an integer in visual basic will become an integer in real basic, but an integer in real basic is four bytes long, not two bytes long like an integer in visual basic.

Try to get out of using currency and byte if you can, otherwise you're going to have to work around them when you get it over. You can use the char-ascii combination as a byte replacement, usually. You can do some manipulations to be able to do that. Substitute double for currency. Okay, before anyone starts slinging, I know there are rounding differences between doubles and currency. That's why currency is like it is. The REALbasic developers know that.

In fact, about two or three months ago, we had another session like this at RealWorld, which is the REALbasic trade show. And, you know, with great detail, several REALbasic developers very nicely articulated the issue. You know, they're going like this. It was funny. And so I know it's being worked on.

Thank you. The error handling that you have in your VB code is just going to go away. It's all going to become commented by the Project Convertor. So you're going to have to find it and fix it after that. So things to do beforehand, get rid of go-to.

I mean, you can use it, but, you know, if you don't need to, don't. I mean, you can still use it, but you can't say go to a line number. You can go to a label. Move things from forms into modules. Bust up your code, if you can, into chunks of related function, if you have. And if you've got the all-singing, all-dancing VB Form app, you know, you must have seen them if you've been around long enough. It's like, you know, Form 1, and it's 6 megabytes big. It takes forever to load, and it's just everything. Try to break it up.

There's no such a thing as Go Sub in REALbasic, so functions and methods and logic are going to be required. And REALbasic does have the database engine and has SQL capabilities. It's different than the sort of Microsoft model, you know, the ADO control model that Visual Basic has, but the SQL logic will largely be compatible. You know, select star from whoever. Things like that will work fine.

So what was the experience using it? Well, it always creates a project. Now, REALbasic doesn't have individual modules, as we already said. I mean, they do logically. But when you save it on disk, it's one big file, whether it's XML or it's a binary project. So if I just bring over one module of Visual Basic code that I want to port, it'll port it, and it'll create a REALbasic project with an application object. It'll have a default window in it, and it'll have my module. So you're going to have to take that and then save that module out on the side. That's not that hard to do.

Some things are going to be problems. Like when I was doing some conversions, I had a variable in one of my programs called graphics. Actually, it was a class, I think. So I had whatever, I was using the word graphics. Well, graphics is a reserved keyword in Real Basic because they actually have a paint event where you get a graphics handle that you have to use APIs for. And Visual Basic actually just happens by default as an argument passed to the paint event of an object or a form. It's like, oh, here's a graphics object. And that's a graphics dot this or graphics dot that.

So that keyword is, you know, they've got to worry about those things. So my advice, use the VB project converter to convert one file at a time. After you've converted a file, export it or make what Real Basic calls make external, which is how you can have external files and how you share files between projects. Make it external.

And then debug or port that code. This gets back to busting my code up into modules and things I can exercise. And, you know... Just do it again and again until you're done. It's called programming. In the end, you can do it. It works. I'm living proof of that.

And just remember that REALbasic is object-oriented. It's, in my opinion, a better language than Visual Basic. And why do I say better? Because it made me get cleaner about the code I would write. And I'm just, I'm programmed now. You know, I'm like, my lightsaber shines green instead of red. You know, I'm over to the dark side.

So, you know, I find myself dimming everything, and everything's a class, and I'm just, you know, I just, this whole object-oriented thing has taken me over. It's cool. I like it. At my age, you don't learn new things very often. So, again, you can read as well as I can.

I've talked about most of these things. Import one piece at a time. Test as you import. Build them up as external pieces. And now you've really moved your Visual Basic code into a stage where you can compile for any platform you want, not the least of which is OS X. Thank you.

And of course,

I thought it might be nice to talk about a couple marketing opportunities. After you've done the work that Hank outlined for you and you have a publicly available app, whether it's commercially available or freeware, shareware application, you might want to get the word out about that, having taken the time to come to a new platform.

So here's a couple free marketing opportunities that are available for you. The first is the Real Basic Showcase. So the folks at Real Software have put together a part of their website, realbasic.com slash showcase, and you can go there and list your application. And one way for customers to find out about it.

The other is the Macintosh Products Guide. So there's a shot of it there. There are 25,000 products in the Macintosh Products Guide. You can list your product for free, and there are also pay opportunities to get some of these larger ads that you see there. And that's at guide.apple.com. And that is very much the storehouse of record for all the products available for Mac OS X. And I would encourage you, again, if you have a publicly available application, to list them in these two different areas. Take advantage of these free co-marketing opportunities.

For more information, you're welcome to contact myself, Tyler Stone, Developer Relations. You can see here Hank's email address up there, which is hank at slayfire.com. And you can also contact the folks at Real Software. Matt Qualiana has volunteered his address, matt at realsoftware.com, if you want more information about the REALbasic tool itself. We're doing pretty good on time here. Let's run through these resource libraries.

I'm sorry, so we have some resources available for developer tools over at slayfire.com. There's actually a good comparison of different IDEs out there at Codefu at the Rosetta site. And go to the Real Software site if you want to see kind of a point-by-point comparison, REALbasic to Visual Basic from a feature point of view.