Re: [ARMini-support] SideDiff

  • From: Harriet Bazley <harriet.bazley@xxxxxxxxxxxxxxxx>
  • To: ARMini support <armini-support@xxxxxxxxxxxxx>
  • Date: Mon, 11 Apr 2016 21:51:40 +0100

On 10 Apr 2016 as I do recall,
          Bernard Boase  wrote:

On 10 Apr, john@xxxxxxxxxxxxxxxx typed:

Using SideDiff on AMX6 I get an error message: Undefined font handle
at line 3381, though if I ignore that the window opens and seems to
work.

Same here, whatever font is set in Choices. Indeed bringing up the
Choices menu also gives the similar message "Undefined font handle at
line 3385", as does attempting to change the font via the Choices
dialogue.

So I set the font manually by editing Choices:SideDiff.

(I am using SlidingHeap 2.12 and have implemented the change from
arithmetic shift right to logical shift right in FONT_Lib in SideDiff
2.44 mentioned by Steve).

I am copying this to Harriet in case she hasn't seen this thread yet.
(Apologies if you have).

I hadn't - but this sounds rather like the elusive input-dependent bug that
Christopher tracked down, which only manifests on the latest versions of the
OS.   It turned out to be triggered by using Font_ScanString to calculate
the width of a string which contains a tab character, since apparently
CHR$(9) counts as a 'special character' in strings passed to the Font_ SWIs.
Unfortunately it's also an extremely common character in diff input; so
common that diff actually offers the option to convert all tabs to
fixed-width spaces (see the 'Diff' section of the Choices window).

If setting this option fixes the issue, then that's probably the bug.
Alternatively, configuring SideDiff to use the system font would probably
have the same effect.
But being unable to use Font_ScanString or Font_Paint in a program that
displays text via outline fonts is not a very easy thing to work around.

The bug *only* raises an error under certain versions of the OS:   earlier
ones presumably take a look at the data following the tab character, decide
that it isn't valid input and ignore it - they certainly don't 'eat' the
three following characters as the control character definition would suggest
 9  dx low,middle,high  : Move print position horizontally

And it only shows up  only when certain data follows the tab character,
which makes it quite consistent across a given input file but very
intermittent across normal usage of the program :-(

I could simply force the 'Expand tabs' option to be permamently on, but this
has the unfortunate side-effect of corrupting the input file if you attempt
to 'write back' any edits....   So I've worried about it and done nothing.

-- 
H. Bazley

Violence is the last refuge of the incompetent.
---
To alter your preferences or leave the group, 
visit //www.freelists.org/list/armini-support
List-related queries to info@xxxxxxxxxxxx

Other related posts: