Author |
Topic: Another bug in v 6.0? (Read 1015 times) |
|
KenDown
Full Member
member is offline
Posts: 181
|
 |
Re: Another bug in v 6.0?
« Reply #2 on: Jul 19th, 2015, 5:19pm » |
|
It's a very short program. I don't use line numbers but may include them temporarily to help in debugging. I don't concatenate lines.
I have REMed out the lines which load arrow bmps into two of the buttons. The fault remains and is not exacerbated by their absence.
Note that the program works fine from the program editor provided there is a text file called "Overlay.txt" in the same directory, consisting of two or more lines of text separated by lines consisting of a single comma. When compiled, however, I have to use Ctrl+Alt+Delete and force the program to close.
PROCinit
*SYS 1
click%=0
ON SYS click%=FNsys(@msg%,@wparam%,@lparam%):RETURN
SYS"DragAcceptFiles",@hwnd%,1
REPEAT
pause%=INKEY(1)
CASEclick%OF
WHEN100:click%=0
IFword%>0word%-=1:VDU7
CLS
PROCprint(word$(word%))
WHEN101:click%=0
word%+=1
CLS
PROCprint(word$(word%))
IFword%>w%end%=TRUE
WHEN104:end%=TRUE
ENDCASE
MOUSEx%,y%,b%
CASEb%OF
WHEN4
CASETRUE OF
WHENdraw%=TRUE
MOVEx%,y%
REPEAT
MOUSEx%,y%,b%
IFy%>60DRAWx%,y%
UNTILb%=0
WHENfill%=TRUE
c%=POINT(x%,y%)
GCOL0,128+c%
IFy%>60FILLx%,y%
ENDCASE
SYS"BringWindowToTop",@hwnd%
WHEN2:CLS
PROCprint(word$(word%))
WHEN1
end%=TRUE
ENDCASE
UNTILend%
SYS"DeleteObject",larrow%
SYS"DeleteObject",rarrow%
CASETRUE OF
WHENINSTR(@dir$,"Desktop")>0:PROCdeletebmps
WHENINSTR(@dir$,"Transparent\")=0:PROCdeletebmps
ENDCASE
VDU7
QUIT
:
DEFPROCprint(a$):LOCALi%
py%=300
nw%=xscreen%-200
VDU5
REPEAT
REPEAT
REPEAT:i%+=1:UNTILMID$(a$,i%,1)=" "ORi%>LENa$
SYS"GetTextExtentPoint32",@memhdc%,LEFT$(a$,i%),i%,nsize{}
UNTILnsize.x%>nw%ORi%>LENa$
IFnsize.x%>nw%-16REPEAT:i%-=1:UNTILMID$(a$,i%,1)=" "
SYS"GetTextExtentPoint32",@memhdc%,LEFT$(a$,i%),i%,nsize{}
lx%=(xscreen%-nsize.x%)
GCOL0,0:MOVElx%,py%:PRINTLEFT$(a$,i%-1)
GCOL0,15:MOVElx%-8,py%+8:PRINTLEFT$(a$,i%-1)
a$=MID$(a$,i%+1):i%=0
py%-=100
UNTILa$=""ORpy%<100
VDU4
GCOL0,9
ENDPROC
:
DEFPROCdeletebmps
OSCLI("Delete leftarrow.bmp")
OSCLI("Delete rightarrow.bmp")
ENDPROC
:
DEFFNsys(M%,W%,L%)
CASEM%OF
WHEN273:click%=W%AND&FFF
REMWHEN563:PROCdrag(W%,L%):click%=0
ENDCASE
=click%
:
DEFPROCdrag(W%,L%)
SYS"DragQueryFile",W%,-1,0,0TON%
IFN%=0ENDPROC
SYS"DragQueryFile",W%,I%,K%,255
PROCopen($$K%)
ENDPROC
:
DEFPROCinit
INSTALL@lib$+"WINLIB5"
SYS"GetSystemMetrics",0TOxscreen%
SYS"GetSystemMetrics",1TOyscreen%
SYS"SetWindowLong",@hwnd%,-16,&16000000:REM Remove title bar and furniture
SYS"SetWindowPos",@hwnd%,-1,0,-30,xscreen%,yscreen%,32:REM Set window to full screen
VDU 26
COLOUR129:GCOL0,129
CLS
transparent%=TINT(0,0)
SYS"SetWindowLong",@hwnd%,-20,&80000
SYS"SetLayeredWindowAttributes",@hwnd%,transparent%,0,1
end%=FALSE
VDU23,23,4;0;0;0;
GCOL0,9
gcol%=9
bot%=yscreen%-30
but1%=FN_button("",0,30,60,30,100,&80)
but2%=FN_button("",xscreen%-60,30,60,30,101,&80)
but3%=FN_button("Load",0,62,60,30,102,0)
but4%=FN_button("Quit",0,94,60,30,104,0)
REMSYS"LoadImage",0,@dir$+"leftarrow.bmp",0,60,30,16TOlarrow%
REMSYS"LoadImage",0,@dir$+"rightarrow.bmp",0,60,30,16TOrarrow%
REMSYS"SendMessage",but1%,247,0,larrow%
REMSYS"SendMessage",but2%,247,0,rarrow%
draw%=TRUE
DIMword$(400)
DIMnsize{x%,y%}
F%=OPENIN(@dir$+"OverlayText.txt")
w%=0
REPEAT
a$=GET$#F%:IFa$=""a$=GET$#F%
IFa$<>","word$(w%)+=a$ELSEw%+=1
UNTILEOF#F%
CLOSE#F%
OSCLI("FONT Ariel,36,B")
word%=-1
ENDPROC
|
|
 Logged
|
|
|
|
rtr2
Guest
|
|
Re: Another bug in v 6.0?
« Reply #3 on: Jul 19th, 2015, 6:59pm » |
|
on Jul 19th, 2015, 5:19pm, KenDown wrote:
As I suspected, it's something which is accepted by the interpreter but not by the compiler. To be precise you have omitted a required space here:
Code:
If you change this line to:
Code:
or, arguably even better:
Code: IF word%>w% THEN end%=TRUE
it will compile and run successfully.
In general you seem to be writing 'compressed' code - you have omitted spaces at almost every opportunity, as if you were wanting to squeeze the program in the 16K of a Model A BBC Micro!
Don't do it. On the contrary use plenty of 'white space', long variable names, loads of REMs etc. to make your program as readable and maintainable as possible. When you finally 'compile' your program BB4W will automatically take out all the 'unnecessary' verbosity.
Richard.
|
| « Last Edit: Jul 19th, 2015, 7:05pm by rtr2 » |
Logged
|
|
|
|
KenDown
Full Member
member is offline
Posts: 181
|
|
Re: Another bug in v 6.0?
« Reply #4 on: Jul 19th, 2015, 9:22pm » |
|
Well, I did cut my teeth on a BBC model A until I could afford a B, so yes, I do omit spaces at every opportunity and actually find them an annoying distraction.
Anyway, thanks for finding the problem. Are there any other instances in which v.6 requires spaces? After all, the program compiles happily on v.5.95. If spaces are now required in certain circumstances, I think we should be alerted to them.
Thanks again.
|
|
Logged
|
|
|
|
rtr2
Guest
|
|
Re: Another bug in v 6.0?
« Reply #5 on: Jul 19th, 2015, 10:44pm » |
|
on Jul 19th, 2015, 9:22pm, KenDown wrote:| Are there any other instances in which v.6 requires spaces? |
|
BBC BASIC has always required spaces in many situations, such as:
Code: IFcondition variable=number
Obviously a space between "condition" and "variable" is essential here. However not all cases are as obvious:
Code:
Here, by analogy with the IF example above, one might expect it to be acceptable to omit the space, but it isn't.
Because the rules governing when you must include a space, and when it's optional, are quite complicated the safest thing to do is always to include it - and it makes the program much more readable.
Quote:| After all, the program compiles happily on v.5.95. |
|
The change comes about because of the introduction of 64-bit integer variables having a %% suffix. Previously, if the compiler encountered a percent sign it knew it must be the last character of the variable name, but that is no longer the case. So now it waits until it sees a character which definitely cannot be part of the name (for example a space).
The interpreter, on the other hand, has the luxury of parsing the program as it is executed at run-time, so a similar ambiguity doesn't arise.
Quote:| If spaces are now required in certain circumstances, I think we should be alerted to them. |
|
I would turn this on its head: where have you seen in the BB4W documentation that spaces can be omitted? As far as I am aware nowhere does it say that, and you will be hard pressed to find any example programs which do so (except RHEOLISM!).
Few if any other dialects of BASIC allow you to omit spaces in the way you are doing, it's a quirk of BBC BASIC which was exploited in the BBC Micro days to squeeze more functionality in the limited memory, but it has always been discouraged. I would never do it myself, and I would venture to suggest that you are probably the only BB4W user who does.
It's a habit I would try to kick.
Richard.
|
| « Last Edit: Jul 19th, 2015, 10:49pm by rtr2 » |
Logged
|
|
|
|
|
