|
|
|
|
Any program has to have three elements. There may be complications, but these three elements must appear. The program must be able to accept input from the user. The program will elicit this information and then store it for later use. Then there will be manipulation of that information. The inputted values will be coddled, massaged and processed according to the goal of the programmer. Then there will be output; the results of the manipulations will be communicated to the user. VB accomplishes input and output through controls. Controls are the elements displayed in the toolbox at the left of the development screen. When you program, you drag the needed control onto the screen, where it will appear when the user runs the program. Some of the controls have the primary duty of calling for action, usually via a click. Most controls can display text assigned to them by the program. The Text Box control and Grid control can accept user input, as well as display output generated by the program. When the user types information into a text box control, for example, the program can be told to read and store that information. A crucial idea is that of a variable. The meaning is the same as in algebra; the program will call something by a generic label, while the user will be thinking of a specific instance. For example, the variable X could have a value of 5 during one execution of the program, and the value 10 during another. VB variable names must begin with a letter, and the optional subsequent characters can be any combination of letters and numbers. Thus A, A1, ANYTHING, and ANY14 are acceptable names, but 1ANY is not. VB interprets any of these names as numerical variables, and will assign to them whatever current value the program dictates. Alphabetic variable names are used to store non-numerical values, that is, values with letters in them. For example, USERNAME could be an alphabetic variable whose current value might be David when I run the program. The program would learn the value (David) via the input process. For semantic reasons I don't want to understand, VB's creators refer to alphabetic variables as string variables. A few variable names are illegal because they are words that VB has reserved for its own purposes. Some that I know about are ABS, DATE, GET, IF, LEN, LOOP, MOD, SET, and TYPE. If you try to use a reserved word as a variable, the compiler will interrupt you with the obscure error message "Expected: Identifier" and it will highlight the offending term. VB is very tolerant of differences in programmer's typing idiosyncrasies. I'll mention mine explicitly, because you may wish to adopt others (even though some of mine actually have reasons underlying them!). (1) I type programming words and variable names in all capitals, so that they're easy to distinguish from literal text. VB doesn't care; the jargon is that the language is case-insensitive. Text within quotes will appear on the screen exactly as I type it, so usually I use an ordinary mixture of upper and lower case. (2) I put each program statement on a separate line. Many programmers take advantage of VB's use of a colon as a separator, so that multiple statements may be placed on a single line if they are separated by a colon <:>. For example, one may type A = 5: A = A + 1:LABEL1.CAPTION = A The reason I don't save space in this way is that it is easier for me to find errors when the lines are individualized; I can peer into the workings of the program using VB's debugging aids more effectively to identify the offending statement. (3) I am somewhat erratic when it comes to indenting. VB does not care about spaces at the beginning of a program line. Sometimes it is easier for the programmer to follow the flow when associated lines are typed as a hanging paragraph. I do think indenting is a good idea, but in my personal programs I usually don't bother. (4) I use line numbers or line labels only when they are needed as addresses to control program flow. In the early versions of the BASIC language, each line was required to have a line number. Some compilers generated them automatically. My view is that optional line numbers just clutter up the program and I don't use them. Professional programmers don't like line numbers, preferring to control program flow with other methods. They refer to this approach as "structured programming" and disparage code filled with GOTO's as "spaghetti code". I think it's just snobbery; whatever works for you is OK with me. (5) VB allows special non-executed statements known as REMarks to be interspersed throughout a program. Any statement preceded by REM (or its alternative, <'>, the apostrophe) will be ignored during execution, though it displays during program listing. The idea is to help the programmer remember what a program line or segment is supposed to accomplish. Professional programmers claim to use them profusely. I suppose they're valuable for team-written programs, especially after a team member leaves the firm. I guess REM statements have to be recommended, but I confess I don't often put them in my own programs (I'll put some in where I think they might help you, though, and I'll color them green). Perhaps I'm too vain to admit I could forget why I wrote something. My concession to fading memory is to use very explicit variable names (in my youth, variables were X and Y and I always remembered what they stood for).
|
|
|