Font_ScanString bug

I am getting an abort on data transfer when I try to scan a multi-line string, in fact a string which is being used as the text which fills a text area object to make sure the column height is sufficient to encompass the string:

!tem%=0
tem%!4=0
tem%!8=0
tem%!12=0
tem%!16=-1
tem%!20=0
tem%!24=0
tem%!28=0
tem%!32=0
SYS "Font_FindFont",,"System.Fixed",256,256,0,0 TO fh%
SYS "Font_ScanString",fh%,ptr%,&040020,,&287EE,&7FFFFFFF,tem%
-- Abort on data transfer at &FC2484E8 (offset &4D7C in FontManager)
ptr% -> (text follows)
\!1
\D1
\F3System.Fixed 10
\L12
\P10
\3
The last satellite fix was obtained at 18:49:15 no date (2).  RISC OS time not available.

\L14

Satellites (first twenty shown above in orange) were:
Satellite   elevation   azimuth     SN ratio
18:49:08 $GPGLL,,,,,184909.00,V,N
18:49:09 $GPRMC,184910.00,V,,,,,,,301016,,,N
18:49:09 $GPGGA,184910.00,,,,,0,00,99.99,,,,,,
18:49:09 $GPGLL,,,,,184910.00,V,N
18:49:10 $GPRMC,184911.00,V,,,,,,,301016,,,N
18:49:10 $GPGGA,184911.00,,,,,0,00,99.99,,,,,,
18:49:10 $GPGLL,,,,,184911.00,V,N
18:49:11 $GPRMC,184912.00,V,,,,,,,301016,,,N
18:49:11 $GPGGA,184912.00,,,,,0,00,99.99,,,,,,
18:49:11 $GPGLL,,,,,184912.00,V,N
18:49:12 $GPRMC,184913.00,V,,,,,,,301016,,,N
18:49:12 $GPGGA,184913.00,,,,,0,00,99.99,,,,,,
18:49:12 $GPGLL,,,,,184913.00,V,N
18:49:13 $GPRMC,184914.00,V,,,,,,,301016,,,N
18:49:13 $GPGGA,184914.00,,,,,0,00,99.99,,,,,,
18:49:13 $GPGLL,,,,,184914.00,V,N
18:49:14 $GPRMC,184915.00,V,,,,,,,301016,,,N
18:49:14 $GPGGA,184915.00,,,,,0,00,99.99,,,,,,
18:49:14 $GPGLL,,,,,184915.00,V,N

what is going on please?

Have decided it is simpler to scan each paragraph to detect width and work out how many line breaks it requires and just add them up – i.e. don’t venture into multi-line stuff at all. But I still think a valid OS call should not abort. That method seems to work OK.

SYS “Font_ScanString”,fh%,ptr%,&040020,,&287EE,&7FFFFFFF,tem%

What on earth are you doing there? The flags say you’re passing the spacing/split/bbox in R5, but R5 contains &7FFFFFFF. Definitely some user register jumblage going on.

But I still think a valid OS call should not abort.

It’s not valid.

But I still think a valid OS call should not abort.

Many parts of RISC OS will act badly on invalid input. So if something that unexpected happens, the first port of call should be to examine carefully the parameters being passed.

SYS “Font_ScanString”,fh%,ptr%,&040020,,&287EE,&7FFFFFFF,tem%

In cases like this, I prefer to use binary notation (like %010101…) or build the value in parts (like (3<<16)+(1<<22) ) because this makes it much clearer what is being attempted.

Your flags are %1000000000000100000, or bit 5 and bit 18. This means to use R5 as coordinate block on entry, bounding box on exit. Thus, as Sprow points out, &7FFFFFFF is an invalid address and the reason for the abort.

There are two commas after the &040020.Remove one of them, that should put things in the right places, assuming that &287EE and &7FFFFFFF are the width/height remaining on the current line (in millipoints)…

There are two commas after the &040020.Remove one of them, that should put things in the right places, assuming that &287EE and &7FFFFFFF are the width/height remaining on the current line (in millipoints)…

Many thanks – I feel rather embarrassed they are width/height (whether in Draw units or millipoints I can’t remember but I’ll check they are millipoints), ‘tem%’ is indeed intended for R5 and I seem to have put in one too many commas! I’ll try again.