Learning to program the Wimp in BASIC

All I’m questioning is whether the 3D widgets matter at all.

If nobody has ever complained that all your applications’ buttons are still 2D-style, then no!

For PipeDream and Fireworkz it was important as Acorn let ‘NewLook’ out into the wild around RISC OS 3.1 time that supported 3D-styling and enough punters complained that we had to put the effort into redoing the dialogue boxes for these applications in case NewLook was active on customer systems. Fireworkz was able to do this on-the-fly as it creates all its windows in memory without templates, whereas for PipeDream (that does use window templates) the buttons were a bit of a compromise as they still had to look OK on most of our customer systems that weren’t running NewLook.

If nobody has ever complained that all your applications’ buttons are still 2D-style, then no!

No, nobody has. But they probably realize it’s not the kind of thing I give a shit about, so don’t bother to complain. Now if there was a functional reason to want 3D-style, things would be different.

Please don’t call them “widgets” as a widget is an icon with some degree of intelligence or ability – like a menu handle you can click on that shows a drop down menu by itself; or a timer that when set up and started will call a routine periodically. Accordingly, they are something of an alien concept around these parts. ;)

Anyway, 3D icons mattered since 1992 when RISC OS 3 induced them and allowed us to get away from a yucky boring flat look.

Then in 2013, a mere 22 years later, Apple released iOS 7 which did away with all of the skuomorphisms (in other words, buttons that looked like buttons) and returned us to the horrible flat look of the early ‘90s. They then quickly pushed out an update so that icons at least had a slightly different background so you’d know what the hell you’re supposed to fiddle with.

I happen to like the 3D effect icons. Raised things that say “click me, I do stuff”. But I guess a younger generation of programmer can’t grok clicking on anything that isn’t a word in blue and underlined… Pffft.

Oh, and the 3D effect actually has some specific uses on RISC OS. You may notice the next time a question pops up, or a window with choices, that one of those choices is an icon with a bigger fancier ridge around it.
That’s the one that will be actioned if you press Enter.

Typically the other, or the leftmost if there are multiple, would be actioned if you pressed Escape, but this really only has value in error boxes. Multitasking windows don’t tend to trap the Escape key.

Without 3D effects, the way to tell these actions apart would be the icon background colour, and that’s the ugly look of RISC OS 2 that drove Computer Concepts so far around the tree that they created their own 3D icon system (ABI).

Please don’t call them “widgets”

Okay, I was merely repeating what someone else called them. I’d not even noticed them until they were mentioned above.

Without 3D effects, the way to tell these actions apart would be the icon background colour

Well, exactly

and that’s the ugly look of RISC OS 2

not the kind of thing I notice at all. Something changes when you click on things. What changed? I don’t know, I just noticed it changed, whatever it was.

Funnily enough, while I don’t notice things of this sort, I’m acutely sensitive to typography.

I happen to like the 3D effect icons.

I don’t dislike them, they’re fine. But I don’t really care one way or the other about them. If I learn how to use templates because they make other things easier, and I get 3D icons as a side effect, that’s fine.

Since BASIC has no data structuring, you get joy like this […]

Sort-of. In practice you wouldn’t, because a set of library routines to build and position standard window components would be the way to go. Something like…

configuration_dialog% = FNstart_dialogue("Configuration")
PROCstart_group(configuration_dialog%, "Some options")
PROCcheckbox(configuration_dialog%, "Option one")
PROCcheckbox(configuration_dialog%, "Option two")

…and so on. But… I’m not aware of anything like that, however, and creating it would be a huge step to take for a beginner.

Which is why we end up with beginners poking bits into blocks of memory using !, ? and $, whilst getting ever more frustrated.

Or using templates. :-)

I’d give an example here, but all I can find is stuff written in C.

Over in that tutorial that I linked to earlier (and where I’ve just fixed the duff message list advice), I’ve done just that:

REM Load the window templates

DIM TemplateName% 12

SYS "Wimp_OpenTemplate",,"<PaneDemo$Dir>.Templates"

