VisualNewt Software

Programming Using NSBasicCE

ARTICLE 2--The Editor and Modes

All content (c)1999, 2002 Serg Koren.

All rights reserved.

Welcome to the second installment of NSBasic on the CasioE-105. If you're joining us late you may want to peruse the Introduction if you haven't done so already and the archived article at: http://www.VisualNewt.com/CE/NSB/AvantGo/Archives

This time around I'll discuss the NSBasic editor, the modes that NSBasic works in and some introductory material on Objects. In addition we'll do some fairly basic (excuse the pun) programming. Most people tend to jump into programming with a full blown example program and dissect it to explain how to program. I'm going to take the bottom up approach and start simple and work our way up so that I don't lose anyone along the way. You can't build a house from the top down, so we're going to lay a good foundation first.

The NSBasic Editor

If you haven't done so, you want to install NSBasic (see the first article) and start it (Start/Programs/Basic). The program that runs is the NSBasic Editor. This is where you will spend most of your time writing and developing your programs. It has the principle features of most editors, but in addition it has features specific to running and debugging your programs. Debugging, I'm sure you probably know, means finding problems in your program and fixing them. We'll have a whole article or two on debugging.

Let's go through the editor and describe its features. Along the top is the menubar with all the functionality and commands available to you. The large blank spot is where you can 'type' your programs. The menubar has some familiar features under the File and Edit menus; I'll only describe the things specific to NSBasic.

