Write a program that does something practical, yet illustrates good programming techniques. Avoid any graphics and use of the RND function.

How about a checkbook program? One enters date, amount, check number, payee and remark. One also enters deposits, void checks, and cash withdrawals (no check). Internal files will keep all amounts in pennies to make calculations accurate.

To get started, write some programs to debug critical subroutines. Example

DECLARE FUNCTION CashIn& ()
CLS
PRINT "Debugging the cash input subroutine": LOCATE 5, 1
DO
  W& = CashIn&
  PRINT "You entered "; W&: PRINT : PRINT
  PRINT "Enter space to try again, anything else to stop ";
  DO: k$ = INKEY$: LOOP WHILE k$ = "": PRINT k$
LOOP WHILE k$ = " "
SYSTEM

FUNCTION CashIn&
LINE INPUT "Amount"; A$
CashIn& = 100 * VAL(A$)
END FUNCTION

Now you might think "Why debug such a simple subroutine?"

That's because that subroutine is not NEARLY finished. You need to handle errors. Suppose the user enters "$123" or "xxx" or "1.2345" or just null?  "Will you support "1,234.55" or will you make the user enter "1234.55"?

The reason I used LINE INPUT is to make recovery from user input of comma easy.

I estimate you could spend your first day on this subroutine alone to do a good job.

Now since everything is in pennies, you need a subroutine to convert this to a standard length field. This is not so complex since user errors need not be handled. It should be something like this:

DECLARE FUNCTION CashOut$ (CashIn&)
DECLARE FUNCTION CashIn& ()
CLS
PRINT "Debugging the cash output subroutine": LOCATE 5, 1
DO
  INPUT "Amount to print"; a&
  PRINT "The amount is |"; CashOut$(a&); "|": PRINT : PRINT
  PRINT "Enter space to try again, anything else to stop ";
  DO: k$ = INKEY$: LOOP WHILE k$ = "": PRINT k$
LOOP WHILE k$ = " "
SYSTEM

FUNCTION CashOut$ (CashIn&)
w$ = STR$(CashIn& / 100)
CashOut$ = RIGHT$(SPACE$(10) + w$, 10)
END FUNCTION
Whoa, you say. At least this should be easy. In fact it is already done.

Wrong. There are lots of things to work on. Do you put commas in the output? Does zero print as "0.00"?

Nope, here you can spend another day.

And you are not done yet with these two. I didn't provide for negative numbers. What if the user overdraws the account. The balance will be negative. Print this: 1,234.56-.

Maybe your next critical subroutine is the date subroutine. You want to start with a default of today's date but allow the user to change it easily. And keep the users new date as the default for the next transaction: he may be entering several checks written on the same day. Etc. Etc.

Finally, when your critical subroutines are debugged, use them and write your main program.

Have fun

> How about a checkbook program?

Yes, I can see it now! Just imagine a 14 year old kid sitting behind his parent's computer who is thinking: "Wow! A Checkbook program! What a great idea! Why was I even considering making an action game, when I can make an exciting checkbook program. All my classmates will be so impressed!"
Tell me, how many 12-16 year olds do you know who think a checkbook program is usefull?

I'm sure this was pretty impressive stuff in the fifties when you learned to program, but times have changed. Programming is no longer a matter of scribbling a few flowcharts on a napkin and have a lovely punch typist work it out for you. Today it is about showing everyone what a cool 'cyberpunk' you are.

> Avoid any graphics and use of the RND function.

Why is it that everyone considers graphics as advanced programming? I think people should START with that! A simple program producing pretty picture can be much more rewarding than a program that shows a few numbers on the screen, no matter how well programmed.

Many kids today learn maths and programming with the programming language LOGO, which is very easy to learn, and easily produces fascinating designs. And it teaches them structured programming and thinking in algorithms. And with my LOGO functions you can use the same techniques in QBasic as well: http://www.network54.com/Hide/Forum/message?forumid=171757&messageid=1011671516

> That's because that subroutine is not NEARLY
> finished. You need to handle errors. Suppose the
> user enters "$123" or "xxx" or "1.2345" or just
> null? "Will you support "1,234.55" or will you make
> the user enter "1234.55"?

And don't forget the people who use decimal commas! A good routine will allow at least the following ways of entering numbers: use of both decimal commas or points, use of comma's or points or spaces to seperate multiples of a thousand. (Official international use: decimal commas and narrow spaces. When is Microsoft ever going to come up with a keyboard with a narrow space button?)

> I estimate you could spend your first day on this
> subroutine alone to do a good job.

