About QBasic Mac Expertise QBasic was designed to be run on a DOS operating system. I can answer most any question about programming in general and QBasic and DOS in particular, at a level understandable to the average novice programmer.
As QBasic was designed to introduce people to the principals of programming and not designed to be a developer's language, I am unable to answer questions regarding how to write programs to do Windows type functions or advanced graphics. In particular, I answer no questions regarding VISTA as that system does not support QBasic. Sorry you have VISTA!
Experience I have been writing BASIC programs since the VIC-20 was introduced and QBasic programs as soon as it came out. I have participated on QBasic forums such as the classic forum at www.qbasic.com for years and thus have lots of experience working with people with limited knowledge of QBasic.
Samples of my works:
A telephone-book type program which is notable because of the way it remembers what the user enters and is difficult to "break" by entering bogus information.
A utility program that will scan a QBasic program and find all labels which were not used.
A maze you will probably never solve, but you can watch the computer solve it! I know someone who solved one.
V'GER, A fascinating game of concentration rather than motor skills.
A generalized help SUB. You insert your help information and as a result, you have a help panel with navigable topics.
Homework drill: You supply a data file of word-pairs and it asks questions and checks your answer. The "different" part is that if the answer to "What is the capital of the USA"?" is "Washington, D.C." it will accept slight variations like "Washington DC".
A program where you enter a,b,c of aX^2 bX c=0 - Get roots
The missing ARC SIN and ARC COS functions
A Bowling Scorepad. You enter pins knocked down. See scores entered.
A House Alarm Simulator. Shows INKEY$ working in main program while ON TIMER is stepping down time until alarm triggers.
Demo which shows swapping screens, moving object with arrows, objects moving while awaiting input.
A program you can start in two windows and which allows you to send messages back and forth.
Well, you get the picture. The list goes on and on.
Expert: QBasic Mac Date: 3/27/2008 Subject: errors when compiled
Question QUESTION: I have a quickbasic (4.5) program that does brake calcs. It returns correct results when run in the editor but some results are incorrect when run as a compiled executable. Samples follow...
from QB editor...
0.00E 0.0000-0.0000
0.20E 0.1411-0.1496
0.40E 0.3049-0.3232
from executable...
0.00E %-1.0I0%-1.0I
0.20E 0.1411-0.1496
0.40E 0.3049-0.3232
ANSWER: Hi, Greg,
Could you post the exact snippet of code that produced
0.00E %-1.0I0%-1.0I
so I can try it out.
Might be inconsistency in
PRINT USING
between IDE and compiler.
But in general, the two values are merely differences in how the exact same value is displayed.
This is irritating to human beings, who perceive that when different values are displayed, then there must be different values.
Nope, says the machine, I just chose to display it that way. The values are the exact same.
Mac
---------- FOLLOW-UP ----------
QUESTION: Thanks heaps for your help. Program does display results with a PRINT USING statement, but don't think this is the issue coz I tried removing the USING condition and just printed raw results, and same thing happens. (BTW, I compile executable requiring BRUN45, not standalone, coz program chains to other programs - in case this has anything to do with it?). Anyway, I've pasted example of code below, along with output from within editor and after compiled. Note that these values are calculated by another section of code (some fairly complex calcs including interpolation of intermediate values) and then sorted into ascenting order of the first value ('E'). When run within the editor this works perfectly and sorts intermediate values in correct order, but when compiled these intermediate values are calc'd as negative values and bubble to the top of the sort. It's got me beat!
FOR e% = 2 TO 14
LOCATE e% + 5, 2: PRINT inpress!(e%);
PRINT "E",
PRINT ERCmin!(e%);
PRINT "-"
PRINT ERCmax!(e%)
NEXT
Results from running within editor...
0 E 0 - 0
0 E 0 - 0
0 E 0 - 0
.2 E .1411138 - .1495806
.2004831 E .1415094 - .15
.373275 E .2830189 - .3
.4 E .3049055 - .3231998
.5462495 E .4245284 - .45
.5773908 E .45 - .4769999
.6 E .4684929 - .4966024
.7 E .5492617 - .5822173
.8 E .6307819 - .6686288
1 E .750996 - .7960557
Results from compiled program...
-1.0I0D E -1.0I0D --1.0I0D
-1.0I0D E -1.0I0D --1.0I0D
-1.0I0D E -1.0I0D --1.0I0D
-1.0I0D E -1.0I0D --1.0I0D
0 E -1.0I0D --1.0I0D
0 E -1.0I0D --1.0I0D
0 E -1.0I0D --1.0I0D
.2 E .1411138 - .1495806
.4 E .3049055 - .3231998
.6 E .4684929 - .4966024
.7 E .5492617 - .5822173
.8 E .6307819 - .6686288
1 E .750996 - .7960557
Answer I can't duplicate your exact case. The IDE was written by one group of people at one time and the compiler was written by another, so we can expect discrepancies in the mysterious area of near-zero.
All I can suggest is instead of testing for exact match
IF A = 0 then
Instead test for nearly match
IF A < .00000001 and A >.00000001
If you are dealing with real data from lab experiments,
65.4 is the same as 65.400000001
