VisualNewt Software

Programming Using NSBasicCE

ARTICLE 3--Objects, Methods, and Properties! Oh My!

All content (c)1999, 2002 Serg Koren.

All rights reserved.

Welcome to the third installment of NSBasic on the CasioE-105.

This time around I'll discuss some major concepts in computer programming today, namely the concepts of object-oriented programming (don't worry, I'll go slow). But first, I left off the last article with a question.

Leftovers from Last Time

Given the following code snippet (which you can enter into NSBasic...see the last two articles on how to do this).

'---start code here---

' Everything inside a SUB or FUNCTION gets done programmatically and waits to be told to run by your program.

SUB ProgrammaticMsgbox

MSGBOX "This is the programmatic one."

END SUB

' Everything outside a SUB or FUNCTION gets done immediately (as soon as you hit Run).

result = MSGBOX ("This is an immediate mode MSGBOX. Tap Yes to see a programmatic one.",vbYesNo)

IF result = vbYes THEN

	ProgrammaticMsgbox ' tell our programmatic MSGBOX to run now

END IF

'--- end code here -----

The question I asked was: Why don't you get the window with "This is The programmatic one." first? Lines in programs get executed (run) in sequence from the first (top) to last (bottom).

The answer relates directly to the last article. First thing I should mention is that any line starting with a single-quote (') is a comment, and ignored by NSBasic. It's a way of reminding you or explaining to others what your program code is actually doing. Use comments extensively in your program. I'd go as far as to say, that you should probably have more comments than code (but I won't hold you to it).

Anyway, the answer is that the MSGBOX "This is the programmatic one." doesn't show up first because it doesn't execute UNTIL the SUB (subroutine) is called (executed). Where does it get executed? It gets executed LATER in the program when the result = MSGBOX(...) line gets called. And this gets called in IMMEDIATE (see the last article) mode, but only when you tap the Yes button on the first dialog (This is an immediate mode MSGBOX. Tap Yes to see a programmatic one.)

So in short Immediate mode commands get executed right away. Programmatic mode commands (those in SUB or FUNCTION) only get executed when called.

This leads to the ultimate conclusion that all NSBasic programs ultimately get run from an Immediate mode command somewhere in the program. I'll give you a general guideline to better programming:

The better (more organized) your NSBasic program is, the fewer Immediate mode commands it has in it.

You can't get away from Immediate mode commands, but you should only use them when you have no other way to go. We'll talk more about this next time, but now some more concepts and some more code!

Object-Oriented-Programming: Object, Methods, Properties, Events

Object-Oriented-Programming (OOP for short) is the way to go nowadays. It's the big thing. It's a way of thinking about programming. The little bit of code we've seen so far has not been OOP. The stuff we've seen is called "procedural programming" (sorry no acronym for this). It's procedural because it has procedures (also known as SUBroutines and FUNCTIONs). The code gets executed line by line from the top down (with sidetracks as SUBs and FUNCTIONs are called). It's procedural because you're basically doing instructions to get, massage, and output data by issuing commands.

OOP thinks differently. Instead of thinking about data and what you do with it, for something to happen, you think about objects (real such as cars, loaves of bread, etc., and psuedo-objects such as arrays, lists, and even numbers.). In OOP you define objects that represent real (and not so real) things in the world. Each object you define knows how to do what the object does. A car object would know how to speed up, slow down, turn, brake, stop, etc. How does it know? Once you define an object (car) you define the things the car object knows (speed up, slow down, brake, etc.). These "things" the object knows how to do are called methods. So Objects have Methods which are things that Objects know how to do. In other words, you wouldn't have a Method in a car Object called "MakeToast", because a car doesn't know how to make toast (usually)--a Toast Object would have a Method called MakeToast. How many Objects can you have? As many as you need. How many Methods can an Object have? As many as your Object needs. Ok. So we have a car Object and it knows how to speed up using a SpeedUp Method. How fast is the car going? How does the car Object know? Via a Property. Properties are characteristics of the Object. A car Object would have a Speed Property; it would probably also have an Acceleration Property that told it how fast the SpeedUp property was accelerating the car. A car Object would also have Make, Model, Color, Year properties. Any characteristic that the car Object would have to worry about and use. If the car Object didn't care what Color it was, you'd leave out the Color Property.

