Ladies and gentlemen and welcome to session 636. At this time we'd 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. Thank you.

Good morning, everybody. I know everyone was up late last night. Was everybody up late last night? now. 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? Good. How many people in here have seen and/or used Real Basic? 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, 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 how, 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 a 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 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 underwriter's 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 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, and you 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've 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 every day to do things in a 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 away, you've got a little bit of a learning curve. You've got to go figure. 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 X, 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 SlaveFire products without using a single API call. and they run on all three platforms. So some rethinking needs to be done, but a lot of times you can do it, and Real Basic's 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 X, 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 real basic is... I don't know, if you're a VB developer, and you're good, 20 minutes. If you're new, two, well, no, 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. 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 Real Basic 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 Real Basic implementation currently today, it does not. Now, to Real Basic'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. Thank you.

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 know, you're not gonna last forever. Some, you know, someone somewhere someday is gonna look at your code and go, "Wow, What am I doing with this? So real basic 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, graphic-wise, it isn't there. A funny thing, a Visual Basic application, by default, can't even pick up the Windows XP themes on its own. So your VB apps look like Windows 3.1 apps when you run them on XP. So graphically, it's not very cool. But Real Basic is really graphically rich, 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. *sniff* So 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 Real Basic.

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 chr32, 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 real basic 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 Real Basic 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 Real Basic calls it uppercase and Visual Basic calls it U-case. So you may say, that's not so bad. I can just go through my VB code, do a global edit replace U-case with uppercase, and I'm happy. Or I could import it into Real Basic and do a global U-case 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 pour, 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 Real Basic, so I'm not pushing my own book, but there are other books. And the Real Basic 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, 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 Real Basic. Real Basic can open modules and just load the code right up and show it in its editor, and it actually looks pretty cool. But 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." And I was like, "Yeah, watch this." I cracked my knuckles and I'd do something that couldn't be done in VB. You know, like a file on a race program that did direct disk manipulation to be able to recover deleted files. And 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. 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 integer. 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 real basic and go dim, by the way, real basic 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. Okay.

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 do, 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 Real Basic, you don't do it like that. You say for i equals 10 down to 1. There's no step minus 1 in Real Basic. So you're going to have to do a little bit of, you know. And in fact, you can actually have that code in there, the 10 to one step minus one, the loop just never gets executed. It skips right over it because i is already one or less than one 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 Real Basic did. So the folks in Visual Basic for the longest time, or, and, x, or, 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 Real Basic. Real Basic actually has true bit manipulation. So you're gonna 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 gonna 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 like start to compile and go. and then you'll have to, oh yeah, that's right, x dim x as integer or dim y as string. So you're gonna wanna 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. Real Basic 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 dollar in Real Basic. You could 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. Look for loops, look for those four loops I talked about, and just remember, mark them, that you're gonna 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 Real Basic 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 Real Basic has a much richer set, and it also has Indian 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 Real Basic to talk about maybe getting that into the Real Basic language, 'cause there are no user-defined types per se in Real Basic. What you do have in Real Basic 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 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 by name. 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 real basic, 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 real basic 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 kinda 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 Real Basic, 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. Now, 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 Real Basic and how you would open it in Visual Basic. just a little bit different. 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. Real Basic 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 real basic 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 real basic that does most of this stuff for you called the VB Project Converter. 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 structures of the methods and functions and events are put together. Real Basic supports methods, functions, and events just like Visual Basic does. A little bit of difference here and there. In Real Basic... to exit something, you would say exit function, exit sub. I'm sorry, in Visual Basic, you say exit function, exit sub. In Real Basic, 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 function7. I would say function7 equals the result of my function, and that would be the return value.

In real basic, 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 Real Basic.

Not that different. They both support by ref and by val, 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 Real Basic. 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 Real Basic to put them in there. And one of the lead development people from Real Basic is here, so we can gang up on them and lobby them. They all offer constants. One of the nicest things, yeah, look, Cordis is like, ah!

So one of the coolest things about Real Basic 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 Real Basic 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. and they're really good. So constants are gonna 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. The UDTs are gonna 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 real basic class that lets you do the equivalent of user defined types. No extra charge.

