Discussion:
Font problem
(too old to reply)
Alan Adams
2019-05-10 18:25:04 UTC
Permalink
Hi

I'm struggling with a mysterious problem.

I have a BASIC program which can be launched three ways - run directly, or
run via Wimp_StartTask from one of two different programs. When it is
launched via one of those programs it changes the desktop font to the
System font. This occurs if the launching program starts up using "run at
startup" but not if it is run manually.

(This is a bit over-simplified - I can reproduce the problem using the
above, but I have seem intermittent effects affecting the font on other
occasions.)

It uses a pane window which contains a varying number of icons. This
problem occurs just after the number of icons is increased from 1 to 3 by
copying the first one downwards.

Within the code, the change of font occurs at the first Wimp_Poll, which
is after the windows are manipulated and opened.

If Organiser is running at that point it crashes with "invalid font
handle".

When the launched program puts text into some of its icons, no text is
displayed.

This program is the only one of my set to use a specified font in its
icons, so this could be related. The Wimp_LoadTemplate does contain a
pointer to a 256 byte font handle block, which has been initialised with
0's first. I have tried DIMming unused blocks before and after this, with
no effect on the results. I've tried increasing the Wimp slot, and
increasing the size of all the buffers used in manipulating the windows.

My suspicion, as always in such cases, is to suspect that something I am
doing is overwriting memory somewhere. Can anyone come up with a reason
for the desktop font change to be the result?
--
Alan Adams, from Northamptonshire
***@adamshome.org.uk
http://www.nckc.org.uk/
Alan Adams
2019-05-10 18:35:27 UTC
Permalink
Post by Alan Adams
Hi
I'm struggling with a mysterious problem.
I have a BASIC program which can be launched three ways - run directly, or
run via Wimp_StartTask from one of two different programs. When it is
launched via one of those programs it changes the desktop font to the
System font. This occurs if the launching program starts up using "run at
startup" but not if it is run manually.
<snip>
Post by Alan Adams
My suspicion, as always in such cases, is to suspect that something I am
doing is overwriting memory somewhere. Can anyone come up with a reason
for the desktop font change to be the result?
This is being tested on a Raspberry pi running RO 5.23 (13-Apr-2017).
CPU is set to ARMv7 strict mode.
--
Alan Adams, from Northamptonshire
***@adamshome.org.uk
http://www.nckc.org.uk/
Alan Adams
2019-05-10 19:19:13 UTC
Permalink
Post by Alan Adams
Post by Alan Adams
Hi
I'm struggling with a mysterious problem.
I have a BASIC program which can be launched three ways - run directly, or
run via Wimp_StartTask from one of two different programs. When it is
launched via one of those programs it changes the desktop font to the
System font. This occurs if the launching program starts up using "run at
startup" but not if it is run manually.
<snip>
Post by Alan Adams
My suspicion, as always in such cases, is to suspect that something I am
doing is overwriting memory somewhere. Can anyone come up with a reason
for the desktop font change to be the result?
This is being tested on a Raspberry pi running RO 5.23 (13-Apr-2017).
CPU is set to ARMv7 strict mode.
I've now set up a pi using the 5.24 disc image download. The results are
the same. Does this have page zero protection? If so does it need to be
turned on, and if so, how?
--
Alan Adams, from Northamptonshire
***@adamshome.org.uk
http://www.nckc.org.uk/
Matthew Phillips
2019-05-10 20:21:39 UTC
Permalink
Post by Alan Adams
If Organiser is running at that point it crashes with "invalid font
handle".
This suggests to me that something is closing a file handle which is in use
by the Font Manager. Does your application to CLOSE# with a filehandle that
is stale or which might have been corrupted?

If there is a CLOSE# command anywhere in the code that has been executed
before this problem, try commenting it out and see if it makes a difference.

I could be wrong though. I'm not sure how the Font Manager keeps track of
file handles.
--
Matthew Phillips
Durham
Harriet Bazley
2019-05-11 00:20:08 UTC
Permalink
On 10 May 2019 as I do recall,
Post by Alan Adams
I have a BASIC program which can be launched three ways - run directly, or
run via Wimp_StartTask from one of two different programs. When it is
launched via one of those programs it changes the desktop font to the
System font.
This definitely sounds as if the desktop font handle is being closed
erroneously by your program - are you manipulating any file handles
(e.g. in an error-handling routine)? Or using Font_LoseFont and
possibly passing the wrong value to it (again, typically in error
handling)?
--
Harriet Bazley == Loyaulte me lie ==

You cannot propel yourself forward by patting yourself on the back.
Paul Sprangers
2019-05-11 12:28:07 UTC
Permalink
When it is launched via one of those programs it changes the desktop
font to the System font.
Completely agree with Matthew and Harriet. It happened to me too, until
someone told me that I should avoid using CLOSE #0.

Kind regards,
Paul Sprangers
--
http://www.riscos.sprie.nl
Alan Adams
2019-05-12 19:44:45 UTC
Permalink
Post by Paul Sprangers
When it is launched via one of those programs it changes the desktop
font to the System font.
Completely agree with Matthew and Harriet. It happened to me too, until
someone told me that I should avoid using CLOSE #0.
It's not.

Partly because aboput a year I replaced all CLOSE# calls with a function
call which checked the handle for zero, closed it if non-zero, and set it
to zero.

Secondly because at this poiont in the program it hasn't closed anything -
it's still starting up.

