Previous page Previous     TOC Contents     Next pageNext


LESSON 6 - Menu and Debug



Creating a Menu

No! Not a restaurant menu.

If you've worked with Windows applications before you have worked with menus. Every Windows application has one.





The menu gives the users access to functions that are not defined as controls (editing, formatting, etc) and also repeats certain functions that are coded as controls (Exit button, for example). Menus offer a variety of functionalities to define the application: we can include sub-menus, checked items, enabled/disabled functions, toolbar icons. The VB IDE that you are using certainly displays all of those tools, as in the diagram below.








For this lesson, we will use the Registration form we created in Lesson 5 and we will add a menu to it.

The easiest way to create a menu is to do it with the Application wizard when creating the application. But since we're not here to do things the easy way, we'll have to rough-it. In this case, roughing-it is not much harder. We use the Menu Editor that can be found in the Menu bar --> Tools. Using the Editor is fairly obvious. We just build up the menu bar on the first level and then, we add sub-menus using the arrow keys to add an elipsis before the captions. Thus, &File is on the menu bar and ...&Open is under &File. Items can be inserted anywhere using the Insert button.

You may have noticed the use of the ampersand (&) in the captions (the Caption is the part that will display in the menu bar, not the name). That is standard Windows practice. It creates a Hot-key, meaning a function that can be called from the keyboard using the <Alt> key. Putting an & before a letter in a caption makes that letter the hot-key for the function; <Alt><F> will call-up File, <Alt><E> will call-up Edit, and so on. Just make sure that the same hot-key is not used for 2 functions on the same level. In the menu bar for VB above, note that <Alt><F> is used for File but, <Alt><o> is used for Format. The hot-key for each function is the letter underlined so there should'nt be any confusion.

The other consideration when creating the menu is to give each menu item a specific name. In this case we use the prefix mnu_ to identify menu items. These are important because they will be refered to in code and it should be clear that mnu_exit is the Exit function in the menu whereas cb_exit is the Exit command button.



You can run the application at any time while you create the menu, just to verify that it displays correctly. Of course, if you click on a menu item, nothing happens. Just like controls, menu items have to be coded to work. So, we go to the code window and write the code for each of the menu items that we want to activate. Fortunately, some of it is automatic. Clicking on a menu item will automatically open lower-level items, if there are any. We just code for the lowest-level item. For example, for File-->Open-->Viewer, there is no code for File, nor for Open but, we must write the code to execute for when Viewer is clicked.

For this example we will code a few simple operations to show how it is done. From this it is just a question of expanding the menu to display more functions.



When working with forms, there is always a certain amount of data validation that has to be done. Data validation consists of making sure the data is correct before doing calculations and so on. Usually, until the data is all correct certain functions such as calling the database or going to the next form have to be made unavailable - we say that the function is disabled.

To complete the example, let's say that we want to disable the Viewer option if the player's name has not been entered. To do this we add some code in the Go button. The code consists of setting the Enabled property to False if we want to disable a control or menu item; we set the property to True to enable the control again. When disabled, the Caption goes gray and the code cannot be executed. In the case of Viewer, where we have both a button and a menu function, we must remember to disable both.










Debugging code

After six lessons of this tutorial, it would be surprising if you had never had a bug in the code you've been writing. By now you should have written some original code for yourself, not just the examples supplied with the lessons. Whenever you write code there is the possibility of making mistakes. Heck! even Professors make them, although very rarely. It can be very frustrating to try to find an error when you don't know where to begin to look. But there are techniques that can help.

Do you know where the term "bug", for a program error, comes from? In case you've never heard the story before, here it is, as told by Grace Hopper, one of the pionneers of programming.
In the late 40's even a simple computer was a big thing: 1000's of vacuum tubes and 1000's of square feet of floor space. A group of programmers were working late one hot summer night. To help to dissipate all the heat generated by those tubes, all the windows were open. At one point the program that they were working on bombed-out. Eventually they found the problem: a moth had flown in and had become lodged in the wiring, creating a short-circuit. Afterwards, every time a program would crash the programmer would exclaim, "There must be a bug in the machine!". To this day that has remained one of the mainstays of programmers: when the program goes wrong, blame the hardware! 


One of the first techniques to master is the use of breakpoints. A breakpoint is a flag at a given point in code where program execution will be suspended to give you time to look at the content of variables or at the status of properties. When VB hits a breakpoint when running a program, the code window opens and an immediate window opens at the bottom of the screen. You can look at variables or properties in the immediate window and then, either do Start to resume execution or do Step, using <F8> to step through the execution, one statement at a time.

Again we will use the code from Lesson 5. In the code window, click the column to the left of a line of code. This will create a breakpoint indicated by a red dot (you remove the breakpoint by clicking on the red dot). When you run the program it will stop at the breakpoint. In the immediate window, look at the content of different variables or properties. Step through the code with <F8>; the active statement is indicated by the yellow arrow. All the logic represented by IF or LOOP or DO statements will be executed according to the conditions present. If the yellow arrow jumps to a line that you don't expect, find the reason why.



Another technique to learn is called "error trapping". It consists in intercepting errors that can occur at execution rather than programming mistakes, although not providing for user errors can be considered a programming mistake.


Let's build a simple example. The user will input 2 numbers, a numerator and a denominator. The program will divide the numerator by the denominator and display the result. Easy so far. However, if the user inputs 0 for the denominator, the program crashes because programming cannot make sense of division by zero. So, we want to trap the error and process it before it displays an error message to the user. We will use the On Error GoTo ... statement. This tells the program that if there is some kind of run-time error, go to the error-processing-routine named. We have to create a line label to identify the error routine; a line label has a colon at the end, like error_rtn:, in the example. At the same time, there is an Err object created and it contains, among other things, a Number property that will identify the error. For example, if Err.Number = 11, the error was a division by zero; Err.Number = 6 represents an overflow situation.




It is worth noting that line labels in code do not end processing in any way. When the logic gets to a line label it keeps on going. The programmer has to make sure that the processing of errors in the error_rtn is not done automatically every cycle (that is called "falling through" the next routine and it's a common error).







If you haven't found the Visual Basic resource you're looking for,
use our Google Search box for more information.

Google