Saving user settings for Edit

Has anybody else noticed that recently Edit is not setting its display width to user settings correctly.

I’m running a Pi 3 booting from a FAT32 SD card to a USB attached harddrive with my preferred settings for Edit (colours, font, font size and display width) saved as an Obey file in Boot.Choices.Boot.Tasks. Yesterday I download and installed the BCM2835Dev image (dated 9 July 2019) and found that trying to load a text file into Edit produced a long, thin window, the display width showing as -16, the font, etc looked OK. Trying today’s image caused the same long thin window. I also updated the HardDisc4 to todays version. Creating a new file in Edit opened a window that looked very wide, but as soon as I tried to resize it, it transformed into a long, thin window.

I rolled back to an image dated 3 July and the same file open up correctly.

Looking through my printed RISC OS 5 User Guide I found that it described using a Desktop file saved in Boot.Choices.Boot for user preferred settings. This I did, but although it contained the correct value for the display width in the resulting file it didn’t seem to be applied. The font/font size, etc was OK.

Is it just me?
If it is, help please.

I have noticed here that Edit won`t save the BASIC option to not `Strip Line Numbers`

Version number here is 1.73

Has anybody else noticed that recently Edit is not setting its display width to user settings correctly.

On a Titanium, with RISC OS 5.27 (16 Jul 2019):-

Setting Edit$Options from the command line and restarting !Edit does show the issue.

*set Edit$Options A32

The above gives a negative ‘Work Area’ value and a thin window on a resize window drag.

It is OK on RISC OS 5.27 (03 Jul 2019)

Edit is at the same version, 1.73 (03-Apr-15), on both ROMs.

Wrong answer. Deleted.

#define txt1_MAX(a,b) ((a)>(b)?(b):(a))

I’m certain you don’t mean that.

I’m certain you don’t mean that.

Oops!! Previous answer deleted.

The ‘thin window’ thing looks to be associated with RISC_OSLib 6.02. More specifically RISC_OSLib.rlib.c.txtar. A build that reverted to the version from 6.01 evaded the issue. That is as far as I get, I don’t have enough C to see what the real problem is.

HTH.

Yeah, that looks like it would be the problem. It’s been caused by replacing the min/max functions with macros, which causes some of the parameters to be evaluated multiple times (which isn’t a good thing if your parameters have side-effects, like txtar__readoptnum).

I’ve just downloaded and installed today’s (28 July) Beta RPi ROM and it looks as though the long thin widow problem has been banished.

So ‘Thank You’ to David Pitt and Jeffrey Lee for their investigations, and to whoever fixed it.

Is that long thin widow one of Hoffnung’s French widows in every bedroom, who offer delightful prospects?