New, again, with BASIC

[Newbe]

A few comments here:

I realize I heavily used GOTO; I had even more, until someone pointed that out. Each of my GOTOs now goes to a different weight range to display the results. Then, as each weight range completes, it goes to compute the ideal weight. The ideal weight for a male or a female of the same height is not the same, so I had to jump to different computations for each gender. The introduction is the only part that returns to where it left. This is the logic I used for how I compute the BMI and the ideal weight.

Here's how I implemented it, using a normal BMI as an example:

After the intro and asking for weight and height:    IF bmi < 24.9 THEN GOTO normal

normal:
    After displaying BMI: "Next we will determine your ideal weight."
    GOTO ideal  'Compute Ideal weight

ideal:
     After determining gender, go to appropiate section to compute (women: or men:)
     After determining ideal weight for either gender, GOTO terminate

The full code for this program is attached to my February 08, 2013 post.

[Newbe]

I have started a website dedicated to QuickBasic 4.5. Have a peek at it.

http://quickbasic45.weebly.com/

John...

[Salmon Trout]

I see you include a link to a CH thread, which you call "my area on the forum". Isn't that a bit presumptuous?

[Geek-9pm]

Maybe he means this thread.

[Salmon Trout]

Maybe he means this thread.

Possibly, but it's stretching it a bit to call it "my area".

[Newbe]

Hey, a little slack please. I go by Newbe aka Greenhorn because I'm new here. At any rate, I changed "my area" to "my thread."

[Newbe]

Hey, a little slack please. I go by Newbe aka Greenhorn because I'm new here. At any rate, I changed "my area" to "my thread."

I see I've been upgraded to "Rookie."

[Newbe]

OK, here I am again with another endeavor. This time it's a program that asks a series of questions on mathematics and then calculates what percentage you got correct.

I originally wrote it in QB 45 and then tried it in QB 64; it worked just fine. I did have to add a _FULLSCREEN _STRETCH command at the beginning to get it full screen. (Linux 711 helped me on that.)

I'm hooked on QB 64 now that I have a better feel for it. The best part for me is that I can now work on a 64 bit machine with Win Vista and a 6.5" X 14" screen.

I know I could copy/paste the code here, but at 5.33 kb I feel that's it's too much. You can go to my website at quickbasic45.weebly.com to see a copy/paste of the code and/or download the .bas file. Or you can download a Notepad copy of the code right here.

Any comments?

[recovering disk space, attachment deleted by admin]

[Newbe]

Well here is my latest attempt, in QB 64. It's a 15 question trivia quiz, with (annoying?) sound. How about heading over to my website at http://quickbasic64.weebly.com/ and checking it out?

[Newbe]

Well here is my latest attempt, in QB 64. It's a 15 question trivia quiz, with (annoying?) sound. How about heading over to my website at http://quickbasic64.weebly.com/ and checking it out?

Here I am again. Remember my previous post about the annoying sound in the program? I've tried and tried to modify it so a user can turn the sounds off, but to no avail.

Any ideas or suggestions?

Here's a copy/paste of just the sound subroutines. You can download the entire program at my website at http://quickbasic64.weebly.com/

wrong:
IF sound$ = "n" THEN LOCATE 22, 22: PRINT "You have the sound turned off.";
RETURN
BEEP
BEEP
RETURN

correct:
LOCATE 14, 28: COLOR 18, 1: PRINT "That is correct!": COLOR 15, 1
IF sound$ = "n" THEN LOCATE 22, 22: PRINT "You have the sound turned off.";
RETURN
PLAY "mll64"
FOR x = 1 TO 50
    a$ = a$ + "v" + LTRIM$(STR$(x)) + "n" + LTRIM$(STR$(x))
NEXT
FOR x = 50 TO 1 STEP -1
    a$ = a$ + "v" + LTRIM$(STR$(x)) + "n" + LTRIM$(STR$(x))
NEXT
PLAY a$
a$ = ""
RETURN

[BC_Programmer]

You are using a one-line if statements. the return statements following your sound$="n" checks will always be run.

[Newbe]

BC_Programmer,
Thanks for the input. I've switched to a desktop and I seem to have non-BASIC programming problems with it. I'll go back to the laptop I wrote the program on and check it out. I'll get back to you.

[Newbe]

wrong:
IF sound$ = "n" THEN LOCATE 22, 22: PRINT "You have the sound turned off.";
RETURN
BEEP
BEEP
RETURN

Using this shorter one as an example, I expect sound$ to be "n" when the user enters "n" at the "INPUT sound$" prompt. I initialize sound$ to "".
Each of the 15 questions calls the same wrong answer subroutine, which I'm trying to exit (return) if the user selects no sound. I use the same logic for correct answers.

What am I missing? How do I get away from the one-line if statements?

The lack of sound on this program seems to be a deficiency in this program (trivia2.bas) as well as on my desktop. If I run this program and my original version (trivia.bas) on my laptop, the sound works in both programs. I think I know what the desktop sound problem is though.

[Salmon Trout]

wrong:
IF sound$ = "n" THEN LOCATE 22, 22: PRINT "You have the sound turned off.";
RETURN
BEEP
BEEP
RETURN

This above code is first going to run the single line IF test: if sound$ is "n", you PRINT the message, if sound$ is not "n" you don't PRINT the message, then execution continues at the next line (whatever the IF test result was) so you then RETURN, and the two BEEPs are never executed. It looks like you now need to find out about multiline IF statements,

What am I missing? How do I get away from the one-line if statements?

Here are a couple of examples that you may find illuminating:

IF sound$ = "n" THEN
    LOCATE 22, 22: PRINT "You have the sound turned off.";
    RETURN
END IF
BEEP
BEEP
RETURN

or (better)....

IF sound$ = "n" THEN
    LOCATE 22, 22: PRINT "You have the sound turned off.";
    RETURN
ELSE
    BEEP
    BEEP
    RETURN
END IF

Check here:

http://www.schoolfreeware.com/QBasic_Tutorial_7_-_If_Statements_-_QB64.html

and for overall guidance start here:

http://www.schoolfreeware.com/QBasic_Tutorials_-_QB64_Tutorials_-_Programming_And_Code_Examples.html

[Geek-9pm]

GOTO of course compiles to an Assembly JMP instruction. The issue with it is that it often wreaks havoc on the CPU prefetch cache, and basically every JMP will flush the prefetch queue. CALL and RET- which are used for functions and subroutines- work with the prefetcher logic. This wouldn't have a impact on your program- your program is currently fine, since most of it's time is spent waiting for user input.

Above posted earlier by BC_Programmer.
GOTO is almost never needed in modern programming.  Use of procedure and function is more a matter of style rather than t machine efficiency Using procedures with meaningful names help one to maintain disciple and sanity to a project. It can also reduce redundant code. In the rare case that a JMP instruction was really needed, the pre fetch  issue does not matter. If you have to JMP, just JMP.
Here is a reference.
http://en.wikipedia.org/wiki/Prefetch_input_queue