Under the File menu, there is an item labeled Encryption ON or Encryption OFF. This is a toggle menu and it switches between the two based on the source code you happen to be editing. You can also manually toggle it. Try it. What this menu does is save your program in either an encrypted or normal (Encryption OFF) format. If Encryption is OFF, then anyone can see and read and understand your source code (your program's commands). This is useful if you want to distribute your program on the Internet and you want people to see how you wrote your program. If Encryption is ON, then if you distribute your program on the Internet, then people will only be able to run your program. They won't be able to see your source code, or see how you actually did things. You on the other hand, will always be able to see your own programs no matter how they are saved (Encryption ON or OFF). The menu not only tells NSBasic how to save a program, but also reminds you how a program was saved by you when you Open it in the editor. So if you saved a program with Encryption ON, so people won't see your source code, and you go into the Editor and open the source file, Encryption will be set to ON. (You can switch it to OFF if you want to let people see the source code, or vice-versa). Try tapping a few characters into the editor and saving the file with Encryption ON and save another copy with Encryption OFF. Now quit the editor and restart it. Using the File/Open menu open each of the two files you saved and look at the Encryption menu. One should be ON and the other OFF. You can try switching the settings and resaving the files, and then reopening them to see the effect. It's fairly simple. The thing to remmeber is that the person who wrote the program always get to see the source code on their own machine, no matter how they saved it.

Ok, under the Edit menu there are two unfamiliar items: Goto Line, and Overview. GotoLine brings up a prompt and lets you enter a line number. The editor will then move the cursor to that line number. This is useful if you get an error and the error gives you the line number where the error occurred. You can use this feature to jump right to it. Overview is similar to Goto Line in that it lets you jump to a given spot in the program. Instead of jumping to a line number, however, it lets you jump to either a subroutine or function name. Subroutines and functions are "chuncks" of programs that are given names. The names identify and let you reuse a "chunk" from more than one spot in the program. We'll go over this later, but for now you can see how this feature works. Using File/Open, open one of the sample programs that come with NSBasic. Then use the Edit/Overview menu item. Depending on how big the program is, you should get a list of subroutines and functions in a second or two. You can scroll through this list (if the program is long enough). If you don't get a list, then the program you selected has no subroutines or functions. Just open another sample until you find one that has these. Once you have a list up, select one of the items in the list and tap the Goto Line button (which really should say "Go to routine") The program will automatically scroll the editor and select the line with the name you selected. The Overview feature lets you jump to places by name and is useful for long(er) programs.

The Tools menu has a lot of powerful features, so we'll take them one by one.

Format: The Format menu item tries to clean up your program's formatting. It lines things up and adds spaces where it thinks they are needed and basically "beautifies" your program's source code so its easier to read. It's not perfect and some people don't like how it does it (everyone has their own "style" of writing code...some people like lots of spaces, others don't...some like all capital letters, others don't.). But Format does a decent job. Its a good idea to run Format after you've written a lot of code, since formatting the code can sometimes show you were you might have a problem, if things aren't lined up the way you would expect. We'll talk about style later.

Run: This has a couple of submenus: Run, Execute Function, Trace, and Step. You'll use Run most often; it tells NSBasic that you want to try to run (execute) the source code you have in the editor. Try this: File/New to get a clean edit window, and then Tools/Run/Run . What happened? Your menu seems to have disappeared. Actually, it hasn't. You've told NSBasic to run your program, but you don't have one. Actually, you do, but it doesn't have any lines. NSBasic by default, creates a new blank window with a close box for every program. This blank window is where you will put all those keen (sorry for the word) features such as checkboxes, menus, pictures, fields, buttons, etc. that you find in programs. This is the window that contains them. Right now you can't do much with your empty window except close it via the close box in the upper right. So, close it, and you'll get your NSBasic editor back. So, if you're just starting out, and you mysteriously lose your menubar while in NSBasic, don't panic. Just close the window and you'll get back to NSBasic and your program.

Execute Function is disabled. This is a debugging feature. Once your program is running there are ways to interrupt it and tel it to stop where it is. You can then switch back to NSBasic (using the a task manager you can download from various sites) on the taskbar at the bottom of the Casio screen. At this point, Execute Function will be active. You can choose it to specify a subroutine or function name (like the Overview), but instead of jumping there, NSBasic will try to run that "chunk" of program as if it were a mini-program. This is useful for seeing if a given subroutine or function (I'll stop using chunk, since I think you know what it means by now), is working properly. Programs get complicated fast, and the more subroutines and functions you can break your progam up into, the easier it is to find problems and keep from writing the same code over and over and over again. Think small. A good rule of thumb on the Casio is that your subroutines and functions probably shouldn't be longer than one screenfull of source code. Next!

Trace: Trace is another debugging feature. It shows you which line NSBasic is running as its running it. Two warnings with Trace. It slows the program down a lot, and it has a problem. Any program that has a line "OPTION EXPLICIT" will cause Trace to display an error message. You can temporarily comment out (remove) the OPTION EXPLICIT line and try again (don't forget to uncomment (put back in) the OPTION EXPLICIT line when done. Try this with the Benchmark sample in the Samples folder. Trace displays the line number, and the actual source code on that line as it executes it. Compare the results by using the Tools/Run/Run item with the Tools/Run/Trace item. Why is Trace useful? If your program is going somewhere and you think its should be going somewhere else, Trace can help you find where its going wrong.

Step is a more powerful (but slower) version of Trace. It has the same problem with OPTION EXPLICIT as Trace does. Step lets you stop after NSBasic executes a line and see what it did. Try it with the benchmark program (remove the OPTION EXPLICIT again). Once you do a Tools/Run/Step you should get a window with Line 1 at the top, the actual line being executed right under that, a big empty field on the left and two buttons, Execute and Continue on the right. The line number and the line are about to be executed; that means, NSBasic hasn't actually run the line yet. Try hitting the Continue button. The window should now display Line 2. Tap the Continue button a couple of times. You can step through the entire program this way to localize where a line has gone wrong. The big input field lets you type in a temporary NSBasic command and run it with the Execute button. This is useful for trying a simple fix to a line you've discovered is wrong, or for displaying the contents of a variable (a value) to see if your program computed it properly. Unfortunately, Step doesn't let you quit easily. There should be an Abort button. To get out of Step mode and return to the NSBasic editor, type the word BYE into the empty field on the left and hit the Execute button.

Those are the Run submenus. They let you run your program, as well as to help you debug it.

The next menu item on the Tools menu is Execute Code. This feature lets you try a little bit of NSBasic code without actually putting it into your program. This is useful for trying something out before putting it into a function or subroutine if you aren't sure it will do what you think it should do. Try this to see how it works: Tools/Execute Code to bring up a mini-editor. Type in the line:

MSGBOX "I'm learning to use the NSBasic editor."

Double-check the typing and quotes, and exeucte it. But there is no button to execute it, is there? Well what happens when you close the mini-editor, using the Ok box in the upper-right? It runs the code in the mini-editor. If you get an error message, simply close the error window, close the main window (the empty one usually) and then do Tools/Execute Code again. One nice thing about this feature is that once you close the window, your test code in the mini-editor is still there so you don't have to keep typing it in from scratch. Fix your typos and try again. So, Execute Code lets you try snippets of code before you actually put it into your main program. One problem with Execute Code is that once you have the code working in the mini-editor there is no easy way to transfer (copy/paste) it into the main editor. You have to retype it in by hand.

Show Variable on the Tools menu is another debugging feature and is only active while you are running your program. Once you've interrupted your program, Show Variable is active and brings up a window where you can type a variable name and display its value (contents).

Tools/Stats just gives you how many lines your program is and how much space it takes up on your Casio. Load in a sample program and select Tools/Stats. The word "script" in the message maybe confusing to you. A scripti s a set of commands to be executed, so in that sense NSBasic is a scripting language. There are other meanings of the word "script" in computing, but we won't go there just now.

The VisualDesigner item under the Tools menu is a fairly new addition to NSBasic and deserves several articles on its own. The VisualDesigner lets you design the GUI (checkboxes, menus,etc) for your program without having to write much code. But since we're trying to work from the bottom-up, we'll leave the VisualDesigner for future articles.

That's basically the NSBasic editor. The only other feature you should be aware of at this stage is the arrow button on the menubar. This is a shortcut for Tools/Run/Run. Pressing this button will start your program executing.

NSBasic Modes of Execution

Modes of execution refers to ways in which something gets done. This relates to the word "scripting" we mentioned above, and deferred until now. First some explanations and definitions.

NSBasic is an interpreted language. The other major type of language is compiled. An interpreted language is one that is read and executed line by line. You write a program with lots of lines in it. Each line is a comand. The interpreter takes that line and translates it into an intermediate language. When you run the program, the interpreter then translates the intermediate language into its effects (what you want the line to do). A compiled language is one where all of the program lines are "compiled" or translated into a form the machine it is running on understands. You don't need a program to interpret the program. This means two things for you as an aspiring NSBasic programmer. NBasic is interepreted, so any program you distribute over the Internet or to your friends needs something to interpret the program to run. This is provided in the NSBasic "runtime" module. This is a program that knows enough to run a program that's already written, but isn't powerful enough to let someone write a program. So, if you distribute a program, the person running it either has to have a copy of (a) NSBasic, or (b) the runtime module. (It doesn't hurt if he has both). The second thing this implies is that interpreted programs are a bit slower when they run than compiled ones. This isn't critical usually, but if you're trying to write a program that has to be as fast as possible, then NSBasic isn't the way to go.

What does this have to do with modes? Well because NSBasic is interpreted, it really has two modes of operation: immediate and programmatic. Immediate is just what it sounds like. You enter a line of code and execute it immediately. The programmatic mode gets run when the person runs the program. This is a very fine distinction, but an important one. Usually it doesn't matter, but in some programs it does. For instance, if you were to write a program with no functions or subroutines, your entire program would be running in immediate mode whenever you ran it. Anything in a subroutine or a function runs in programmatic mode. Another way to look at this is whenever you use an immediate command (one not in a subroutine or function), it gets executed right away and is really useful if you want to tell NSBasic something (as opposed to having your program do something). This is another definition of "scripting"; you're telling your programming enviornment (NSBasic in this case) to do something, instead having your program do what your program does. You'll find, as we go on, that some commands in NSBasic are for use in Immediate mode, while most are useful programmatically. For example the OPTION EXPLICIT command we'll see later is a command to NSBasic to force you to do certain things when you program, instead of when you run the program its found in. So what about our MSGBOX program? The way we were using it it's an immediate command (it's not in a subroutine or function), and is really telling NSBasic to display a window. However, you can (and will) use MSGBOX inside of functions and subroutines. That way, it would run programmatically, to tell your program to display the window. Yes it's a fine line, and one you can usually ignore. Just remember that some commands are only useful outside of subroutines and functions. Another term for immediate mode is command level or interpreter level mode.

A Bit of Code

Ok, we promised a bit of code. This example shows you the difference between immediate and programmatic mode. We won't explain it, but will say that the second window is programmatic, while the first is immediate. Start up NSBasic, and type the following program in. Save it (and call it whatever you would like). Then tap the right arrow on the menubar or execute a Tools/Run/Run command. Again if you have an error message come up, double-check for typos (careful to use double-quotes). Tap Yes to see the programmatic MSGBOX. What happens when you tap No instead in the first window?

' 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

Ok, a question to think about regarding this simple program. 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). We'll answer this question and discuss the above program next time, along with actually getting into more programming, now that we've gone over the Editor.