So, in OOP you design (or in NSBasic you use) Objects, that have Methods that makes the Object do things, and Properties that tell you things about what the Object is doing at that instant (the Speed may be one thing--30mph now--but may be 105mph later.) Ok. There are two more OOP concepts we need to worry about (there are lots more things to know about OOP, but this is really all you need for NSBasic. How do we tell an Object it should do something? We send the Object a Message. For example, to tell our Car Object that we want it to speed up, we might send a "speedup" Message to the Car Object. The Car Object knows that this means it should call the SpeedUp Method which really does the work of speeding the car up. The last concept is one of Events. An Event can be thought of as a trigger that causes the Object to do something. In our example, the Car Object receiving a "speedup" Message is an Event. The Car Object speeding up, may or not be an Event depending on how it is written. Another type of Event is one caused by the user of the program (you). Tapping on something, typing something, dragging something, are examples of user-generated events. Typically, you have to tell (write code) to tell the Object what to do when the user generates an event.

Phew!

So: Object--->knows how to do something which are Methods

Object--->has characteristics which are Properties

Object--->get sent Messages which cause Methods to execute

Objects-->react to Events (receipt of Messages or user caused events)

That's a lot of info to digest but it isn't too hard to understand. Just a lot of jargon.

You may be wondering now....Why oh why do I have to worry about this stuff? Why can't I just program using NSBasic like we have been? Well to be honest you could, but your programs would really be very primitive and crappy looking. The fun stuff is all done using OOP. The fun stuff in this case being the user-interface (GUI--buttons, menus, edit fields, calendars, databases, etc.)

To take a more concrete NSBasic example, get your NSBasic Bible out (the manual) and turn to the ListBox page. The title on the page has the word Object on the right. This tells you this page describes an OOP Object. (If its a SUBroutine or FUNCTION, it will have SUB or FUNCTION; you will also find STATEMENT which is a simple command in NSBasic, and OPERATOR which is part of a statement.). Ok, a ListBox in NSBasic is an Object, which means it has Properties, Methods and Events. These are all listed at the bottom of the page. A ListBox has Properties named: BackColor, Bottom, FontBold, etc. Properties are characteristics. They determine what your ListBox looks like. You can set these or you can look at them to find out what your ListBox looks like. Methods supported by a ListBox include Hide among others. So our ListBox Object knows how to Hide itself (make itself invisible). Events of a ListBox include Change, Click, DblClick, and GotFocus. Hm...no Hide event, no MakeInvisible event. Why? Because typically, the ListBox doesn't disappear as soon as a person clicks on it. That's a key there! "Clicks on it" So how do we get a ListBox to hide itself? Well we use the Hide Method, by sending the ListBox a Hide message. How do we send messages? We use the name of the Object a dot (period) and then the name of the Method we want to have the Object execute. So, to send a Hide message to a ListBox we would write:

ListBox.Hide

and the ListBox would disappear. We can use the Visible Property to see if it is hidden or not similarly:

... ListBox.Visible ....

The ... indicates other code we aren't going over right now.

Extending this, how do we get a ListBox object to disappear when we double-click on it? Well we use the DblClick Event to send our ListBox.Hide Message.

Events are defined as SUBroutines in NSBasic and instead of the period we use an underscore (_) (I'm not sure why). So our code looks like:

SUB ListBox_DblClick ' respond to a user clicking on our ListBox

ListBox.Hide ' hide the listbox by sending it a Hide Message which executes the Hide Method.

END SUB ' always need an END SUB (or END FUNCTION for a FUNCTION)

Cool huh? One thing we bypassed (deliberately) is how to make a ListBox Object. Your program can have hundreds (well tens) of ListBoxes, how do we know which one we want to hide? Well when we create one, we give it a Name. An Object has a Name (which is really a Property). So if we have 2 Car Objects one may be Ted's Taurs, and the other Tom's Taurus. We create an Object in NSBasic using the ADDOBJECT command as listed at the top of the page in the manual. For a ListBox it is:

ADDOBJECT "ListBox",name,xpos,ypos,width,height

"ListBox" is the type of Object we want to create.

'name' is something you provide as the Name for your ListBox. Names in NSBasic have to be strings (enclosed in double-quotes ").

xpos,ypos are the x and y coordinates of where the ListBox will be (Properties) as are the width and height of the ListBox.

Here's your first complete NSBasic program (simple though it is):

'---start code here---

'

' A simple program that creates a ListBox and lets us show and hide it by clicking on it

'

' A subroutine to create a ListBox on the screen

SUB MakeAListBox

	ADDOBJECT "ListBox","MyListBox",50,50,100,100 ' create an empty ListBox

END SUB

' A SUB to handle a DblClick Event (a Click event handler) for the ListBox called "MyListBox"

SUB MyListBox_DblClick

	MyListBox.Hide ' Hide MyListBox

END SUB

' Our main routine where the main things happen...good to always have one

SUB Main

	MakeAListBox ' create a ListBox

END SUB

Main ' our one and only Immediate command for this program to run the Main SUB

'---end code here---

Simple huh? If you can follow the above program, you've gone through the most difficult concepts in NSBasic. Everything else is just learning the individual Objects, and commands (Statements). Browse the manual and look at the Objects (upper right title) and look at the Properties, Methods and Events each type of object supports (many are similar).

Simple quiz for next time. Write a short program (like above), but include a CommandButton Object. The program should have:

1) A ListBox

2) A CommandButton

The program should:

1) Hide the ListBox when you double-click it.

2) Unhide (use the Show method) the ListBox when you tap (Click) the CommandButton.

We'll show you one version of the code (and a simpler version) next time. Next time, we get into real programming and fewer concepts! Stay tuned!

Cheers!