RISC OS 5.30 Task window error
Michael Foot (8087) 14 posts |
I’ve recently updated to RO 5.30 on a Pi 3B and spotted this error occurring when bringing up the task window on the desktop. |
David Pitt (9872) 362 posts |
Is this with Zap? If so see here for a similar report. |
Michael Foot (8087) 14 posts |
Thanks for that link. Zap is on the the machine but not running when this happens. I’ll try the updated version and see if that helps. It’s also strange that the 2nd time I open the task window it works just fine. |
David J. Ruck (33) 1629 posts |
What editor is responsible for managing the task window? |
Michael Foot (8087) 14 posts |
I just updated Zap to the latest and that has cured the problem. Good to know. Thanks all. |
Steve Pampling (1551) 8154 posts |
Just to note – for future readers – Drucks question is very relevant:
Basically the default editor for the system will be managing the task window, be it Edit, Zap, or StrongED, and even when not visible on the taskbar a bug in the editor can cause errors in the task window startup or operation. |
David Pilling (8394) 96 posts |
I’ve been wondering about this for a while, and this seems a convenient place to ask. When programming on RISC OS, I miss the history feature for command lines that is typical on Linux etc. You know type a command line, find there’s something wrong with it, and all you have to do is press up arrow to have another go, as opposed to typing the whole lot again. In 1988, someone I knew did a module for the Archimedes OS 1.2 command line (plain F12) that allowed this. I wonder about doing it for task windows – are there hooks somewhere. I’ve found mentions of ShellC by MartinWurthner – of course the actual software is vanished – so no idea if it is relevant. |
Piers (3264) 42 posts |
Why wouldn’t the F12 version work in a taskwindow? I wrote one years ago – I’m sure it worked fine both in a task window and not. You’re probably thinking of Olly Betts’ module rather than mine, though, as I’m not even sure I put it anywhere. Maybe Arcade. |
Richard Walker (2090) 431 posts |
This is the magic: https://github.com/philpem/LineEditor Stick it in PreDesk. |
David Pilling (8394) 96 posts |
Thanks. The ReadMe tells that it was based on a line editor written by Richard K Lloyd, which is the one from the past I was thinking of. It is a new implementation by Olly Betts then Darren Salt.
I don’t understand how the command line interacts with the text editor, from that point of view why would it work. In the ReadMe for the line editor above there is plenty of discussion about things occasionally not working with task windows. I should learn how to use Google. My logic was if such a thing exists it will be supplied as standard with RISC OS. |
Steve Pampling (1551) 8154 posts |
Seems perfectly logical. Unfortunately, logic doesn’t always seem to apply. |
Charles Ferguson (8243) 427 posts |
You might also be interested in https://github.com/gerph/linenoise – I ported another line editor which was written in C, because the LineEditor that we know and love is all in BASIC assembler, and that makes it far less useful for maintenance, updates, etc. LineNoise isn’t as featureful at LineEditor, but it is significantly more manageable, being written in C and more easily testable without having to replace ReadLine. Feel free to have a play with it as well, and PRs are happily received – that’s why it’s open source. |
Charles Ferguson (8243) 427 posts |
TaskWindows only provide you character input and output. They fake (through… stuff) some of the character input and output operations, but because the process model on RISC OS is non-existant, their faking is incomplete. As such, the ‘read position’, ‘read size of screen’, and similar, won’t work the way they are expecting. Similarly, the changing of key input doesn’t always work the right way (function and cursor effects might not be exactly the same) – and of course the controlling system may be using some keys for its own purposes. You can’t (for example) reliably say ‘Is ALT pressed’ by calling INKEY in a taskwindow because the key may have been released, or if the TaskWindow was being driven remotely, there may not be any ‘keys’ pressed. Then there are the effects of the output which might not be supported by the output application. For example, you might assume that There’s many reasons why TaskWindows causes problems because of how it has to operate, and LineEditor (and their ilk) hit these for some cases. |
David J. Ruck (33) 1629 posts |
My !GraphTask graphic task windows addresses some of the problems by emulating the VDU system in numbered modes to a certain extent. But it doesn’t get around the problem that when the task window task is running most SWIs will read attributes of the desktop screen as explained above. It does translate mouse position for the task though. |
David Pilling (8394) 96 posts |
Interesting. TBH, I failed to get it to build …module.Makefile (around line 49) (not worth anyone worrying about my problems with the Acorn C tools, me included). |
Bryan Hogan (339) 589 posts |
Note that LineEditor comes with Zap (and is loaded automatically IIRC). This combination works well as Zap handles the cursor movement stuff and cut/paste very well, plus it intercepts the screen width calls so that programs think the screen is the width of the window and hence format their output correctly. (If Fred is listening, this would be a great feature to add to StrongEd!) |
David Pitt (9872) 362 posts |
In my defence I admit to being a StrongED user and though LineEditor does work with StrongED it is not something I have not made much use of. However a simple way of correcting all my spelling mistakes at the command line has its attractions. My copy of Zap, rick-07, has an old LineEditor. *help lineeditor ==> Help on keyword LineEditor Module is: Line Editor 2.76d (03 Mar 2003) [test version - don't distribute without permission] Olly Betts The LineEditor module is here, | | Line Editor boot file | RMEnsure LineEditor 0.00 X RMLoad ZapExtensions:LineEditor.LineEditor 16 2_0000011 2 0 &1000 Set CLI$Prompt <17><1>* Set LineEditor$Edit <17><2> Set LineEditor$List <17><3> Set LineEditor$Type <17><4> Set LineEditor$Output <17><5> For use with StrongED a user automatic load can be included in | User specific initialisation | Here you can add commands to perform additional initialisation RMEnsure LineEditor 2.78 RMload SCSI::SSD120.$.Progm.Editors2.LineEditor Currently the module is in an arbitrary location in my disc image, as a shared resource !System might be more appropriate. There is no StrongED setup as there was with Zap, though it could easily be added if necessary. |
Charles Ferguson (8243) 427 posts |
Ah, that’ll be because it uses my build system, so you won’t have a bunch of things defined, or the makefile headers. I do keep meaning to do a release of the build environment, but it’s not been that much of a priority. I’ll set up an automated build for it later so that there’s an external build. I thought I’d already done that, to be honest. Oh, I did… they’re in the Releases section – https://github.com/gerph/linenoise/releases |
Fred Graute (114) 645 posts |
Already done that. It’s present in the latest test release (StrongED 4.70a15). |
David Pilling (8394) 96 posts |
Thank you. I learnt something new. I had not taken in there is a releases section. I’ve tried release 0.02, and the history bit seems to work, but it always executes some other command to the one typed last. |
Charles Ferguson (8243) 427 posts |
That definitely sounds like I’m failing to return the thing that I actually had entered. Will look into that! |