Cheers!

Programming Using NSBasicCE

ARTICLE 4--CommandButtons

All content (c)1999, 2002 Serg Koren.

All rights reserved.

Welcome to the forth installment of NSBasic.

This time we go over the most common user-interface object you will use: CommandButtons.

Leftovers from Last Time

Last time I we talked about Objects, Properties, and Methods, and I gave you a simple program that had a ListBox object that hid when you double-clicked it:

'---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 "listbox" 

SUB MyListBox_DblClick 	

    MyListBox.Hide ' Hide listbox 

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---

I then asked you to 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.

And I promised to show you one version of the code (and a simpler version).

Here's the version you probably came up with (or a something very similar):

'---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 subroutine to create a CommandButton on the screen 

SUB MakeACommandButton 		

   ADDOBJECT "CommandButton","MyCommandButton",50,75,100,50   ' create a CommandButton named MyCommandButton 

END SUB  

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

SUB MyListBox_DblClick 		

   MyListBox.Hide ' Hide MyListBox 

END SUB  

' A SUB to handle a Click Event (a Click event handler) for the CommandButton called "MyCommandButton" 

SUB MyComandButton_Click 		

   MyListBox.Show  ' Show the ListBox "MyListBox" when the user clicks "MyCommandButton" 

END SUB  

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

