File handles are rubbish

RPCEmu has far better mouse handling.

It is really unfortunate that every good feature in one emulator seems to miss in the other.

No, it’s a desktop. But when I used to use a laptop I think it was fine

So do you leave your desktop on 24/7? Or Shutdown overnight?
It used to be ok on my laptop – possibly pre Win8?

It is really unfortunate that every good feature in one emulator seems to miss in the other.

Indeed. One that had both networking and pointer handling would be a good start!

I have now updated my StopClose0 module to v0.03, see website , with thanks to nemo for his comments.

It now traps the *Shut command as well as *Close.

Firstly Martin, thank you. I owe you a refreshment of your choice.

Inspired by your efforts, and not wishing to carp further about gift horse’s teeth, I made one myself that was somewhat stricter about error handling, multiple instantiation, what the current FS is and other hand-wavy stuff only I’d care about. I gave it a good name. I made it an icon. I put it into my boot it and immediately forgot about it.

Then, researching how many programs actually implement DataOpen properly (specifically the undocumented bit… yeah well) this popped up:

If it had not been for your efforts Martin, I’d be stomping all over zip files again any moment now. Sincere thanks.

As for FormEd (not a program I use – I wrote my own you know), who writes this bobbins?

Bob says

Honestly, I’m sorry I even looked at FormEd…

The first of those is in the error handler. :-|

Honestly, I’m sorry I even looked at FormEd…

Wow. I knew FormEd was rubbish, but…

I wonder how much stuff like that is lingering in ancient code?

That’s interesting. I looked at my version of FormEd, and mine doesn’t have those awful programming errors. The first two have been commented out and the third one has been removed.

I know I’ve slightly edited my version (to add better control over sizing and positioning of icons), but did I make those changes too? I dunno. I doubt it.

The RunImage file is dated 2010. The version is given as 1.36.

This version claims to be 1.17d – so that’s seventeen revisions at least since being deemed suitable for release, presumably. :-O

I stress, I don’t use it. I was just trying every program I could find that responded to DataOpen. The downside of having done this kind of thing for a very long time is that some of the stuff I have is absolutely ancient.

I used a very useful program today that I wrote in 1991, for example.

About !FormED

The RunImage file is dated 2010. The version is given as 1.36.

That is the version I have here though the iconbar info shows 1.26, and can be found on the Nutshell CD as part of the Wimp Programmer’s Toolkit.

ROOL added their !FormED to cvs in 2016 as version 1.27, now on git

The over enthusiastic *CLOSE calls are REM’d out.

nemo wrote:

I made one myself

If it is an improvement on mine, can you put it on your website? Mine was only experimental, and I am quite happy top retire it if there is something better.

!FormED progress.

IF NOT(_bob% = 0)

Is If Not Equals Zero written like that quicker than IF (_bob% <> 0) ?

!FormED progress.

Fixing !FormED feels a bit like fixing !Edit.

Fixing !FormED feels a bit like fixing !Edit.

I like FormEd. I’ve tried TemplEd and Glazier, and I found them very difficult to understand and work with, whereas FormEd is straightforward.

I did enhance my version so I could access width, height, X position and Y position in writable menu items, and I much prefer that way of working to the alternative of dragging stuff around until it looks about right.

The only improvement I’d like is to stop the occasional crash, which looks random and unpredictable to me. I haven’t experienced a crash for a long time now, though.

I like FormEd. I’ve tried TemplEd and Glazier, and I found them very difficult to understand and work with, whereas FormEd is straightforward.

Have you tried WinEd? I find it very good.

If Not Equals Zero

What the programmer meant was IF_bob%:

This is just about the oldest program I still use every week:

Some time ago, Martin asked

can you put it on your website?

I’m sorry, I forgot about this. It is here.

There is an argument for protecting a file handle opened in Task A from being touched by Task B, but that’s a more complicated thing to enforce than the cycle number wheeze.

I might be over-simplifying, but would this not be easily (ish) done by making file handles specific to the process that opened them? CLOSE#0 then closes only that process’s files.

Does anything rely on using a file handle opened by something else?

specific to the process that opened them?

That applies to a tonne of things – file handles, current font, graphics context, cursor, origin, GBPB scan position, VDU “font”, etc etc etc. And that’s not even accounting for the things the Wimp messes with in the normal course of execution.

CLOSE#0 then closes only that process’s files.

I vote to disable CLOSE#0 entirely. There are enough tools around to itemise (and optionally close) lingering file handles, so it ought to be obvious which application is leaving files behind (sometimes unavoidable in a crash) in order to notify the author.
I don’t see any sensible reason, ever since RISC OS gained “multitasking” to have to issue a CLOSE#0.
That call belongs in the era where annoying games would unplug modules, mess with system configuration (font cache size, RMA size, etc) and then force a reset… and never bother to restore things on exit. CLOSE#0 belongs right there with that nonsense.

I’d have agreed with you right up to the point that Martin suggested this solution. See my previous “I’m in charge here” attitude for why. Confirmation is good. Prohibition is bad.

See my previous “I’m in charge here” attitude for why. Confirmation is good. Prohibition is bad.

Disagree (obviously!).

There’s no sensible reason to have a program be able to issue CLOSE#0 to close all files in this day and age; moreso given that it could be done by accident by closing a previously closed and nulled handle…

If you want to be God, and no reason why not, there’s always *Shut or OS_FSControl, 22that will do the exact same thing.

So, I maintain, CLOSE#0 should be faulted.

*Shut does not do the same thing as CLOSE#0.

Now, OK, your RISC OS can’t do this, but this is more useful than *Shut.

Related to handles, I remember back when I did a various bits of Econet programming, back in 3.1 days. I’d end up with file handles and Econet handles open.

If you tried to use one when it wasn’t open or whatever you’d get the helpful message of “Channel?” but you had no indication if it was a file handle or an econet handle .. fun times.