Even with machine configurations where tricks such as the above work, we have no choice but to put up with what happens on our monitor. That string is intercepted by the operating system. Windows slam-dunks your program out of sight because it has to switch the screen from "console mode" so that it can show you the dialog box associated with your printer.
Afterwards, after whatever happens or doesn't happen , there you sit with a blank look on your face: It is up to you restore your console-mode screen by clicking on your GW-BASIC job down in the "system tray" at the bottom of the screen.
To a certain extent, the above may be a tolerable scheme when doing LLIST of many lines of a program. The second case, however, presents a relatively easy opportunity.
Maybe, that is, assuming that all output is in fact text-type data. Another consideration is whether an application treats printed output as a batch or it spits out little chunks on an interactive basis.
Report writing programs typically generate their output as a steady stream from start to finish. Interactive programs are like those for POS jobs that print lines one at a time as a cashier enters each item. Programs that are batch oriented can usually be made to work on Windows machines. Those that do stop-and-go printing will most likely be intolerable in a Windows environment.
The above point needs to be reiterated: If an application wants to print lines one at a time, do not blame Windows or GW-BASIC if you are trying to do it on the wrong kind of printer. In fact, the same problem can occur in other languages. Modern ink jet printers are page printers, not line printers. Another critical aspect can be whether a program outputs "control codes. For a different kind of printer, it is nearly impossible to predict what will happen if you send it codes like this.
That has always been true, by the way. Most control codes are make and model specific; rarely do the same codes produce similar results on different printers. On a Windows machine with a modern printer, code sequences such as the above may produce some really funny results. Caveat, and remember that such problems might be your fault because you are sending geek to a device that doesn't speak geek. Send all desired output to a disk file, then later, open that file with Notepad or a similar program to send it to a printer.
An advantage to this modus operandi is in being able to do fancy formatting on the screen before committing it to paper. Even columns of figures and such will not often come out aligned as desired. In some cases, it may help to condition a word processing program to use "Terminal" font.
Like I said, attitude is one key to solving these problems. Valium and Tylenol may help too, gee whiz. DOS rules apply here, not Windows. Thus, file names cannot be more than eight characters, followed by a dot period , followed by not more than three characters.
No name may contain any spaces anywhere. Although it is also possible to include characters from the "upper " of the old "Standard PC Character" set, those for drawing boxes, for example, will NOT look the same in Windows displays of folders and files.
Moreover, other weird things can happen to uninformed users. BAS because any code from the set will be shown as an underscore. Not only is this mind-boggling, such names would also look like one that really does have an underscore character in the same position. Now, since we all know you cannot have two names exactly alike in any one folder, this sort of nonsense can really blow your mind.
Another one is the oddity that may seem craziest of all: Files with names containing "invisible characters" from the set CANNOT be deleted by Windows programs regardless of their attribute settings. If you get a Windows error , suppose immediately that this is why. If you do not know the exact character code in the offending position, simply substitute a question mark in the corresponding position during DEL or KILL. Caveat: Use of wild cards will affect ALL files having similar names. As has always been true, upper and lower case letters in file names may or may not be significant.
In fact, DOS always displays all letters as upper case, even if some are lower case in the disk directory itself. Windows, on the other hand, will normally display the truth, so to speak. Even so, even when it displays mixed upper and lower case letters as such it is fibbing just a little. Like DOS, Windows also treats all letters as upper case for all file-referencing purposes. This can be an especially mean stunt when you are inclined to use the same name for both a program and a data file.
To keep me from hurting myself, my habit is to always specify extensions on data file names such as dot-DAT, for example. Although the option of adding a comma-A after a SAVE command will cause the same program to be written to disk as a text file, it too will have a dot-BAS extension unless you specify otherwise. Today's computers are so fast we no longer have to worry so much about how long it will take to do something.
Interpret my meaning as, less brain strain is needed to ensure our coding is as optimum as possible. Not covered there, however, are two problems that can arise in the Wonderful World of Windows that we never had to worry about on old DOS machines.
One of them has to do with shared files. Or rather, NOT shared files would be a more apt expression. EXE running. To do so is really living on the edge--the dangerous edge, that is. Once I have a general understanding of those concepts, I can usually figure out the rest on my own. Most programming languages have some similarities, so once you know one programming language, learning the next one is a matter of figuring out the unique details and recognizing the differences.
To help me practice a new programming language, I like to write a few test programs. One sample program I often write is a simple "guess the number" game, where the computer picks a number between one and and asks me to guess it. The program loops until I guess correctly. My "guess the number" program first prompts the user to enter a random number seed, then generates a random number between 1 and The RND 1 function actually generates a random value between 0 and 1 actually 0.
Adding 1 gives a number that's between 1 and The program then enters a simple loop where it prompts the user for a guess. If the guess is too low or too high, the program lets the user know to adjust their guess. The loop continues as long as the user's guess is not the same as the random number picked earlier. We can run the program by tapping the F2 key. Using a random seed of generates a completely new random number.
It took me six guesses to figure out the secret number was Thanks to Microsoft for releasing this great piece of history as open source software, and thanks also to the many open source developers who assembled GW-BASIC so we can run it. Image by :. Get the highlights in your inbox every week.
Get started with FreeDOS. A variable is what you create to represent some other value. Think of them as containers that can hold many values. For example, if I use the variable X, I can put many values into it.
In fact very few programmers bother with the LET statement Many programmers have yet to discover that you can use more than 2 fingers at a time on the keyboard, so they tend to be brief. However, be careful!
In this case, One of the advantages of an interpreter is that it can give you an immediate response without running a program. You don't need special commands to use this mode, just don't use line numbers. Thus if you typed the initial line of our program, the interpreter would respond: Hello there Note that the quotes have disappeared. One use you can make of this feature is as a calculator. If you type any mathmatical expression, the interpreter will give you an answer.
Notice, particularly, that the order of interpretation depends on both the operator and any parentheses. This is called precedence. Basic also uses some defaults to describe whether a variable is a string, integer or real number.
You could also define specific variables to be strings or integers, but that starts to get confusing, so I use the convention that all variables are integers unless otherwise indicated. Now let's see how this works in a program. You should always try to predict what your program is going to do. Remembering that prediction will help when it does something you didn't anticipate.
Experiment with various combinations of arithmetic operations, until you can predict what the results will be. In particular, try examples which mix multiplication and addition. What is the effect of using parentheses? Use assignment statements to hold intermediate results. This time, we'll introduce the concept of branching and program control.
In the next few installments we'll add loops, color, sound and arrays. At that point you'll be well equipped to start writing actual programs. The compiler doesn't need line numbers, and you can skip them entirely, so most of these commands aren't needed. Compilers have direct commands for printing a file usually under the FILE menu item.
I'll continue to use line numbers in this tutorial, but my reason for doing so is that it's easier to discuss a program when I can refer to particular line numbers. For actual programs, I'll usually skip them. Structured programming is just a small part of the overall concept of structured design. The root concept is to build a program from the top down. It also discards the concept of flow charts. Here's the reason: Flow charts are unnecessarily detailed.
By the time you break a problem down to flow chart level, you can usually write the code directly. They're so detailed, that few programmers go back and change them when the program changes, so flow charts are usually out of date as soon as they're written. Structured programming does use diagramming techniques, but for our purposes we'll be able to use pseudocode for all our designs. We approach the problem by defining what we want to do at a very high level.
For example, to create a checkbook balancer, we might outline the following steps: Enter initial balance Add deposits Subtract checks Show final balance Quit Now we can elaborate this to describe each step in more detail: Enter initial balance Add deposits -- ask user if there are any more deposits -- if there are then get the next deposit add that amount to the balance In some cases, we could write the Basic code directly, so there's no need for further refinement.
Now, we're ready to write the actual code. Using this structured, top down approach any problems become apparent from the start. This text based way of describing a program is termed pseudocode, because it's simpler than English, but not rigorous enough to feed to the computer. It forms a useful link between human and computer.
Well written pseudocode is easily converted to any language, and forms an outline of the program. It also suggests a preliminary set of comments. Using only these 3 constructs, any possible program can be written. Try substituting these operations in the fragment above to see their effects. The IF statement evaluates a conditional statement and then follows one of several paths. This says that you want to do something only if the conditional is true, and you have no other statements to process.
Since the interpreted Basic IF statement must all fit on one line, we can also use an expanded form when we have several things that we want the statement to perform. As we learn more about Basic, the exercises will suggest ways you can return to this example to flesh it out.
For now, try running this program and follow its operation. The example programs are included in the tutorial package in a ready to run fashion. You can also clip out segments of code from this tutorial and edit them.
The compiler doesn't limit us this way, so we can construct statements without ever using GOTO's. One of the goals of structured programming is to make programs that are easy to modify and maintain in the future.
To this end, you should include a header at the top of each program that describes what it does, and most important, when it was last modified and by whom. Then in writing the program, use comments wherever they help to explain the flow of the program. Comments are ignored by the Basic interpreter and the compiler. They're indicated by either the word REM or more commonly, the apostrophe '.
Comments starting with ' may be either the first or last elements on a line. This allows short comments to be placed more precisely. Combined with a standard indentation comments make the program structure more readable. For example, I indent any statements after an IF statement. I also indent any GOTO that starts a statement.
In this way you can see that the statements are dependent on the IF statement and that the control is passed by the GOTO. You'll probably encounter any variants of indenting.
The important thing is to be consistent. Remember, though, that indenting is solely for the human reader's benefit. The computer acts on what it reads, not how it's formatted. Improper statements will not improve because of indenting. If condition A is false, then only statement 3 is executed and condition B isn't even checked. It adds a question mark and then waits for the user to enter an answer and hit the enter key.
INPUT is simple to use, but does have some drawbacks. Try entering some non-numeric characters. INPUT recognizes illegal characters, but its response is less than elegant. Later we'll see some better ways for handling data input. After the balance is entered, we enter the main loop of the program.
The user indicates what type of transaction comes next. Note that we've changed the structure of our program so that the user can enter deposits and checks in any order. This is much friendlier since the user only needs to press one key each time. Since we don't care whether the user enters an upper or lower case letter, we shouldn't penalize them. Thus we'll allow either when we check. Lines , and check to see if the value entered is not equal to one of the valid codes.
At any stage, if we find a match, we do the appropriate processing, then go back to get the next transaction. One last suggestion on GOTO's. Do not jump up in the program, unless absolutely necessary.
That is, in reading a program, the normal flow should be downwards. One exception would be a loop such as we have here. Line 90 starts the loop, and at the end of each transaction we return to it. In addition, we've already seen some of the elements of designing user friendly programs.
Add a third option that allows the user to enter a monthly service fee. Decide on a code, and add a new transaction that subtracts the fee.
Be sure to change the prompt line to show this new code. The current program just ignores bad codes. Add a message line that tells the user that they've entered a bad code, then asks them to reenter their choice. Assume that any number greater than is an error. Add an extra check to both the deposit and check section that prevents these numbers from being included. You should print an error message and then go back to the transaction code input line without making any changes to the balance.
Only positive numbers are valid for input. Check that each number entered is greater than 0 before allowing it. This time, we'll add more structured loops, color and sound. In the following section, we'll look at arrays and data statements. This is discouraged by purists and for good reason.
It's too easy to write spaghetti code with meatball logic that jumps all over. This makes it difficult for anyone else to read or understand your code. It's even hard to read your own code after a week or two. The first number is the initial value, the second is the final one. You can also use the STEP command to move by more than one. These loops can be nested as shown in the following example.
Note that the last FOR started must be the first one finished. The semicolon ensures that all 5 products are printed on a single line. The value of X never changes, so the loop repeats forever.
If you're testing and the program just wanders off and never comes back, infinite loops are prime suspects.
WHILE's can handle loops when the ending conditions are unclear. RND is a Basic function that returns a random number between 0 and 1. Since dice have no 0's we add one to it. Here the while statement has 2 possible ways to end.
Either the die rolls a 6, or the total points becomes 20 or greater. If the loop ends with a die roll of 6, then all points are lost. Allow an unlimited number of points to be accumulated. Don't use any GOTO's in your solution. There are 8 colors, with 4 possibilities for each color, defined as follows: "dark" "light" dark, blinking light,blinking black 0 8 16 24 blue 1 9 17 25 green 2 10 18 26 cyan 3 11 19 27 red 4 12 20 28 magenta 5 13 21 29 brown 6 14 22 30 white 7 15 23 31 On the CGA you can have any of the 32 colors as a foreground color.
This is the color that letters and other characters will use. You can also set any of the 8 colors as a background color. This allows reverse video effects. Try the following: 10 color 7,0 20 print "try me" 30 color 0,7 40 print "try me" 50 color 15,1 60 print "try me" 70 color 31,1 80 print "try me" The program included on the disk, COLORS. BAS gives a more extensive display of the color range. First it reproduces the table above, but using actual colors for the numbers. Then it shows all combinations of foreground and background.
Note that if foreground and background are the same, the letters can't be read. Color can be easily abused. Clashing colors or too many colors distract rather than attract. Try to avoid using flashing messages for all but the most important warnings. In particular, don't use flashing colors for input messages.
They are difficult to read. Use colors which are easy to read, with the more garish colors saved for special cases. The most readable color combinations on most displays are: bright white on blue bright yellow on blue bright white on red useful for error messages bright yellow on red " " " " bright white on black black on white bright green on black bright yellow on black bright indicates either light or dark is ok.
We'll use colors more later when we look at more of the graphics commands. For now, try the following problem: [ If a Debit is chosen, change color to bright yellow on blue. If a Credit is chosen, change color to bright white on blue. If the user makes a mistake, change to bright yellow on red. Remember to change back to the original setting after each special color.
SOUND is easier to learn, but harder to use effectively. Instead it's useful for sirens and other sound effects. Different CPU speed may affect these sounds, so they are not generally recommended. Most compilers have a timer function that allows you to delay a set amount of time. PLAY has a more complex syntax.
I'll briefly introduce it here. The best way to learn this command is to practise using it in various ways. PLAY requires a string that uses Microsoft's music command language. Some of the commands are: A-G with optional or -, play the notes A-G with sharps or flats.
O n sets the octave. An octave goes from C to B. N x plays note x, from 0 to This is an alternative to using the notes and octaves, but is less useful if you're transcribing from musical notation.
L n sets the length of the note. Can range from 1 to Any value, can be played, even 23rd notes! P n pauses for length n. For example Largo is , Adagio is , Allegro is To play a sequence, you just construct a string and give it to PLAY. Then we play this sequence of notes at tempo , using eighth notes in octave 2.
We pause for a quarter note's time, then move up an octave, change to sixteenth notes and repeat the phrase. Note that I've used an alternate way of designating the length in line Using the cursor movement keys, any line displayed on screen can be edited. It also contains function key shortcuts at the bottom of the screen. All tool lines must be numbered; all non-numbered lines are considered to be commands in direct mode to be executed immediately.
Tool source files are normally saved in binary compressed format with tokens replacing commands, with an option to save in ASCII text form. The default kind for undeclared variables not identified by such typing statements, is single-precision floating point bit MBF.
Visual Basic 6. Aurel Basic is simple programming tool wich is made for beginers in programing world. He is dialect of BASIC , and like other basic languages he share his simple sintax and philosophie of programming.
This software is oriented to learn basics for. Note: The software listed is limited to software installed with the Windows Installer.
0コメント