SUB Main 		

   MakeAListBox         ' create a ListBox   

   MakeACommandButton   ' create a CommandButton 

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

'---end code here---

The new code consists of the MakeACommandButton and MyCommandButton_Click subroutines, plus the MakeACommandButton line in the Main subroutine.

The points to remember from last article are:

1. Call Methods using the name of the object, a period, and the name of the Method: MyListBox.Show
2. Write event handlers using the name of the object, an underscore, and the name of the Method (event to be handled): MyListBox_DblClick

Now this looks like a lot of code (believe me it isn't) and complicated (again it isn't). If you followed the last article this should all make sense, if not reread the last article or email me with questions (Serg@VisualNewt.com).

The one question you may be asking, is why do we use a DblClick (double-click) for the list box, instead of a Click as in the CommandButton? Apart from letting you use more than one type of Method and event handler, the ListBox only responds to single clicks (Click) if there is something in the listbox to click on. Otherwise it only responds to DblClick events. (We'll talk more about Events in the next article).

Now for the simplification (believe me it is). Look at the Main subroutine. It calls two subroutines which "make" or "setup" things. Specifically, the methods set up parts of the user interface. What we can do is factor (like in math...remove the common bits) that code out into a separate subroutine, and replace it with a single call to a subroutine in Main. Like this:

SUB Main 		

   SetupUI  ' call a routine to setup our User Interface 

END SUB

So we replaced two lines of code (which did similar things...namely setting up parts of the User Interface) with a single line of code. That's simplified it. But what is this thing called "SetupUI"? It's a call to a new method we write using the lines we took out! Like this:

'   A subroutine to set up all the bits of our user interface (controls). 

SUB SetupUI 	

   MakeAListBox  ' create a ListBox 	

   MakeACommandButton ' create a CommandButton	 

END SUB 

 So our new (simplified) program now looks like: 

'---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 subroutine to create a CommandButton on the screen          

SUB MakeACommandButton 	

    ADDOBJECT "CommandButton","MyCommandButton",50,75,100,50 ' create a CommandButton named MyCommandButton  

END SUB   

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

SUB MyListBox_DblClick 	

   MyListBox.Hide ' Hide MyListBox 		

END SUB  

' A SUB to handle a Click Event (a Click event handler) for the CommandButton called "MyCommandButton" 

SUB MyComandButton_Click 	

   MyListBox.Show  ' Show the ListBox "MyListBox" when the user clicks "MyCommandButton" 	

END SUB   

'   A subroutine to set up all the bits of our user interface (controls). 

SUB SetupU

   MakeAListBox  		' create a ListBox
   MakeACommandButton ' create a CommandButton 

END SUB   

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

SUB Main 	

   SetupUI   ' set up our controls 		

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

'---end code here---

You may be shaking your head at this point, totally confused. How is this simpler? Right now, it looks like we've added more code and made things more complex. True we've added more code. It's false that it's more complex. The code is easier to follow, easier to understand, we know now that those two lines that we "factored out" set up our user interface, because our Main now tells us that it does. (SetupUI tells you exactly what those lines do, whereas the individual lines may be doing something else such as modifying the user interface, instead of just setting it up). Also, this is a very simple program, as you write more complex programs, you'll be putting all sorts of stuff into your Main subroutine, which would confuse any other reader (and you) about what exactly those line do.

Factoring is a common computer programming concept. It tries to replace code with a common function, with a single subroutine (or function) call, to make the code more understandable. The other reason for factoring is that it makes the factored lines (those two lines in our example) reusable. If you ever needed to set up your user interface more than once in the program you'd only have to write:

...
SetupUI
...
SetupUI
....

instead of:

...
MakeAListBox  ' create a ListBox
MakeACommandButton ' create a CommandButton
...
MakeAListBox  ' create a ListBox
MakeACommandButton ' create a CommandButton
....

Which you have to admit is a lot less typing. Factoring is a "good thing", to steal a phrase. Byte-sized chunks are easier to digest than pages of commands.

Ok...our little program doesn't do much and it really looks kind of pitiful. Our list is empty and our button looks kind of drab and not really like a button. We're going to change our program (it'll still be pitiful, but it won't look as drab.) keeping all we've gone over in mind.

CommandButtons

The CommandButton we've used is one of the two user interface controls (commonly known as widgets) you'll use most frequently. We'll start our in-depth tour of widgets with the CommandBox, and go right into the other most frequentlyused widget, the MSGBOX.

Referring to the NSBasic manual (and proven by our little program earlier), you create a CommandButton the same way you created the ListBox. The only difference in the command was that "CommandButton" followed the key word ADDOBJECT instead of "ListBox". So, from this we can see that NSBasic has a nice consistent way of creating objects. They all follow the same pattern:

ADDOBJECT "the type of object","the name you give your object", xpos, ypos, width,height

Some objects require all these pieces (such as CommandButton) while others only require some of them, but basically if you know how to create one object you know them all. The differences lie in the Events, Methods, and Properties of each object.

A CommandButton, is a simple button, that the user clicks on to get something to happen. It has some text (a label) that describes what the button does. You can change its colors and the style of the text in the label. It's a fairly simple, but very flexible object.

One thing you should be aware of is that if you look at the CommandButton page of the manual, the Properties, Methods, and Events section of the page refer you to other pages. These pages describe each of the corresponding items, and the values that you can set them to. For instance, the BackColor of a CommandButton (the color of the background--that is, the button face color) can be set to a Color...which in turn is explained on yet another page. After a while you'll remember what goes with what thing. But at first, you'll have to do a fair amount of cross-referencing. Just look up the pages Properties, Events, or Methods as needed.

Ok, back to CommandButtons. Let's give our CommandButton in our example program a title. How do we do this? Well, a CommandButton has a Property (remember this is a characteristic of the object) called Caption. And let's make the button say "Hello" on its face. Again, we refer to properties using the dot "." notation. So we would write:

MyCommandButton.Caption = "Hello"

(Remember to put words that are visible to the user, like the caption in quotes--"Hello" instead of Hello.)

Where do we put this line? Well, it's part of creating our button so put it in the bit of code that creates our button, namely "MakeACommandButton"

' A subroutine to create a CommandButton on the screen 

SUB MakeACommandButton 	

   ADDOBJECT "CommandButton","MyCommandButton",50,75,100,50   ' create a CommandButton named MyCommandButton 	MyCommandButton.Caption = "Hello" 

END SUB

Make this change to your program and rerun it. Your button now has as caption! It looks much more like a real button now. We can make the text in the caption standout, by using the FontBold property. (A Font in computer-talk is the shape of the family of letters or text being used to write with. That is, the shape when you ignore things like underlines, italics, and bold, etc.) When you cross-reference FontBold you find it's set to True/False (something known as a Boolean in computerspeak). So if we set it to True, then the text in the caption should be highlighted. Add the line to MakeACommandButton again. I'll wait for you to do it....back? Good. This is what the line looks like:

MyCommandButton.FontBold = True

When you rerun the program you see the caption is darker and stands out now. Take some time now, and play with all the other Properties of a CommandButton. Try different values for them to see their effect on your single button. A lot of these Properties are common to other objects, so if you experiment with them on the CommandButton, you'll know what they do and how to use them in other Objects.

For the time being ignore Properties labelled as (read-only) in the manual. We don't have enough programming yet under our belts to deal with read-only properties.

Onward!

A CommandButton only handles two Events (Methods you can call): Click and GotFocus. We've seen and worked with Click already; this is the Event that triggers your Click event handler method. GotFocus is a bit harder to explain. In simplest terms, GotFocus means the object has been selected (not clicked) but selected. Typically, you move the focus (selection) around by using the Tab button on the keyboard. It moves the selection (highlighting) around from object to object as you hit Tab. You can then hit the Enter key (or the Casio's Action Wheel) to generate a "click" event on that button or control that has "GotFocus". What the GotFocus event handler lets you do, is let you execute some commands whenever the object (CommandButton in this case) gets highlighted. For instance, maybe you have a message come up like a tool-tip (help bubble) whenever someone selects or highlights your button. You could do that in your GotFocus event handler (since NSBasic doesn't support tooltips).

CommandButton Methods include two that we've played with already: Hide and Show. In addition there is something called "SetFocus" you can call this method (MyCommandButton.SetFocus) to highlight the button (and consequently generate a GotFocus event, which would cause your MyCommandButton_GotFocus method to run.) Phew! Now we see some of the power of Objects! Some methods can create secondary events: Doing a SetFocus causes a GotFocus event to be created which causes your GotFocus event handler (method/subroutine) to run. Take a deep breath and reread what we've done so far. It's a lot to digest, and once you understand (or at least feel comfortable with) all this, you're on the road to being a programmer!

The last metthod a CommandButton deals with is Move. This lets you Move the button from your program--that is, alter where it sits depending on something else. Lets move our button to the right 5 units each time the user taps (Clicks) on it. Cross-referencing Move we see it takes similar values to the actual creation command...so in essence we're reacreating our button somewhere else on the screen. This should be simple then, and it is, but we haven't gone over a crucial part of programming yet, namely something known as "parameters" or "parameter passing". We'll leave this for another time.

That's all there really is to CommandButtons (and lots of other Objects) in NSBasic.

To get you used to using CommandButtons, I want you to write a program for next time.

The program should have:

1. Four command buttons.
2. Each button should have a different label: Bold, Italic, Underline, and Normal

The program should:

1. Start with all captions in the default style (not Bold, Underlined, or Italic)
2. When you hit the button that says "Bold" the label style should go bold (stand out)
3. When you hit the button that says "Italic" the label style should switch to italics
4. When you hit the button that says "Underline" the label style should underline
5. When you hit the button that says "Nomal" all label styles should go normal (the default) and undo everything else.
6. No button should affect any other button except for the "Normal" button which affects all the others.
7. Use factoring.

It's not that hard really. Take is slow and if you get stuck reread the sections of the article that explain what you're stuck on. Check for typos, and use double-quotes! We'll go over the answer next time, and we'll finally explain what a SUBroutine really is, and get our first explanation and use of FUNCTIONs. We'll also go over our next Object, the MSGBOX.

If you get stuck or have a question about anything we've gone over, feel free to email me at Serg@VisualNewt.com

Cheers!