Wimp_LoadTemplate Handle error
Pages: 1 2
|
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”]
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. |
|
Just read this discussion with interest. I have had a similar problem. One of a group of programs was doing |
|
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? |
|
One of the first things I implemented 15 years ago in the Basalt extension to BASIC was just this. ;-) |
|
All of the affected handles are open… that’s the whole problem.
Changing an existing command in that way is probably out, because of the side effects. |
|
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 |
|
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. |
|
Apart from development, how many
I do not think there is any suggestion that
It is true that files opened directly by SWIs, in |
|
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 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. |
Pages: 1 2