Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #5743 > unrolled thread

Font problem

Back to article view | Back to comp.sys.acorn.programmer

Contents

  Font problem Alan Adams <alan@adamshome.org.uk> - 2019-05-10 19:25 +0100
    Re: Font problem Alan Adams <alan@adamshome.org.uk> - 2019-05-10 19:35 +0100
      Re: Font problem Alan Adams <alan@adamshome.org.uk> - 2019-05-10 20:19 +0100
    Re: Font problem Matthew Phillips <spam2011m@yahoo.co.uk> - 2019-05-10 21:21 +0100
    Re: Font problem Harriet Bazley <harriet@bazleyfamily.co.uk> - 2019-05-11 01:20 +0100
    Re: Font problem Paul Sprangers <Paul@sprie.nl> - 2019-05-11 14:28 +0200
      Re: Font problem Alan Adams <alan@adamshome.org.uk> - 2019-05-12 20:44 +0100
        Re: Font problem Martin Wuerthner <spamtrap@mw-software.com> - 2019-05-13 19:43 +0200
          Re: Font problem Alan Adams <alan@adamshome.org.uk> - 2019-05-13 21:54 +0100
          Re: Font problem Alan Adams <alan@adamshome.org.uk> - 2019-05-14 11:57 +0100
        Re: Font problem jgh@mdfs.net - 2019-05-14 21:10 -0700
          Re: Font problem Alan Adams <alan@adamshome.org.uk> - 2019-05-15 10:11 +0100

#5743 — Font problem

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
alan@adamshome.org.uk
http://www.nckc.org.uk/

[toc] | [next] | [standalone]

#5744

In message <003219b257.Alan.Adams@ArmX6.adamshome.org.uk>
          Alan Adams <alan@adamshome.org.uk> wrote:

> 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>
> 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
alan@adamshome.org.uk
http://www.nckc.org.uk/

[toc] | [prev] | [next] | [standalone]

#5745

In message <aa251ab257.Alan.Adams@ArmX6.adamshome.org.uk>
          Alan Adams <alan@adamshome.org.uk> wrote:

> In message <003219b257.Alan.Adams@ArmX6.adamshome.org.uk>
>           Alan Adams <alan@adamshome.org.uk> wrote:

>> 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>
>> 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
alan@adamshome.org.uk
http://www.nckc.org.uk/

[toc] | [prev] | [next] | [standalone]

#5746

In message <003219b257.Alan.Adams@ArmX6.adamshome.org.uk>
 on 10 May 2019 Alan Adams  wrote:

> 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

[toc] | [prev] | [next] | [standalone]

#5747

On 10 May 2019 as I do recall,
          Alan Adams  wrote:


> 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.

[toc] | [prev] | [next] | [standalone]

#5748

In article <003219b257.Alan.Adams@ArmX6.adamshome.org.uk>,
   Alan Adams <alan@adamshome.org.uk> wrote:

> 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

[toc] | [prev] | [next] | [standalone]

#5749

In message <57b27c5a25Paul@sprie.nl>
          Paul Sprangers <Paul@sprie.nl> wrote:

> In article <003219b257.Alan.Adams@ArmX6.adamshome.org.uk>,
>    Alan Adams <alan@adamshome.org.uk> wrote:

>> 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?



> Kind regards,
> Paul Sprangers



-- 
Alan Adams, from Northamptonshire
alan@adamshome.org.uk
http://www.nckc.org.uk/

[toc] | [prev] | [next] | [standalone]

#5750

Alan Adams <alan@adamshome.org.uk> wrote:

> 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 --------

[toc] | [prev] | [next] | [standalone]

#5751

In message <mpro.prgel000idcos0ogk.spamtrap@mw-software.com>
          Martin Wuerthner <spamtrap@mw-software.com> wrote:

> Alan Adams <alan@adamshome.org.uk> wrote:

>> 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
alan@adamshome.org.uk
http://www.nckc.org.uk/

[toc] | [prev] | [next] | [standalone]

#5752

In message <mpro.prgel000idcos0ogk.spamtrap@mw-software.com>
          Martin Wuerthner <spamtrap@mw-software.com> wrote:

> Alan Adams <alan@adamshome.org.uk> wrote:

>> 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
alan@adamshome.org.uk
http://www.nckc.org.uk/

[toc] | [prev] | [next] | [standalone]

#5755

> 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.

[toc] | [prev] | [next] | [standalone]

#5756

In message <101d047b-eaea-4a5a-8955-bc6e52ad7eac@googlegroups.com>
          jgh@mdfs.net wrote:

>> 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


> 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, from Northamptonshire
alan@adamshome.org.uk
http://www.nckc.org.uk/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web