Wimp_LoadTemplate Handle error

Given DeviceFS can associate files with device access, I think CLOSE#0 could have unforseen consequences. Ideally there ought to be a ServiceCall prior to a file being closed where one can veto the handle actually being closed.

[I know one can sit on FindV, but that doesn’t have handle level granularity – one can trap #0 as a handle, but not specific handle(s) in the set of “all”]

What are Internet progs supposed to do over a Poll?

Bend the rules. A socket allocated to you should be left alone so you can refer to it again (as far as I’m aware, there’s no *Close equivalent to close all open sockets). One should hope the same applies to file handles, but as you say you had programs that didn’t check the handle was not zero. I doubt you’re alone there. I set unused file handles to NULL, and since I use DeskLib it’s a real handle and not the CLib one. I check, but it only takes forgetting once to mess things up. ;-)

In short, there’s no easy answer. We’re far beyond the single user single process single state concept that was born of Arthur, and some things (anything that interacts with a remote machine) simply wouldn’t work if some state wasn’t held across polls. Consider, well, never mind a browser, consider a simple telnet program. Back in the days of BBSs, I doubt Hearsay (etc) closed file handles across polling for lengthy downloads. Sometimes the rules themselves are more problematic than what the program is trying to achieve.
Plus, if in doubt, just point at FilerAction. ;-)

Just read this discussion with interest. I have had a similar problem. One of a group of programs was doing
CLOSE#X:X=0 twice. The second of course had the effect of CLOSE#0.
Sometimes another program produced the “file has been closed” message from Wimp_LoadTemplate. However that program had the open, load and close template calls in successive lines of the BASIC program, so it’s hard to see how the CLOSE#0 could have affected it. Nevertheless, fixing the problem program so it doesn’t do CLOSE#0 has also fixed the load template problem.

Could this all imply that an addition to BBC BASIC could re-implement the CLOSE# command to incorporate these ideas and make a safe CLOSE# command which checked if the handle was open, closed it if it was, then set its handle to zero?

Sorry, Sophie, it’s only taken (!) so many years to arrive here!

Is BASIC immutable?

re-implement the CLOSE# command to incorporate these ideas and make a safe CLOSE# command

One of the first things I implemented 15 years ago in the Basalt extension to BASIC was just this. ;-)

a safe CLOSE# command which checked if the handle was open

All of the affected handles are open… that’s the whole problem.

Is BASIC immutable?

Changing an existing command in that way is probably out, because of the side effects. CLOSE#0 is a documented action, albeit a largely undesirable one.

Changing an existing command in that way is probably out, because of the side effects. CLOSE#0 is a documented action, albeit a largely undesirable one.

I agree. When I’m testing an application and it bombs out with an error leaving files open, a simple f12 close ENTER ENTER gets it ready for another test.

At least *CLOSE only affects the current filing system and not things like network etc.

The use and syntax of CLOSE# is interesting. The warning in the manual only refers to the form CLOSE#0, not with a variable, and it says that it should not be used within programs except, possibly, during development. *Close has an identical action, so CLOSE#0 is really redundant. Even so, it would not be difficult to parse the zero form separately and still prevent the variable form from closing all files accidently and this would be backword compatible. In later versions of Basalt files in use are automatically closed on QUIT, so the question need not arise. ;-)

CLOSE#0 is really redundant

Isn’t CLOSE# just a front to OS_Find, 0 so changing the behaviour of CLOSE#0 is going to cause confusion?

I suppose there is an argument for it only closing files opened by BASIC, but that would require quite a substantial change so BASIC tracks open files – which isn’t as straightforward as it sounds without hooking into the filesystem vectors or hardcoding it into various BASIC commands and what happens when some machine code opens a file under BASIC? Sounds like more trouble than its worth.

changing the behaviour of CLOSE#0 is going to cause confusion?

Apart from development, how many CLOSE#0 statements exist in programs, except in error when the file hande variable is zero? CLOSE#0 in command mode can just as well be *Close. Anyway, I proposed that the exact form CLOSE#0 does not change its behaviour.

I suppose there is an argument for it only closing files opened by BASIC

I do not think there is any suggestion that CLOSE#0 should only close files opened by BASIC.

so BASIC tracks open files – which isn’t as straightforward as it sounds

It is true that files opened directly by SWIs, in SYS or assembler, would be tricky to keep track of, but files opened with the BASIC keywords are not. I have been doing that for years. ;-)

Just read this discussion with interest. I have had a similar problem. One of a group of programs was doing
CLOSE#X:X=0 twice. The second of course had the effect of CLOSE#0.

I read somewhere, years ago, that good practice in BASIC is to always use the form IF file% THEN CLOSE# file%

It has the added advantage that if the variable does not exist, it closes no files at all.

IF file% THEN
  CLOSE#file%
  file% = 0
ENDIF

Otherwise there is the risk that another app has opened a file with the same handle number, and you will close it if you call the same code again!

“I read somewhere, years ago, that good practice in BASIC is to always use the form IF file% THEN CLOSE# file%

It has the added advantage that if the variable does not exist, it closes no files at all."

It fails with “no such variable” if file% doesn’t exist.

It works if you use X% (or other single-uppercase-letter% variable, because these always exist – the resident integers so useful for saving memory on the BBC Micro.