!Zap 149 Does triple click no longer selects the line?

I have !Zap 1.48 tnk-7 on 5.23 on pi3B and triple clicking selects the line the cursor is in. (Also on my SA RPC 4.39)

I am upgrading to Pi3B+ with Zap 1.49 rick-05 on 5.24 and triple click appears to select in sequence various other parts of the file but never at all the current line.

Do other people see this too? Is it an option or have I botched the migration in some way?

Many thanks

Alan

This appears to be a known issue

I still use !Zap 1.45 on 26bit platforms.

I am still using !Zap 1.48 tim-01, which works correctly on the ARMv8

The tim-01 release works correctly? I’ll need to diff this.

though is still 1.48.

The version bump is because there were too many incarnations of 1.49.

I do not like the changes to the UI that were made for the current 1.49 version, it is not very !Zap.

The changes were to try to make the menu structure more logical as display options, for instance, were all over the place.
If you like the old cluttered way, just copy your UK menu file back. It’s inside ZapUser someplace (I’m at work so can’t look it up).

If you like the old cluttered way

I wouldn’t say I like it, but I’m used to it, and it works. Everything I’ve wanted to do with it so far worked okay, anyway. I’d need more motivation to actually bother to change anything. Likewise I’m still on RISCOS 5.23. Everything’s working…

The tim-01 release works correctly?

No, it doesn’t. [just tried all the versions I have on the Pi2]

tnk-11 works. tim-01 does not. Does anybody know if there were any versions in between?

which works correctly on the ARMv8 though is still 1.48.

Did you pick up my ZapMJE patch? Because colourised code probably won’t work on the Pi3 due to loveliness like STR r10,[r10,#-4]!.
Elsewhere – ZapObey’s non-word-aligned code offset, a SWP instruction in the printing code, Tab handler crashiness fixed, and some other stuff like fixes for character spacing being wrong.

just copy your UK menu file back. It’s inside ZapUser someplace

$.ZapUser.Config.Menus → it’s the one call “UK”. Ignore the “Source” as the menu generator can’t be built at this time (some dependency that doesn’t work – perl?).

Your choices:

• Old Zap (you’ll find it in any older Zap release)
• Rick’s reworking (in Zap Ultimate v1.49 etc)
• nemo’s way (posted to the forums, a search ought to find it)
• And, of course, a tweak-it-yourself job.

I wouldn’t say I like it, but I’m used to it, and it works.

;-) I know the feeling. I just couldn’t handle looking here for font, looking there for window width, and looking over there (somewhere behind the sofa) for options to set up word wrapping. So I’ve tried to make the menus more logical, plus more in keeping with how Edit arranges its menus (Save, Select, Edit, Display…) so it should be more familiar.

Likewise I’m still on RISCOS 5.23. Everything’s working…

Yes. Plus I’m a bit spooked by the sudden violent objections of the HidePtr module without a clear and evident cause. Essentially put – it’s a weird bit of code that has worked since 3.10 that suddenly goes very wrong on 5.24+. I’d like to know why. What’s changed to cause this to happen? I’m also somewhat less amused by the overzealous nannying of checking the flamin’ bits in the error number part of error blocks. Sure, throw a fault if it’s a bogus pointer, but to go as far as to ensure bits (what – 24 to 30 or something?) are zero and fault if they aren’t – does this not seem self defeating in that essentially these bits could never be used in the future lest existing versions of RISC OS that might be floating around choke on the non-zero-ness?
Plus, it’s a PITA to download the tarball, merge in my changes, and build the ROM. I only do it periodically, which is why I’m still stuck on 5.23 build on 8th August 2017. <shrug> It’s over a year old, I guess I ought to update sometime soonish…
…apart from intermittant rrrrrrrepeating keys (no obvious origin, but worse in Zap than NetSurf for some reason), everything works okay. My uptime is 19 days, 0 hours, 21 minutes and 14 seconds. It would have been (much) more, but I powered down because of a risk of thunderstorms in the area…

My uptime is well over a year now. And no repeating keys, so I presume that’s at least partly a hardware issue?

so I presume that’s at least partly a hardware issue?

No idea. It’s a cheap generic keyboard and the Pi is running off a decent enough power supply. No rainbow graphic or anything. I believe there is a USB fix sometime in the past year that should improve the situation, so it might be either an edge case thing or just something with a crappy USB implementation.

*USBDevices
No. Bus Dev Class Description
  1   1   1  9/ 0 Synopsys DWC OTG root hub
  2   1   2  9/ 0 SMSC SMSC9514 USB Hub & Ethernet device
  3   1   3 FF/ 0 SMSC SMSC9512/9514 USB Hub & Ethernet device
  4   1   4  0/ 0 Prolific Technology Inc. USB-Serial Controller
  5   1   5  0/ 0 Logitech USB-PS/2 Optical Mouse
  6   1   6  0/ 0 USB USB Keykoard
*

Given their apparent inability to manage to spell the name of their product (!), I’m not sure I’d trust them to be capable of following a spec. At least it “mostly works”. ;-)

Vendor ID is 1C4F, product 0002. Manufacturer text is “USB”, product text is “USB Keykoard”. It follows USB spec 1.10 and claims 98mA. There’s a keyboard device (endpoint 1, 8 bytes) and an HID device (endpoint 2, 3 bytes) because the keyboard has three extra keys – Power, Sleep, and Wake Up.
As expected, the extra keys are invisible to RISC OS.¹ Ho hum, maybe we ought to have a bounty to build basic HID support into the USB system so the kernel/apps can ‘see’ these extra keys?

¹ https://www.riscosopen.org/forum/forums/11/topics/11678?page=2#posts-80811

I have no trouble with text coloring.

In C or assembler?

Can you do *Help ZapMJE? [it’s the ZapMJE module that colourises C/assembler]

Tnk-11 crashes for me on the ARMv8 whith the Obey files

ZapObey was broken. At +&244 in the module, following data tables, is the string “ZapObey:Menus”,0 and the Initialisation code was specified as directly following that, at address +&252, which you can see stored in the word at offset +&170. The code itself is correct, the assembler inserted padding to keep the code word aligned, but it wasn’t smart enough to alter the branch label accordingly (or, what it probably should have done – throw an error), so the jump location was to a non-word-aligned address. It’s quite likely that the older ARM cores would have simply ignored the two lower bits of any address pushed into PC. Thus, the only side effect would have been to execute the final “s” of the menus string (which is ANDEQ R0,R0,R3,ROR R0…).
Fast forward to more capable ARM cores with stricter changing for… what would Clive call this? “UNDEFINED”? “STUPID”? ;-) Telling the processor to jump to address +&252 would cause the processor to stop and say “do WHAT”? So, there you go. Older versions of ZapObey were broken. And older ARM cores didn’t care.

tnk-11 works. tim-01 does not. Does anybody know if there were any versions in between?

It looks like Tim’s first version was to fix ZeroPain by inserting checks for ‘deleted files’ as described here. I’m guessing that one of those might be affecting the text selection logic?

Hmmm… As André observes, he’s not figured out why calls were being made on “deleted” documents, and I’d echo that. It seems a weird thing to need to check for…

Warning, old thread and bug resurrection! Although this thread go rather diverted from the topic last time.

I’ve just updated to Zap rick-07 and the problem with triple click is still there :-(

It seems to select everything from the 2nd line of the file down to the line above the one clicked on. A fourth click then correctly selects the current paragraph.

Using ARMX6, RO 5.25 (25-Apr-18)