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

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

Font_DecodeMenu

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

Contents

  Font_DecodeMenu Paul Sprangers <Paul@sprie.nl> - 2011-06-14 12:24 +0200
    Re: Font_DecodeMenu Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-06-14 15:54 +0200
      Re: Font_DecodeMenu Martin Wuerthner <spamtrap@mw-software.com> - 2011-06-14 20:52 +0200
      Re: Font_DecodeMenu Paul Sprangers <Paul@sprie.nl> - 2011-06-14 23:56 +0200
    Re: Font_DecodeMenu Steve Fryatt <news@stevefryatt.org.uk> - 2011-06-14 22:43 +0100
      Re: Font_DecodeMenu Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-06-15 06:50 +0200
        Re: Font_DecodeMenu Martin Wuerthner <spamtrap@mw-software.com> - 2011-06-15 13:18 +0200
          Re: Font_DecodeMenu Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-06-15 15:38 +0200
            Re: Font_DecodeMenu Steve Drain <steve@kappa.me.uk> - 2011-06-15 17:20 +0100
        Re: Font_DecodeMenu Steve Fryatt <news@stevefryatt.org.uk> - 2011-06-15 20:24 +0100
          Re: Font_DecodeMenu "Ste (news)" <steve@revi11.plus.com> - 2011-06-15 21:19 +0100
            Re: Font_DecodeMenu Steve Fryatt <news@stevefryatt.org.uk> - 2011-06-15 22:14 +0100
              Re: Font_DecodeMenu "Ste (news)" <steve@revi11.plus.com> - 2011-06-16 14:35 +0100
                Re: Font_DecodeMenu Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-06-16 18:10 +0200
            Re: Font_DecodeMenu Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-06-16 18:04 +0200
              Re: Font_DecodeMenu Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-06-16 18:51 +0200
              Re: Font_DecodeMenu "Ste (news)" <steve@revi11.plus.com> - 2011-06-16 18:12 +0100
                Re: Font_DecodeMenu John Tytgat <this@is.invalid> - 2011-06-21 19:19 +0200
                  Re: Font_DecodeMenu Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-06-22 19:18 +0200
                  Re: Font_DecodeMenu "Ste (news)" <steve@revi11.plus.com> - 2011-06-25 17:53 +0100
                    Re: Font_DecodeMenu John Tytgat <this@is.invalid> - 2011-06-27 13:06 +0200
          Re: Font_DecodeMenu Alan Wrigley <spamhater@keepyourfilthyspamtoyourself.co.uk> - 2011-06-15 22:13 +0100

Page 1 of 2  [1] 2  Next page →

#430 — Font_DecodeMenu

Dear all,

It's hard to describe the abyss of my incomprehension when it comes to wimp
programming (to call but one example).

This time it is the attempt to create a font menu and choose a font from
there. I've managed to get a font menu on screen (with submenus for
weights), but as soon as I click on a font, the program quits with an Abort
on data etc.

The culprit appears to be the following call:
SYS "Font_DecodeMenu",0,fontmenu%,block%,buf%,&100

(fontmenu% holds the font menu, while buf% is dimensioned elsewhere.)

Strangely, I used exactly the same call in another program without
problems. Even more strangely, when I change block% to block%!36 (a
desperate man is willing to plunge into the unobvious), the program happily
runs further, but will always choose the first font in the menu, no matter
on which font I clicked.

Who will point at at the above stupidities?

Kind regards,
Paul Sprangers

[toc] | [next] | [standalone]

#431

On 14/06/2011 12:24, Paul Sprangers wrote:

> The culprit appears to be the following call:
> SYS "Font_DecodeMenu",0,fontmenu%,block%,buf%,&100

Should R0 be zero? My StrongHelp files says that is for decoding an 
encoding?


> (fontmenu% holds the font menu, while buf% is dimensioned elsewhere.)

What call did you use to generate the font menu? Bits 19, 20, and 21 
should be set. Nothing else.


> problems. Even more strangely, when I change block% to block%!36 (a
> desperate man is willing to plunge into the unobvious),

The obvious question is what exactly is block% that you are passing?

block% should be the result of Wimp_Poll code 9 (menu selection), in 
which case the block is:
   !0 - offset to first menu item
   !4 - offset to second menu item
   [etc, until you reach a -1 to end the list]
If you're trying to pass a menu definition block, it'll go bang.

Thus:
.--------------.
| Font one   > |
| Font two   > |--------.
|*Font*three*>*| Bold   |
| Font four  > |*Italic*|
| Font five  > |--------'
'--------------'

