RISC OS Open
A fast and easily customised operating system for ARM devices
ROOL
Home | News | Downloads | Bugs | Bounties | Forum | Documents | Photos | Contact us
Account
Forums → Code review →

Wimp_LoadTemplate Handle error

Subscribe to Wimp_LoadTemplate Handle error 37 posts, 13 voices

Posts per page:

Pages: 1 2

 
Sep 9, 2018 11:04am
Avatar Rick Murray (539) 7570 posts

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. ;-)

 
Dec 4, 2018 8:59pm
Avatar Alan Adams (2486) 49 posts

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.

 
Dec 4, 2018 9:16pm
Avatar John Williams (567) 635 posts

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?

 
Dec 4, 2018 9:37pm
Avatar Steve Drain (222) 1057 posts

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. ;-)

 
Dec 4, 2018 10:54pm
Avatar Steve Fryatt (216) 746 posts

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.

 
Dec 5, 2018 9:13am
Avatar Chris Hall (132) 2414 posts
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.

 
Dec 5, 2018 10:53am
Avatar Steve Drain (222) 1057 posts

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. ;-)

 
Dec 5, 2018 1:28pm
Avatar Jon Abbott (1421) 1771 posts

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.

 
Dec 5, 2018 2:02pm
Avatar Steve Drain (222) 1057 posts

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. ;-)

 
Dec 7, 2018 3:41pm
Avatar John Sandgrounder (1650) 372 posts

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.

 
Dec 7, 2018 3:55pm
Avatar Dave Higton (1515) 1820 posts

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!

 
Dec 10, 2018 12:06pm
Avatar Alan Adams (2486) 49 posts

“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

Reply

To post replies, please first log in.

Forums → Code review →

Search forums

Social

Follow us on and

ROOL Store

Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.

Donate! Why?

Help ROOL make things happen – please consider donating!

RISC OS IPR

RISC OS is an Open Source operating system owned by RISC OS Developments Ltd and licensed primarily under the Apache 2.0 license.

Description

Developer peer review of proposed code alterations.

Voices

  • Rick Murray (539)
  • Alan Adams (2486)
  • John Williams (567)
  • Steve Drain (222)
  • Steve Fryatt (216)
  • Chris Hall (132)
  • Jon Abbott (1421)
  • John Sandgrounder (1650)
  • Dave Higton (1515)

Options

  • Forums
  • Login
Site design © RISC OS Open Limited 2018 except where indicated
The RISC OS Open Beast theme is based on Beast's default layout

Valid XHTML 1.0  |  Valid CSS

Powered by Beast © 2006 Josh Goebel and Rick Olson
This site runs on Rails

Hosted by Arachsys