PROCtemplate_load("Main", b%, buffer_size%, -1)
SYS "Wimp_CreateWindow",,b% TO MainWindow%

PROCtemplate_load("ProgInfo", b%, buffer_size%, -1)
SYS "Wimp_CreateWindow",,b% TO InfoWindow%

SYS "Wimp_CloseTemplate"

where PROCtemplate_load() is defined as

DEF PROCtemplate_load(name$, buffer%, size%, fonts%)
LOCAL templ_size%, indir_size%, workspace%

$TemplateName% = LEFT$(name$ + STRING$(12, CHR$(13)), 12)

REM Find the size required for the template and indirected data.

SYS "Wimp_LoadTemplate",,,,,-1, TemplateName%, 0 TO ,templ_size%, indir_size%

REM Return if the template won't fit in the buffer.

IF templ_size% > size% THEN ENDPROC

REM Claim the required indirection block.

DIM workspace% indir_size% - 1

REM Load the template into the buffer.

SYS "Wimp_LoadTemplate",,buffer%, workspace%, workspace% + indir_size%, fonts%, TemplateName%, 0
ENDPROC

PROCtemplate_load() is loosely based on the more complex PROCtemplate_load_claim() from my WimpLib – there’s a lot of extra ick in that which isn’t required for messing around with window panes.

But they probably realize it’s not the kind of thing I give a shit about, so don’t bother to complain.

Since flat seems to be the current fashion, it would seem that you, like many of my clothing items, are totally with that fashion by standing still and waiting for them to get round to where you are…

Since flat seems to be the current fashion … clothing

Surely creased, or preferably even crumpled, is the eternal fashion for clothing, no?

Surely creased, or preferably even crumpled, is the eternal fashion for clothing, no?

and patches (are those still a fashion, or do I need to wait for them to come round again, again…)

In similar vein, and back on topic, I suspect 3D-effect graphics will be back – probably to be Apple’s best “new” idea ever – so don’t ditch the code.

so don’t ditch the code

I don’t have any to ditch…

Just a small thing, Steve, but with a single, named template you do not need the 12-byte buffer, which is used for wild-carded names (PRM 3-171 not StrongHelp). So:

DIM TemplateName% 12

$TemplateName% = LEFT$(name$ + STRING$(12, CHR$(13)), 12)

SYS “Wimp_LoadTemplate”,,,,,-1, TemplateName%, 0 TO ,templ_size%, indir_size%

Wimp_LoadTemplate",,,,,-1, name$, 0 TO ,templ_size%, indir_size%

Of course, when you load all the templates in a loop you need the buffer, but I use buffer$="***********" for that and let BASIC do its stuff with SYS and strings.. ;-)

Also useful, perhaps, with RO5 you can use DIM LOCAL to provide the template buffer, which removes the need to supply a sufficiently large one as a parameter.

Since BASIC has no data structuring

BASIC has arrays. ;-)

This point about no structuring in BASIC is a bit irksome. Structures™ are not provided in the language ¹, but structuring is a state of mind. It will not be something for the beginner, in BASIC or C. Look at raw code to define a wimdow in C and it is not really much simpler than BASIC, with its indirection. True, you get named structure items, provided by an invoked header file, but you can have named indirection offsets provided by a library ². Once a programmer is ready to exploit structuring, the route taken in BASIC will likely be one using PROCs and FNs in libraries, as outlined by Steve F, but Structures™ can also be provided using library routines if you really have to have them ³

¹ Unles you used Basalt, of course. ;-)

² I have one of those that follows Desktop C quite closely, so you can do things like PRINT !(MyWindow%+Wicon(3)+Ibox+Xmax).

³ Such as that on my downloads page. This is very old and could be improved, but it does the job.

Unles you used Basalt, of course.

I am rather intrigued by the latest update, by Sprow, to this document

I am rather intrigued by the latest update, by Sprow, to this document

So am I. I’ve been saying for many years now that BASIC needs a 64 bit integer type. The first use that springs to mind is a file pointer when we get files bigger than 4 GiB.