The choice of "font three, italic" ought to return a block akin to:
   block%!0 = 2
   block%!4 = 1
   block%!8 = -1


Best wishes,

Rick.

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

#432

In message <4df76802$0$30755$ba4acef3@reader.news.orange.fr>
          Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:

> On 14/06/2011 12:24, Paul Sprangers wrote:

>> The culprit appears to be the following call:
>> SYS "Font_DecodeMenu",0,fontmenu%,block%,buf%,&100

> Should R0 be zero? My StrongHelp files says that is for decoding an
> encoding?

No, the value of 0 is correct. A value of 1 is for decoding an 
encoding menu.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

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

#434

In article <4df76802$0$30755$ba4acef3@reader.news.orange.fr>,
   Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:

> > SYS "Font_DecodeMenu",0,fontmenu%,block%,buf%,&100

> Should R0 be zero? My StrongHelp files says that is for decoding an 
> encoding?

It confused me too, several times even. For decoding the encoding menu, bit
0 has to be set, which means that bit 0 must be 1. For decoding the font
menu, you should therefore enter 0 here, as Martin stated already.


> The obvious question is what exactly is block% that you are passing?

Good question. I've now updated the block% with the given entries and
terminated it with -1, before passing it to the above call. This works
indeed, hallelujah! Thank you very much.

The only question is, why didn't I have to do the same in the other
program? Presumably, because that program is much more simple, so that the
block% arrived unchanged from poll to call - contrary to the current mess.

Again, a piece is added to the wimp jigsaw.
The news groups are great.

Kind regards,
Paul Sprangers

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

#433

On 14 Jun, Paul Sprangers wrote in message
    <51e32acc58Paul@sprie.nl>:

> This time it is the attempt to create a font menu and choose a font from
> there. I've managed to get a font menu on screen (with submenus for
> weights), but as soon as I click on a font, the program quits with an
> Abort on data etc.
> 
> The culprit appears to be the following call:
> SYS "Font_DecodeMenu",0,fontmenu%,block%,buf%,&100
> 
> (fontmenu% holds the font menu, while buf% is dimensioned elsewhere.)

The short answer is "no idea": in isolation, your code is faultless.

Of course, we don't have any idea what fontmenu%, block% and buf% contain in
the context of your program.
 
> Strangely, I used exactly the same call in another program without
> problems. Even more strangely, when I change block% to block%!36 (a
> desperate man is willing to plunge into the unobvious), 

It's unclear what that's supposed to be trying to achieve.  block% should be
a pointer to the block returned by Wimp_Poll on a Menu Selection event
(reason code 9), so block!36 would be the selection at the 10th level of
(sub)menu: I'm not even sure that the Wimp will go that far.  In fact,
you're probably just pointing Font_DecodeMenu to some random memory address,
which isn't a smart move...

Allowing for the important caveats that: a) I've only used these calls in
anger from C, b) the following code uses extremely poor memory allocation
techniques, and c) I don't do BASIC much nowadays and this hasn't been
tested at all (what could possibly go wrong? ;-), I think the following
semi-pseudocode should be what you're doing.  Is it?

  DIM block% 255
  DIM font_menu% size1%
  DIM font_names% size2%
  DIM returned_name% size3%

  REM ... time passes ...

  SYS "Font_ListFonts",,font_menu%,&800,size1%,font_names%,size2%,0
  SYS "Wimp_CreateMenu",,font_menu%,x%,y%

  REM ... more time passes ...

  SYS "Wimp_Poll",0,block% TO reason%
  CASE reason% OF
  
    REM ... etc ...

    WHEN 9
      SYS "Font_DecodeMenu",0,font_menu,block%,returned_name%,size3%
      SYS "XOS_GenerateError",returned_name TO returned_name$

      REM returned_name$ now contains the font name plus stuff: you'll
      REM now need to do some string manipulation to sort out what.
      REM
      REM I can't remember if the name is zero terminated; if not,
      REM you might get away without XOS_GenerateError.
  
    REM ... etc ...
  
  ENDCASE

-- 
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

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

#435

On 14/06/2011 23:43, Steve Fryatt wrote:

> SYS "Font_DecodeMenu",0,font_menu,block%,returned_name%,size3%
> SYS "XOS_GenerateError",returned_name TO returned_name$
                                        ^ missing % ;-)

Erk! Hacky, using a side-effect to convert!

You could drop the XOS_GenerateError and use something like:

   CASE $returned_name% OF

or perhaps just specify returned_name$ in the DecodeMenu SWI to tell the 
system you want it as a string in the first place.


Best wishes,

Rick.

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

#436

In message <4df83a04$0$14668$ba4acef3@reader.news.orange.fr>
          Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:

> On 14/06/2011 23:43, Steve Fryatt wrote:

>> SYS "Font_DecodeMenu",0,font_menu,block%,returned_name%,size3%
>> SYS "XOS_GenerateError",returned_name TO returned_name$
>                                       ^ missing % ;-)

> Erk! Hacky, using a side-effect to convert!

> You could drop the XOS_GenerateError and use something like:

>    CASE $returned_name% OF

No, that will not work. The $ operator only works for CR-terminated 
strings.

> or perhaps just specify returned_name$ in the DecodeMenu SWI to tell the
> system you want it as a string in the first place.

No, you cannot do that. Font_DecodeMenu needs a buffer pointer.

The above is a bit of a hack, but a pretty standard one for reading a 
ctrl-terminated string from memory. Better to hide that call away in a 
function and document it there, but Steve was not actually claiming 
that this is production quality code.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

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

#437

On 15/06/2011 13:18, Martin Wuerthner wrote:

> No, that will not work. The $ operator only works for CR-terminated
> strings.

I must be mixing it up with Wimp_DecodeMenu... always found the Font 
stuff to be a bit of a PITA to work with (ScanString? eeek!).


> No, you cannot do that. Font_DecodeMenu needs a buffer pointer.

So you couldn't, say:
   meh$ = STRING$(255, " ")
   SYS "Font_DecodeMenu",<etc>,<etc>,meh$,255
?
Shame, it'd make like simpler, as C and BASIC use quite different 
line-ending styles, and it seems the OS is friendly to half. ;-)


> The above is a bit of a hack, but a pretty standard one for reading a
> ctrl-terminated string from memory.

It's a surprise that there isn't an OS_ConvertString to handle 
conversions of one line convention to another, such as:
   SYS "OS_ConvertString", source$, original%, desired% TO dest$
It'd be pretty easy in code, just step through looking for <original>, 
when found replace with <desired>, then return the result.
[a bit of extra code, it might cater for RISC OS <-> DOS text too]


Best wishes,

Rick.

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

#438

On 15/06/2011 14:38, Rick Murray wrote:
> On 15/06/2011 13:18, Martin Wuerthner wrote:
>> No, that will not work. The $ operator only works for CR-terminated
>> strings.

True.

>> No, you cannot do that. Font_DecodeMenu needs a buffer pointer.

But SYS will convert a buffer terminated by 0 or 10 to a BASIC string. 
*If* this buffer is so terminated then:

  SYS "Font_DecodeMenu",0,block%,buffer%,size% TO ,,,buffer$

should work, without resorting to "XOS_GenerateError".

> So you couldn't, say:
> meh$ = STRING$(255, " ")
> SYS "Font_DecodeMenu",<etc>,<etc>,meh$,255

Or maybe:

  SYS "Font_DecodeMenu",<etc>,<etc>,STRING$(255, " "),255 TO ,,,result$

Nothing is tested, these are just general ways of dealing with SWIs. ;-)

> Shame, it'd make like simpler, as C and BASIC use quite different
> line-ending styles, and it seems the OS is friendly to half. ;-)

But OS buffers can be terminated by &00, &0A or not terminated, but the 
length of the string returned or a pointer to the end of the string.

> It's a surprise that there isn't an OS_ConvertString to handle
> conversions of one line convention to another, such as:
> SYS "OS_ConvertString", source$, original%, desired% TO dest$
> It'd be pretty easy in code, just step through looking for <original>,
> when found replace with <desired>, then return the result.
> [a bit of extra code, it might cater for RISC OS <-> DOS text too]

Perhaps you are looking for Basalt's RETURN$, which can be used for 
these conversions for BASIC, at least.

Steve

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

#439

On 15 Jun, Rick Murray wrote in message
    <4df83a04$0$14668$ba4acef3@reader.news.orange.fr>:

> On 14/06/2011 23:43, Steve Fryatt wrote:
> 
> > SYS "Font_DecodeMenu",0,font_menu,block%,returned_name%,size3% SYS
> > "XOS_GenerateError",returned_name TO returned_name$
>                                         ^ missing % ;-)

I said it was untested... ;-)

> Erk! Hacky, using a side-effect to convert!

Yes, but it's now a pretty standard trick and hence one that's unlikely to
be removed from RISC OS any time soon.  I've even had my wrist slapped by
better developers from around these parts for *not* using it in the past[1].

> You could drop the XOS_GenerateError and use something like:
> 
>    CASE $returned_name% OF

You might be thinking of BB4W's $$returned_name%; RISC OS Basic has no
built-in way to read zero-terminated strings (which is why the
XOS_GenerateError trick is used at all).


1. Preferring, for reasons of non-hack to do something like

  DEF FNread_string(string%)
  LOCAL string$

  string$ = ""

  WHILE ?string% <> 0
    string$ += CHR$(?string%)
    string% += 1
  ENDWHILE
  =string$

-- 
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

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

#440

In article <mpro.lmuj8p02zu8sw01cg.news@stevefryatt.org.uk>,
   Steve Fryatt <news@stevefryatt.org.uk> wrote:
> 1. Preferring, for reasons of non-hack to do something like

I think saying it's a 'hack' to use a deliberate, documented feature of the
BASIC SYS statement is probably pushing it.

Some people use OS_IntOn rather than XOS_GenerateError. I'm not sure which
is fastest or best. There's only one way to find out. Fight!

In my quick test, the OS_IntOn method was 30% faster if we call the SWI by
name, whereas when calling the SWI by number, OS_IntOn was only 4% faster.
This seems to show that calling SWIs by name is slow, especially the X form
of SWIs and BASIC having to interpret a longer SWI name string doesn't help.

>   DEF FNread_string(string%)
>   LOCAL string$
>
>   string$ = ""

The above is not required; BASIC initialises local variables for you.

>   WHILE ?string% <> 0

Why would you ever bother with the "<> 0" part? It's as pointless as LET.

>     string$ += CHR$(?string%)
>     string% += 1
>   ENDWHILE
>   =string$

Finally, I'd use ptr% rather than string% to make it easier to
read/understand. Well, I would if I didn't use XOS_GenerateError in the
first place.

Ta,

Steve

-- 
Steve Revill @ Home
Note: All opinions expressed herein are my own.

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

#442

On 15 Jun, Ste (news) wrote in message
    <51e3e527c5steve@revi11.plus.com>:

> In article <mpro.lmuj8p02zu8sw01cg.news@stevefryatt.org.uk>,
>    Steve Fryatt <news@stevefryatt.org.uk> wrote:
>
> > 1. Preferring, for reasons of non-hack to do something like
> 
> I think saying it's a 'hack' to use a deliberate, documented feature of
> the BASIC SYS statement is probably pushing it.
> 
> Some people use OS_IntOn rather than XOS_GenerateError. I'm not sure which
> is fastest or best. There's only one way to find out. Fight!

I think the 'hack' concern comes from the fact that it's not what
XOS_GenerateError is supposed to be used for.  It works at present, but
there's always the worry that this might change (although I'm now of the
opinion that this usage is common enough that no-one sane would change the
way the X-form operates).

[snip]

> >   DEF FNread_string(string%)
> >   LOCAL string$
> >
> >   string$ = ""
> 
> The above is not required; BASIC initialises local variables for you.

True...  The example was written off the top of my head for that post, and I
don't seem to think in BASIC these days.

> >   WHILE ?string% <> 0
> 
> Why would you ever bother with the "<> 0" part? It's as pointless as LET.

See above: I'm not (personally) a fan of writing stuff like "while (ptr)"
when what's meant is "while (ptr != NULL)", and as such I would write the
above as "while (*ptr != '\0')" instead of "while (*ptr)" and let the
compiler worry about things.

In BASIC there may be advantages to being terse; I still prefer clarity,
though. :-)

-- 
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

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

#443

In article <mpro.lmuobu00pahs001l4.news@stevefryatt.org.uk>,
   Steve Fryatt <news@stevefryatt.org.uk> wrote:
> I think the 'hack' concern comes from the fact that it's not what
> XOS_GenerateError is supposed to be used for.  It works at present, but
> there's always the worry that this might change (although I'm now of the
> opinion that this usage is common enough that no-one sane would change the
> way the X-form operates).

Changing the documented behaviour of SWIs (and most other things) in a
non-backwards compatible way is not the RISC OS way of doing things anyway
so I agree that we don't need to worry about that.

Ta,

Steve

-- 
Steve Revill @ Home
Note: All opinions expressed herein are my own.

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

#445

On 16/06/2011 15:35, Ste (news) wrote:

> Changing the documented behaviour of SWIs (and most other things) in a
> non-backwards compatible way is not the RISC OS way of doing things anyway

No, God forbid we'd end up in a situation where we'd have three or so 
completely different versions of something very large that are *mostly* 
the same, but not similar enough to anybody that understands what is 
meant by "backwards compatibility".

Who'd be crazy enough to try crap like that these days?

<looks at .Net framework, all three of 'em [*]>

Oh.


Best wishes,

Rick.

* - on another computer, I pulled all but v1 off of my eeePC because I
     couldn't justify the hundreds of megabytes required on a small SSD
     for something that is used by very little...
     ...of course, that doesn't stop WindowsUpdate from attempting to
     update them, failing, and leaving temp files scattered all over the
     place. Really, Microsoft code is like an incontinent elephant who's
     just eaten a box of laxatives. [I'll leave you with that image ;-) ]

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

#444

On 15/06/2011 22:19, Ste (news) wrote:

> There's only one way to find out. Fight!

;-) Reminds me of that odd claymation fight-fest that was on MTV back 
around Y2K.


> This seems to show that calling SWIs by name is slow,

Yes - which is why one of the first optimisations you should do is 
convert SWI names to numbers.


I notice in hacking around the PVR code, that at some point ARM based 
Linux altered SWI handling to call SWI &0 and pass the code in R7 
instead of calling SWI &<code>. I wonder, given how this must then be 
picked apart in the SWI handler, how much of a speed increase this 
makes? It does seem to rather break the niceness of SWI <number>, however...


Best wishes,

Rick.

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

#446

On 16/06/2011 18:04, Rick Murray wrote:

Clarification:

> I wonder, given how this must then be picked apart in the SWI handler,

I meant, of course, that:

   SWI &12345

would require the handler to load up the instruction, pull the SWI 
number from the instruction, etc etc.

As opposed to having it ready in R7...


Best wishes,

Rick.

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

#447

In article <4dfa29aa$0$14673$ba4acef3@reader.news.orange.fr>,
   Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:
> I notice in hacking around the PVR code, that at some point ARM based
> Linux altered SWI handling to call SWI &0 and pass the code in R7 instead
> of calling SWI &<code>. I wonder, given how this must then be picked
> apart in the SWI handler, how much of a speed increase this makes? It
> does seem to rather break the niceness of SWI <number>, however...

I don't know if you're aware of why they do it (apart from ARM deprecating
the field in the SWI instruction which contains the RISC OS SWI number)...

It's because putting the SWI number in the instruction means the SWI handler
has to load the word of memory containing the instruction into the data
cache (it will probably only be in the instruction cache at the time it is
executed) causing a whole line of dcache to be thrown out in the process. 

This is nasty - it'd be just lovely if there was some other register (co-pro
register or something) that the ARM could automatically dump the SWI number
before it branches to the vector. That would be faster for the SWI handler
and would eliminate the dcache pollution.

Sadly, because Linux (and presumably many other OSs) never bothered to use
the SWI number field, instead deciding to pass a reference to the routine in
a register, I don't think ARM have ever cared.


Ah, I see from your next post that you already knew. :)

Steve

-- 
Steve Revill @ Home
Note: All opinions expressed herein are my own.

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

#484

On 6/16/2011 7:12 PM, Ste (news) wrote:
> [...] (apart from ARM deprecating
> the field in the SWI instruction which contains the RISC OS SWI number)...

Do you have a reference for SWI number field being deprecated by ARM ?

John.

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

#486

On 21/06/2011 19:19, John Tytgat wrote:

>> [...] (apart from ARM deprecating the field in the SWI instruction which
>> contains the RISC OS SWI number)...
> Do you have a reference for SWI number field being deprecated by ARM ?

Nothing on ARM's site that I could see. And it isn't specifically the 
RISC OS SWI number, it is the interrupt number.

As far as I'm aware, the SWI number field is still available, it is just 
that in later processors it is a lot quicker/simpler to pass the number 
in a register.


Best wishes,

Rick.

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

#490

In article <itqjrg$96c$1@dont-email.me>,
   John Tytgat <this@is.invalid> wrote:
> On 6/16/2011 7:12 PM, Ste (news) wrote:
> > [...] (apart from ARM deprecating
> > the field in the SWI instruction which contains the RISC OS SWI number)...
>
> Do you have a reference for SWI number field being deprecated by ARM ?

Ah, perhaps a poor choice of words. I should really have said it has been
suggested in conversations I've heard in the past that because nothing(!)
uses any value other than zero in that field, they could reclaim a big chunk
of number space for new instructions/encodings.

Whether or not any of this was suggested as something ARM are actually
planning to do is beyond my recollection because the relevant conversations
were years ago.

In summary: I really mean that we shouldn't be surprised to see a future
generation of the ARM architecture that does this and gives RISC OS a
massive problem.

Just like the way that we should be surprised in the future if ARM drop the
ARM instruction set all together and move over to Thumb2 or something...

:-|

Ta,

Steve

-- 
Steve Revill @ Home
Note: All opinions expressed herein are my own.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web