BBC BASIC for Windows v6.13 release candidate

[RichardRussell]

I have put a BB4W v6.13 release candidate here; as always it has a dependency on aplib.dll. This version will announce itself as v6.12x and has the following changes compared with v6.12a:

1. Extended VDU 27,n to work in VDU 5 mode as well as VDU 4 mode, making it considerably more useful.
2. Fixed a bug in WIDTH() which could occasionally affect subsequent text or graphics rendering.

Please test this version as thoroughly as you can and report any problems here (or to me personally if you prefer).

[KenDown]

I found that if I simply clicked on the link given I received the following message: "The code execution cannot proceed because aplib.dll was not found. Reinstalling the program may fix this problem."

After trying several other things - probably because I'm not very good at this - I finally managed to save the file to disk. I then opened up the BB4W directory on drive C:, renamed bbcwin6.exe to bbcwin6a.exe and copied the new bbcwin6.exe into that directory and eureka! Up came 6.12x as predicted.

I then ran the program which had previously offended in the matter of WIDTH and I'm happy to report that everything functioned as it should. Thank you, Richard.

I look forward to trying out the improved VDU command.

[RichardRussell]

I received the following message: "The code execution cannot proceed because aplib.dll was not found.

I specifically drew attention to this ("as always it has a dependency on aplib.dll") so I'm not at all sure why you felt the need to mention it.

I then ran the program which had previously offended in the matter of WIDTH and I'm happy to report that everything functioned as it should.

Excellent, but the worry is of course that I might have inadvertently broken something else, possibly apparently unrelated - it's happened before. Please don't limit your testing to the one thing I know I've fixed!

[KenDown]

Indeed you did - but my post explained how I got round the problem. Perhaps I'm the only dim one here and others would solve the problem with a nifty keyboard shortcut or something, but just in case …

I will certainly use WIDTH where I can and report any problems, however it has occurred to me that there is one thing for which I will still need to use the other routine: in my program I move the text-y position manually - I like slightly larger line spacing than the default - and for that I need to know not only the width of a string but also the height for that particular font. It's a bit greedy, I know, but I don't suppose there is any chance of a txty%=HEIGHT(a$) in addition to the txtx%=WIDTH(a$)?

[DDRM]

Hi Richard,

Thanks for the update. I've installed it: no formal testing, but it seems to run things fine so far. I'll carry on trying.

Best wishes,

D

[RichardRussell]

Indeed you did - but my post explained how I got round the problem.

Fair enough, but with something as straightforward as satisfying the DLL dependencies of an executable I prefer to leave people to use whichever method they prefer rather than to lead them in a particular direction. Personally I would not have chosen the method you used, because of needing to rename the file (and with the attendant risk of overwriting the old version if you forget to).

I would probably just copy aplib.dll into the same directory as the executable, but the various different options (such as copying it into the \Windows\SysWOW64 directory) can be found by checking out the default DLL search sequence at the MSDN documentation of the LoadLibrary function.

and for that I need to know not only the width of a string but also the height for that particular font. It's a bit greedy, I know, but I don't suppose there is any chance of a txty%=HEIGHT(a$) in addition to the txtx%=WIDTH(a$)?

WIDTH(), or an equivalent, is necessary because the different characters in a proportional-spaced font have different widths, so there's otherwise no way to ascertain the total width of a string. There isn't a comparable situation with the height; all the characters have the same height, so the height of a string is independent of its length or the characters it contains! Therefore the height can be trivially found from the documented @vdu%!220 value.

I've just used the Search Utility in BBCSDL to find out how many of the supplied example programs contain a reference to @vdu%!220, as an indication of how common this usage is: the answer was 24! If for some reason you're using the GetTextExtentPoint32() function anyway then it's reasonable to use it for both the width and height, but if you're using WIDTH() because of its advantages - not least that it's cross-platform - then getting the height from @vdu%!220 is the obvious way.

Of course @vdu%!220 is useful in another way as well, it's how (documented at the wiki) you specify a font by its pixel height rather than its point size. This can be very useful if you don't want your font to scale with DPI value. For example you will see that I use it in the recent lotto.bbc program for labelling the balls with their numbers, because it's important for the font size always to be related to the size of the balls rather than to be scaled.

[hellomike]

Will it include an updated Box2D lib in order to run the latest BBC BASIC for SDL 2.0 examples?

[KenDown]

All the characters have the same height? I never knew that. Every time I've selected a new font in my program I test "HqWi", thinking that by including tall characters as well as ones that descend below the line I was being clever!

I might have known.

[RichardRussell]

Will it include an updated Box2D lib in order to run the latest BBC BASIC for SDL 2.0 examples?

The Box2D libraries for BB4W have never been bundled, it has always been necessary to download them separately and copy them into the LIB directory (as indeed it is for many other libraries). I don't see any particular reason to change that, not least because if I did bundle them people would expect them to be documented in the main Help manual (they already complain that the bundled EVENTLIB library isn't documented) which wouldn't be practical or sensible. What is your concern, if any, about needing to download libraries separately?

[hellomike]

No concern whatsoever Richard. Is there a dedicated section on your site listing the version numbers of the most recent available libraries?

I checked: http://www.bbcbasic.co.uk/bbcwin/updates.html but that isn't it.

It is not a complaint but rather my failure to locate updated material outside of the mainstream BB4W bundle.