Yep, you've successfully lost any newbie under the age of 50(0?) now! ;-)

> Nope, here you can spend another day.

"How could I even consider wasting my day on playing Tomb Raider 6, when I can write such an thrilling subroutine!"

> And you are not done yet with these two.

Whoa! There is even MORE? ;-)

> Maybe your next critical subroutine is the date
> subroutine. You want to start with a default of
> today's date but allow the user to change it easily.
> And keep the users new date as the default for
> the next transaction: he may be entering several
> checks written on the same day. Etc. Etc.

And don't forget the program needs to be year 10 000 compliant, allow for dates entered in the form Day-Month-Year as well as Month-Day-Year (or else the Americans get confused) and it is best to store the date as a Julian Date so it easier to calculate with. Don't forget support for the Jewish and Islamic Calendar! ;-)

> Have fun

I'm having a blast! Your post is incredibly funny even if you didn't intend to. ;-)

And I mean that. One thing, if the user insists upon commas, use this code:
INPUT A, B
A = A + B
B = 0
You see?

INPUT A, B
A = A + B
B = 0

How can that work?
Suppose someone wants to type in 1,5 (one and a half).
The program then gets to the second line, and basically does this:
A = 1 + 5
Now A is 6 isn't? Not 1.5!

Making a program that allows decimal comma's as input would be quite difficult. You must LINE INPUT the numbers in as strings and change the comma's into points, and then use VAL to extract the number.
A bit more complicated, but you can do it. And using LINE INPUT to ask for the numbers as strings is preferable anyway, because it allows you to test whether the user really typed in a number and not a few letters. That way you avoid the dreadfull 'Redo from Start'.

Could you explain this in a lot more detail?

Why would a user insist on commas?

Please give some sample user input as input by the user and as interpreted by the program.

I fear you are mixed up here, but want to understand if you are not.

Thanks, Mac

Second, in case you haven't noticed, but in most countries outside the US, people use comma's instead of points to seperate the decimals from the units. It's a bit like using the word billion for a million million. It's the official use as defined by international scientific standards. Like anyone ever obeys them fully...

Even Windows has the option to change the decimal point to a decimal comma. So it isn't that weird. Some people might really prefer typing in comma's.

So 1,5 in Europe = 1.5 in USA
When the user types 3,141925 the computer should interpret it as 3.141925

Easy huh? The comma just changes to a point (because QBasic doesn't follow the international standards) and if the user desires it will change the point in the output to a comma.

If you mean that Iain is mixed up, then: yes you are right. I guess he just doesn't understand the difference between a decimal comma and a plus sign. Makes me wonder what he will make of your program idea...

INPUT A, B
'SINCE THIS IS A MONEY PROGRAM, THE ONLY REQUIRED
'DECIMALS ARE AFTER THE DECIMAL POINT
B = B / 100 'GIVES A DECIMAL
B = A + B
A = 0
DO WHATEVER TO A

so if the user enters 1,50


then the 50 would become .5
1 + .5 = 1.5

so you see?

that could will only work if you know for a fact the user will 100% for sure use a decimal comma. the thing is this, you simply need one single routine to test how it was entered and convert it to american decimal points if necessary. yeah, i suppose it's evil of me to end this reply without putting the code in myself, but it's been a long day and i'm not in the mood to think, even if it is simple.

then it will be like this:
1.5 + .00

0 / 100 = .00 or 0
see?

that if you code

INPUT "Enter dollar amount: $",Dollars, Cents

and at the prompt the user inputs

Enter dollar amount: $5.45

qbasic will respond with

Redo from start

which can not, as far as I know, be trapped with an error routine.

KN

Well, you make a setup file, then in the setup file create a .txt file, and then ask the user which type of decimal will be used, then use an IF THEN to see which decimal the user uses. :)

1) First of all, ALL inputs should be strings, as they are in Visual Basic, so you never get a "Redo from start" error. The following may be coded into a subprocedure.

2) Use INSTR() to check how many commas there are and whether the last (and only) comma is followed by two or three characters. If it's 2 characters and only one comma, you know you have to convert that comma to a period and eliminate any of the extraneous periods. Otherwise, eliminate the commas.

3) Check if there is a $ on the left and eliminate it.

4) Check the LEN() of the remaining string. Convert the string to a number with VAL(). Convert back to a string with STR$() using a different variable and test with LEN() to confirm that the correct number of characters were converted (and no non-numeric characters are included).

Note: After converting back from a number to a string, the result should be one character longer if the number is positive because a space is added to the left of a positive number.

5) If the above test does not check out, then loop back to the input after notifying the user.