StrongHelp 2.90 released

I’m pleased to announce that StrongHelp 2.90 is now available from my website

Changes from 2.89

• Now released as open source software under the 3-clause BSD licence.
   
• If a #Sprite command referred to a sprite that could not be found, SH would abort. The changed redraw code in v2.89 failed to catch this.
   
• Redraw changes made in v2.89 caused a vertical misalignment between text and sprite when small icons were used.
   
• Output StrongHelp warnings (those shown in a StrongHelp window) to SysLog so that there’s a record of such messages.
   
• Changed workaround to avoid running !Pre files unnecessarily, the old workaround had some issues. This allows manuals with a 26-bit !Pre to be opened on ARMv7.

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.

I am not sure how many times this topic has arisen before: what is the canonical way of providing a right margin for text in StrongHelp documents? Would it be difficult to extend StrongHelp with an extra page formatting command to implement a right margin? I have long felt that many StrongHelp documents look a bit naff having text right up to the right hand edge of the window.

I am not sure how many times this topic has arisen before: what is the canonical way of providing a right margin for text in StrongHelp documents?

Currently StrongHelp puts a margin of 8 OS units around a page. Increasing this is easy at source level as it’s just a single variable.

Would it be difficult to extend StrongHelp with an extra page formatting command to implement a right margin?

That’s a more difficult question to answer. The code that lays out a help page is not easy to read; lots of large routines with little or no comments. There is no documentation describing the layout engine either.

Previous maintainers haven’t really touched the layout code, probably for the above reason. Having worked on all 3 of Guttorm’s ‘Strong’ applications, I find StrongHelp by far the hardest to get into.

Anyway, I’ll have a look at providing a way to control the size of the right margin. A page formatting command would be one option but it might be more convenient to set this up via the !Configure file so it applies to all pages.

Good. It might be possible to implement without touching the layout code, if one is content with an integral number of character-widths, by insertion of blank spaces at the end of lines. Alternatively, can one play layout tricks with sprites? I seem to recall that one can force the width of a Stronghelp window by having a blank sprite at the top.

The code that lays out a help page is not easy to read; lots of large routines with little or no comments. There is no documentation describing the layout engine either.

It is a very long time ago that I traced this code and I could certainly not understand it now. I got as far as working out how to force a fixed width, but only by by-passing the engine. I think the purpose was to include all the information on the screen, when screen sizes were small.

Alternatively, can one play layout tricks with sprites? I seem to recall that one can force the width of a Stronghelp window by having a blank sprite at the top.

I cannot see a way to use #sprites to create a right margin, but I do use a blank sprite and a narrow font to force/fool the engine to make pages a fixed width. I think I understood why it works, too. ;-)

A #width command would be much better.