🚀 go-pugleaf

In article <1992Dec13.020107.28690@infodev.cam.ac.uk> idg10@cl.cam.ac.uk (I.D. Griffiths) writes:
>In article <1992Dec10.093501.25007@westminster.ac.uk>, gpcec@westminster.ac.uk (Tom Kirby-Green) writes:
>|> How ( having dynamicly created a sprite area ) do I access the icon
>|> definitions that follow the wimp_wind pointed to by w_handle. According
>|> to the PRMs I need to get hold of the indirected icon's and plug in my
>|> user sprite area before wimp_create_wind'ing the window.

Yep, your interpretation of the PRMs is correct.

>language like assembler...  C will merely make things difficult for you
>by being awkward about letting you do pointer maths.  Something like
>this may work:
>
>  icon = (wimp_icon *) (((char *) w_handle) + 88 + 32 * icno );

I have to disagree withh you on C making it harder - it makes it easier (IMHO).
The following works well, and uses C's handling of pointers to make it easier:
(lifted direct from SparkInfo's source)
{
  wimp_wind *window;

  wimpt_init("SparkInfo");
  res_init("SparkInfo");
  resspr_init();
  template_init();

...

  window = template_syshandle("ProgInfo");
  window->spritearea = (void *)1;
  ((wimp_icon *)(window+1))[1].data.indirectsprite.spritearea = resspr_area();
                            |
     Icon number __________/
}
NB: This code is from SparkInfo 2.11 which has not yet been released (still
under development), and icon numbers and use in the Templates may be quite
significantly different to that in 2.10.

This code makes sprites in windows created from the "ProgInfo" template (which
has been loaded into memory by the template part of RISC_OSLib) default to
coming from the wimp sprite pool. It also says that icon 1 should take its
sprite from the resspr sprite area (icon 1 is an indirected sprite only icon).
This avoids the need to make assumptions about the size of window and icon
blocks (I know they are unlikely to change, but what about in a year or so when
we are on RISC OS 4.00 and Desktop C 5??? - hard coded values are a nightmare,
and unnecessary where we have very good header files).
The only thing with pointer arithmetic is that you have to think carefully
about what data type is being pointed to at each stage, since +1 has a
significantly different meaning for different types.
-- 
 _    _
|_|  |||	1st Year Undergraduate, Department of Computer Science
|aul | |urphy	The University of Edinburgh
email: Paul.Murphy@ed.ac.uk