One of the differences in error handling that Real Basic has versus Visual Basic is Visual Basic has this really arcane thing that came out of GW Basic, 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, Real Basic 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 Real Basic. 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 Real Basic is that in the application open, in the application object, every Real Basic 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 Real Basic 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, 'cause 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 Real Basic. At the end of.NET, you have this thing that runs on Windows. If you go to real basic, 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 real basic 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 drop-downs 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, suffice it to say, anything that was designed and built around a Mac has a user interface that knocks the socks off of anything that came out of Windows. I'm an IBM guy from my mom, from millions of years. But I just got to admit it. It's heads and tails above. Real Basic 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 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 Real Basic 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 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 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 Real Basic 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 Real Basic, but ActiveX doesn't exist in Mac.

and therefore it won't work. And that, you're going to have to deal with that. Real Basic has this concept of plug-ins, but the plug-in is not an ActiveX. So there's these two sort of different methodologies, but Real Basic 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, is that when you get done porting your Visual Basic program into Real Basic, 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 TreeView and ListView, it's gonna be one of the biggest issues you have. There is no TreeView and ListView equivalent in the Macintosh world. Macintosh has, I forget how many, it's like 36 or eight different constructs that you can use for user interface widgets, or I forget the exact number. So you're gonna wanna try to find a model, 'cause it's generally frowned upon to create your own You can create controls as long as they follow the model that Mac has this look and feel thing that you gotta kinda roll with. So you're gonna have to create your own and do that. You may need what you call roll your own. Another good thing to do is to just stick with the intrinsic controls. If you only use the controls that are there by default, the ones that are built in, that you don't have to ship an ActiveX DLL COM object with, then that's pretty much gonna roll right over 'cause those intrinsic controls are fine.

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 VB5 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 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. 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 Real Basic 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, you know, 9 or Carbon or whatever, do this. If I'm OS 10, 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 every 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 gonna have to deal with. Don't forget the fact that, there's a different expectation for Macintosh users versus Windows users. They 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.

How many people use tools in their VB world space? Like optimizers or debuggers or things like that? Nobody, don't need them, only a few people. You're going to have to find them. Program structure issues. We talked about it. So, well, at the end of the day, I think that if you're a three-quarters decent Visual Basic developer, that means you've been writing in Visual Basic for a year or two, or maybe a little bit more. You should have absolutely no problem porting almost anything you've done in Visual Basic to Real Basic. It's going to take some manual tweaking, and you have to decide up front, because I've spoken to some people that have said, well, you know what? This thing's been dragging along since VB3, and I've wanted to redo this for a really long time, and I'm just going to start from scratch in real basic. But I don't have to throw all my code away, because I've got some classes or some modules and some things I've done that I want to reuse. So you have to decide, once you look at it, whether you want to toss it in and come from scratch. But in most cases, at least some of the code will move forward, if not everything. Amen.

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. And also, you're gonna 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 Real Basic for you and give you a starting point? Go like this. Oh, you guys did stay up way too late last night.

We should have that music. You know, they call it the, you know, like the orchestra music in the background. Visual Basic Project Converter. What is it? Where does it come from? It's a free tool from Real Software. It's got a drag and drop interface on it. And it will attempt to convert your Visual Basic stuff to Real Basic stuff. And it works like this. You drag your Real Basic stuff over. You drop it. You click button.

Outsquirts Real Basic stuff. as converted as 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. And 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 do this. Oh, that's right. That should be as integer. Oh, 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 use plus. You want to get rid of all those dollar signs and the other things we talked about. You want to dimension all your variables, hopefully on a single line for your own sanity. Dim x as 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 gonna 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 real basic developers know that. In fact, about two or three months ago, we had another session like this at Real World, which is the Real Basic Trade Show. And, you know, with great detail, several Real Basic 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.

the error handling that you have in your VB code is just gonna go away. It's all gonna become commented by the project converter. So you're gonna 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 haven't. 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 one, and it's six 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 real basic. So functions and methods and logic are going to be required. And Real Basic 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, Real Basic 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 Real Basic 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.this or graphics.that.

So that keyword is, you know, they gotta 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 report 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 real BASIC 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 programmed now. You know, I'm like my lightsaber shines green instead of red. You know, I'm over to the dark side. So, I find myself dimming everything and everything's a class and I'm just, you know, this whole object-oriented thing is taking 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. and of course That's where this gentleman comes in. Come back up for a second. Thank you very much, Hank. No, no.

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 Real Basic tool itself. We're doing pretty good on time here. Let's run through these resource libraries. reference library, 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, real basic to visual basic, from a feature point of view.