StrongHelp 2.89 released

I’m pleased to announce that StrongHelp 2.89 is now available from my website: http://www.stronged.iconbar.com/fjg/

Changes from 2.88

Changes to the !Boot and !Run files introduced a couple of issues. The lines to set the filetype name for manuals got lost, and Obey$Dir no longer matched StrongHelp$Dir by the time the code got to read it. The latter problem meant that StrongHelp couldn’t find !Manuals when it was in the same directory as StrongHelp.

The messages file was moved from application space to the RMA so that the module part of StrongHelp could use tokens too for textual messages. Unfortunately the messages file wasn’t closed when StrongHelp was quit, something that you get away with when using application space but not when using the RMA.

When a page is closed with Adjust, the parent page is opened and the pointer placed over its close icon. A refactoring introduced a bug causing the pointer to over the back icon instead under certain circumstances.

Sometimes StrongHelp’s main menu page got corrupted (manual name truncated or icon missing). This was ultimately tracked down to a spurious write caused by a flexpointer going stale.

Replaced internal references to Obey$Dir with StrongHelp$Dir. This because Obey$Dir may have been changed since setting StrongHelp$Dir due to other Obey files being called during startup.

Added a new subroutine to read and store mode variables, called on initialisation and mode changes. The code was changed to use the stored values instead of using SWIs to read them each time they were needed.

Fixed issues with tiled backgrounds, tile sprites with eigen values > 1 were being plotted squashed. Use OS_SpriteOp 65 if available else use the old manual tiling (which has been optimised).

Fixed abort that could occur on changing to a screen mode with different eigen values. It would happen if any help pages were open that displayed sprites.

Fixed redraw issue with sprites that have different eigen values from the screen mode. Dragging a window over such sprites would could cause them to only be partially redrawn.

26-bit !Pre files

Although StrongHelp itself has been updated to run on modern CPUs, a number of manuals still contain a 26-bit !Pre file. !Pre files are used to assist with keyword lookups, eg by stripping the leading ‘X’ from SWI names.

A 26-bit !Pre file can cause an abort on modern CPUs depending on how tolerant it is of deprecated instructions. The ARMiniX seems to be okay with it but the RPi 3 definitely is not.

If you do get an abort when performing a lookup (Iconbar menu or F1 in StrongED / c-H in Zap) then it’s most likely down to a 26-bit !Pre file. You’ll need to find it and replace it with a 26/32-bit neutral version.

Included is an updated !Pre file for use in manuals that document SWIs. Please be sure to read the ReadMe in the Pre-files first.

Hi Fred. there is something strange here.
Some manuals, as AppBasic or Basil, crash on several pages. No problems on Pi3 with StrongEd 2.87.

Thanks for reporting this. Fortunately it’s a bug that I’d already found and fixed. :-)

Cool :)

I find that StrongHelp 2.89 crashes on the VFP, FFmpeg, POPStar, Reporter, RFSFiles, TemplED and BASIC manuals (RO 5.23 on an Rpi2).

For Reporter – and probably the others – if you replace the !Pre file in the manual with the one supplied with SH v2.89 I think all should be well.

StrongHelp 2.89 crashes on the VFP, FFmpeg, POPStar, Reporter, RFSFiles, TemplED and BASIC manuals

All these manuals, except Reporter, try to display sprites but the sprite can’t be found. Either because the manual has no Sprites file in it or the sprite isn’t in the Wimp sprite pool (app not booted).

Changes in v2.89 caused StrongHelp to abort in such cases. This has been fixed in v2.90 which opens these manuals just fine.

Thanks Fred.

My manuals – VFP, RFSFiles, Basil, Basic etc – do indeed use an empty ‘Sprites’ command to force pages to a fixed width, in the absence of any other way to do that. I think that the algorithm calculating the page width in StrongHelp does not do a very good job. ;-)

My manuals – VFP, RFSFiles, Basil, Basic etc – do indeed use an empty ‘Sprites’ command to force pages to a fixed width,

Thanks for the clarification Steve I’d been wondering why you’d put that in.

I think that the algorithm calculating the page width in StrongHelp does not do a very good job. ;-)

I agree that it would be nice if there was some way of dictating a minimum width. Pages with little text are often made too narrow making less easy to read.

What StrongHelp has always needed is a way to set a right margin. #Indent is OK for left margins only.

I agree that it would be nice if there was some way of dictating a minimum width.

That is the easy bit. Use #Sprite <width>,0 with no name to set a minimum width. I do things slightly differently in later manuals, though.

However, StrongHelp may calculate a greater width than this if there are paragraphs with a lot of text or many paragraphs. The aim of the algorithm seems to be to put everything on a page that will fit the screen ¹, but that may be because it was written in the days of 640×256 screens.

To ensure that the width is the same as the #Sprite command I define a font 4 points wide, select that on the last line, followed by LF. That makes the algorithm calculate what I want. Devious, but effective. ;-)

Just after Guttorm made the source available I studied the code with a view to writing a #Width command. I got to the point of being able to set a width, but never worked out how to write new commands at that time.

¹ Lines of text that are too long are more difficult to read.

I agree that it would be nice if there was some way of dictating a minimum width.

That is the easy bit. Use #Sprite ,0 with no name to set a minimum width.

Since that is the origin of the problem Gavin described I’m inclined to suggest that “solution” is most definitely not a good idea.