Another thing I would like is BASIC to handle strings over 256 characters.

You might as well wait for 64 bit RISC OS, as both of the above will not be backwards compatible.

as both of the above will not be backwards compatible.

Neither were the RiscPC enhancements like GCOL r,g,b.
These days we have COLOUR OF x ON y statements as well.

Is there an easy way to determine the actual BASIC version?
I don’t think it’s useful using REPORT$ as doesn’t BASIC still identify itself as BASIC V Acorn 19xx or something?

am rather intrigued by the latest update, by Sprow,

Thanks for pointing that out – and updated yesterday!

The Basalt link there is useless, so I have extracted some bits of earlier attempts at documentation as an HTML page and as a PDF page

These should make the design thoughts fairly clear.

Another thing I would like is BASIC to handle strings over 256 characters.

Do you want to handle such long strings, or do you want the string variable type to use long strings? If the latter, then as druck says it “will not be backwards compatible”.

However, you can handle long strings in BASIC, with variable degrees of convenience. There are a number of libraries out there ¹. Even BB4W only does up to 64k as a variable type and uses a library for unlimited strings.

¹ One thing that underpins many extensions to BASIC is a flexible means of managing memory. This is surprisingly easy to do with with a heap above HIMEM. Were this to be the first major extension to the BASIC module it would be a great boon.

Is there an easy way to determine the actual BASIC version?

SYS"OS_Module",18,"Basic" TO ,,,code%
SYS"XOS_GenerateError",code%+code%!20 TO help$

Unless things have changed recently, I do not think you can get it directly.

This is surprisingly easy to do with with a heap above HIMEM. Were this to be the first major extension to the BASIC module it would be a great boon.

How crazy would it be to abuse HIMEM thus:

DIM (LOCAL) HIMEM blk% size%: REM to allocate in a BASIC-managed heap above HIMEM
DIM (LOCAL) HIMEM blk% 0: REM to free (and set the variable to zero)

How crazy would it be to abuse HIMEM thus:

That has been the Basalt syntax for the last 20+ years. ;-)

Hmmm. except for -1 to follow regular DIM.

with a single, named template you do not need the 12-byte buffer, which is used for wild-carded names (PRM 3-171 not StrongHelp)

Is this actually documented anywhere? I know it’s the case (and why, having read the relevant bit of the Wimp source code), but on page 3-170 of the PRM it states that R5 “must be 12 bytes word-aligned”. The closest that I can see to being specific on this is that the statement is in parentheses, and these could be linked to the earlier “(wildcarded)” parentheses – although that seems tenuous. There’s certainly nothing in the text that I can see to say that it does not need to be word-aligned unless wildcards are in use?

That said,

DIM TemplateName% 12

$TemplateName% = LEFT$(name$ + STRING$(12, CHR$(13)), 12)

is another bit of sub-optimal code… I clearly cribbed it from somewhere, as I can’t see my having come up with that all by myself, but Wimp Programming for All uses the far saner

DIM TemplateName% 11

$TemplateName = name$

in its listings – and that’s where I’d have originally learned from. In practice,

DIM TemplateName% 11

$TemplateName% = LEFT$(name$, 11)

feels as if it should be more than adequate!

This is from my original paper manual:

As the wildcarded name is overwritten by the actual one found, it must be re-initialised before every call and must be big enough to have the template name written to it.

I interpret that as allowing that if the name is not wildcarded a string passed by BASIC in a word-aligned buffer on the stack will be “big enough” for the identical template name.

both of the above will not be backwards compatible

Lack of backwards compatibility is of no consequence.

(If you cast your mind far enough back, you will realise that there are features in BBC BASIC that we’ve been using for years that were not in the original version.)

People who want to manipulate files > 4 GiB will not be using an old OS version any more than they will be using an old version of BASIC.

We have to move on and keep moving on. We must not be held back by over-zealous desire for backward compatibility.

People who want to manipulate files > 4 GiB will not be using an old OS version any more than they will be using an old version of BASIC.

That was exactly my point.