Personal tools
You are here: Home Anatomy of a MapBasic Program
FrontPage >> MapInfoRoadmap >> MapBasicDevelopment >> A Short Course in MapBasic >>

Anatomy of a MapBasic Program

Document Actions
last edited 1 year ago by sumitkaul

A MapBasic program is a text file composed of MapBasic statements and compiler directives. Typically at the top of the file you put compiler directives like Include, Define and subroutine and function declarations. Global variables are also typically initalized here too. These are followed by blocks of code that constitute sub procedures and functions. All MapBasic programs must contain a subroutine called Main, because this is the one that starts the program. These "source code" text files are named with an ".mb" extension.

Once your code is written, it must be compiled into a MapBasic executable, which will have an .MBX extension. The MBX file is a binary file that is run by MapInfo and this is what does the work.

The way to learn programming is to just dive in and do it. So start MapBasic, open a new file and enter the following (we'll explain things later.)

Declare Sub Main

Sub Main Print "Hello, world!" End Sub

Save this file as "hello.mb" and then compile it by choosing Project/Compile Current File from the MapBasic menu. Then to run it, choose Project/Run. If all worked as it should, you will see the phrase "Hello world!" in the message window.

As mentioned above the MapBasic applications start point is the Main procedure. So in order to keep your source code well structured and easy to overview, you should move your code from the Main procedure to other procedures. In this way you will also be able to use these procedures from elsewhere in your application.

If we do this, your application will now look like this:

Declare Sub Main
Declare Sub PrintMessage

Sub Main Call PrintMessage End Sub

Sub PrintMessage Print "Hello, world!" End Sub

Now if you compile and run the application, you can see absolutely no change in the way the application is running and what it is doing. But your source code is better structured.

Let's continue this. At the moment the PrintMessage always prints the same message to the Message window. We now want to change this so that the caller of the procedure can decide what message to print. In order to do this we have to send a parameter to the procedure. This can be done in this way:

Declare Sub Main
Declare Sub PrintMessage(ByVal sMessage As String)

Sub Main Call PrintMessage("Hello, World!") Call PrintMessage("Hello, World! Twice!") End Sub

Sub PrintMessage(ByVal sMessage As String) Print sMessage End Sub

Let me explain what is going on. As you can see, the PrintMessage procedure has been changed to receive a parameter. The parameter is sent to the procedure ByVal. This means that sMessage contains a copy of the original value, not a reference to it. If you omit the ByVal keyword, the PrintMessage procedure receives a reference to the variable in the procedure calling the PrintMessage procedure. In this way PrintMessage can actually alter the variable in the calling procedure. By using ByVal we make sure this is not possible. Another reason why you should prefer ByVal to ByRef in some places, is that ByVal lets you pass a constant value instead of a variable into the subroutine.

You can also see that the Main procedure now calls the PrintMessage procedure twice, but with different messages to print.

Compile and run the application. In the Message Window these message should now appear: Hello, World! Hello, World! Twice!

(to be continued...)


comments:

Continuation --sumitkaul, Wed, 27 Jun 2007 04:05:25 -0500 reply
Hi.. When can one expect the continuation of this tutorial.

Thanks/Sumit

« December 2008 »
Su Mo Tu We Th Fr Sa
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
 

Powered by Plone, the Open Source Content Management System

This site conforms to the following standards: