Author |
Topic: Another bug in v 6.0? (Read 1013 times) |
|
KenDown
Full Member
member is offline
Posts: 181
|
 |
Another bug in v 6.0?
« Thread started on: Jul 19th, 2015, 3:40pm » |
|
Recently I upgraded to v. 6 and everything seemed to run fine. Then I wrote a short program that uses a transparent window to overlay the screen (specifically while playing video) and then read in subtitles from a file. (Don't ask: it was something I needed.)
I ran the program multiple times while writing it and everything worked fine. When I was satisfied I compiled it and to my astonishment it appeared to hang up. A little debugging produced the message "Mistake in line 0" - even when I used line numbers in the program.
After much hair-tearing I identified the offending line, a seemingly innocuous
w%=0
Remove it and the program worked fine when compiled (though of course there were problems later on when w% was called!) I tried varying the position, changing the variable name, setting it to FALSE rather than 0, but always the same problem and the same unhelpful error message.
Finally the light dawned. I loaded the program into v.5.95 and compiled it and it runs just fine.
I'll be happy to send the program if that would help.
|
|
 Logged
|
|
|
|
rtr2
Guest
|
|
Re: Another bug in v 6.0?
« Reply #1 on: Jul 19th, 2015, 4:38pm » |
|
on Jul 19th, 2015, 3:40pm, KenDown wrote:
Another? If it's really a bug it will be the first!
Quote:| A little debugging produced the message "Mistake in line 0" - even when I used line numbers in the program. |
|
Whether you used line numbers in the source program or not is irrelevant: the compiler removes them (by default). Only if you actually reference the line number in the program - which hopefully you wouldn't - or if you deselect the 'Concatenate lines' option, are line numbers retained in an EXE.
Quote:| I'll be happy to send the program if that would help |
|
Please do, although it would be very helpful if you can first pare it down to the minimum amount of code which demonstrates the issue.
Past experience makes me suspect it's not a bug but some faulty code which is accepted by the interpreter (through being more tolerant of mistakes) but not by the compiler.
Richard.
|
| « Last Edit: Jul 19th, 2015, 4:44pm by rtr2 » |
Logged
|
|
|
|
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
|
|
|
|
|