I still want to know what mechanism could cause the desktop font to revert
to the system font. Is it, for example, a pointer in shared memory which
could be corrupted?
Post by Paul Sprangers
Kind regards,
Paul Sprangers
--
Alan Adams, from Northamptonshire
***@adamshome.org.uk
http://www.nckc.org.uk/
Martin Wuerthner
2019-05-13 17:43:48 UTC
Permalink
Post by Alan Adams
I still want to know what mechanism could cause the desktop font to revert
to the system font. Is it, for example, a pointer in shared memory which
could be corrupted?
No, that would be very unlikely. From what I have observed when using fonts
in icons the Wimp has a rather conservative approach to error handling in
this area: If anything goes wrong at any point with a font used in a window,
it switches everything back to the system font. So, the most likely cause is
that something is wrong with the icon definitions in your window. For
instance, when you copy the icon are you certain that you handle its
indirect data and validation string pointers correctly?
--
Martin Wuerthner MW Software http://www.mw-software.com/

------- RISC OS Software for Design, Printing and Publishing --------
Alan Adams
2019-05-13 20:54:37 UTC
Permalink
Post by Martin Wuerthner
Post by Alan Adams
I still want to know what mechanism could cause the desktop font to revert
to the system font. Is it, for example, a pointer in shared memory which
could be corrupted?
No, that would be very unlikely. From what I have observed when using fonts
in icons the Wimp has a rather conservative approach to error handling in
this area: If anything goes wrong at any point with a font used in a window,
it switches everything back to the system font. So, the most likely cause is
that something is wrong with the icon definitions in your window. For
instance, when you copy the icon are you certain that you handle its
indirect data and validation string pointers correctly?
Thanks, I'll look into that. It fits, because the change occurs
immediately the icons are copied.

I already know that all the validation strings are done by pointing the
addreses to a single place containing the string. I am assuming that
doesn't confuse things. This is old code, so a refresh wouldn't be a bad
thing.
--
Alan Adams, from Northamptonshire
***@adamshome.org.uk
http://www.nckc.org.uk/
Alan Adams
2019-05-14 10:57:45 UTC
Permalink
Post by Martin Wuerthner
Post by Alan Adams
I still want to know what mechanism could cause the desktop font to revert
to the system font. Is it, for example, a pointer in shared memory which
could be corrupted?
No, that would be very unlikely. From what I have observed when using fonts
in icons the Wimp has a rather conservative approach to error handling in
this area: If anything goes wrong at any point with a font used in a window,
it switches everything back to the system font. So, the most likely cause is
that something is wrong with the icon definitions in your window. For
instance, when you copy the icon are you certain that you handle its
indirect data and validation string pointers correctly?
I checked the template for the window concerned. The icon I was copying
had a font specified of system.fixed. I changed it to corpus.medium, and
the problem seems to have gone away.

In case I wasn't clear before, the windows of the application causing the
problem displayed with the correct fonts even after the problem showed up.
Everything that used the desktop font switched to the system font, i.e.
other applicatrion windows, and the labels on the icon bar.

Is there something odd about system.fixed I wonder - I can't see why as
it's just another font? The replacement has a longer name, so it's
unlikely to be a buffer issue.
--
Alan Adams, from Northamptonshire
***@adamshome.org.uk
http://www.nckc.org.uk/
j***@mdfs.net
2019-05-15 04:10:49 UTC
Permalink
Partly because about a year I replaced all CLOSE# calls with a function
call which checked the handle for zero, closed it if non-zero, and set it
to zero.
A function call? How do you do that?

DEFFNclose(chn%)
IF chn%<>0 THEN CLOSE#chn%:chn%=0
=some_return_value

....won't do what you expect as it only changes the *local* value of
chn%.

DEFFNclose(chn%)
IF chn%<>0 THEN CLOSE#chn%
=0

...with handle%=FNclose(handle%) would do it, though I tend to code
it inline explictly as: IF hnd%:CLOSE#hnd%:hnd%=0

However, with the magic of passing-by-reference:

DEFPROCclose(RETURN chn%)
IF chn%:CLOSE#chn%:chn%=0
ENDPROC

would work, giving you PROCclose(handle%). I'd go further and do:

DEFPROCclose(RETURN chn%)
LOCAL tmp%
IF chn%:tmp%=chn%:chn%=0:CLOSE#tmp%
ENDPROC

...so if an error occurs in the CLOSE#, the handle has already been
zeroed, so won't cause an attempt to reclose it.
Alan Adams
2019-05-15 09:11:27 UTC
Permalink
Post by j***@mdfs.net
Partly because about a year I replaced all CLOSE# calls with a function
call which checked the handle for zero, closed it if non-zero, and set it
to zero.
A function call? How do you do that?
Like this

DEF PROCclosefile(RETURN H%)
IF (DEBUG%AND(1<<21)) AND (H%=0) THEN
*REPORT \R WL: closefile: caller$ HANDLE IS ZERO H%
*REPORTSTACK
ENDIF
LOCAL ERROR
ON ERROR LOCAL ENDPROC
CLOSE#H%
RESTORE ERROR
H%=0
ENDPROC
Post by j***@mdfs.net
DEFFNclose(chn%)
IF chn%<>0 THEN CLOSE#chn%:chn%=0
=some_return_value
....won't do what you expect as it only changes the *local* value of
chn%.
DEFFNclose(chn%)
IF chn%<>0 THEN CLOSE#chn%
=0
...with handle%=FNclose(handle%) would do it, though I tend to code
it inline explictly as: IF hnd%:CLOSE#hnd%:hnd%=0
DEFPROCclose(RETURN chn%)
IF chn%:CLOSE#chn%:chn%=0
ENDPROC
DEFPROCclose(RETURN chn%)
LOCAL tmp%
IF chn%:tmp%=chn%:chn%=0:CLOSE#tmp%
ENDPROC
...so if an error occurs in the CLOSE#, the handle has already been
zeroed, so won't cause an attempt to reclose it.
--
Alan Adams, from Northamptonshire
***@adamshome.org.uk
http://www.nckc.org.uk/
Loading...