[comp.sys.atari.st] rsc_gaddr

covertr@gtephx.UUCP (Richard E. Covert) (06/19/89)

	The March/April issue of "Atari Explorer" has an article by John
Jainschigg titled "An introduction to the resource files". In this article John
describes how to use the rsc_gaddr() function. John also said that you should only
attempt to locate the address of "tree" objects. To quote John:

	OBJECT *p;

	rsc_gaddr( type, index, &p);

where "type" is an integer between 0 and 16 denoting the type of object
sought (there are bugs in the function that make it useless for object
types other then trees; type 0), .....


	Anyway, is this a generic bug in GEMDOS, for all versions of TOS??
Is it a bug in the compiler that John uses?? Does Mark Williams C, 3.09, have
this bug??

	This bug reduces the usefullness of rsc_gaddr() if it does exist.
There are times were you want a child of a tree, and it is easily to get the
child's address then to get the tree's address and have to index off of it.

	oh well, what the h - eee - double toothpicks!!

richard (gtephx!covertr) covert

greg@bilbo (Greg Wageman) (06/22/89)

In article <43ed07d6.14a1f@gtephx.UUCP> covertr@gtephx.UUCP (Richard E. Covert) writes:
>
>	The March/April issue of "Atari Explorer" has an article by John
>Jainschigg titled "An introduction to the resource files". In this article John
>describes how to use the rsc_gaddr() function. John also said that you should only
>attempt to locate the address of "tree" objects. To quote John:
>
>	OBJECT *p;
>
>	rsc_gaddr( type, index, &p);
>
>where "type" is an integer between 0 and 16 denoting the type of object
>sought (there are bugs in the function that make it useless for object
>types other then trees; type 0), .....
>
>
>	Anyway, is this a generic bug in GEMDOS, for all versions of TOS??
>Is it a bug in the compiler that John uses?? Does Mark Williams C, 3.09, have
>this bug??
>
>	This bug reduces the usefullness of rsc_gaddr() if it does exist.
>There are times were you want a child of a tree, and it is easily to get the
>child's address then to get the tree's address and have to index off of it.

I have not seen the article.  However, I have successfully used
rsc_gaddr() to obtain the address of free strings and alerts, which
are not type-zero objects.  I have not tried to obtain the address of
children, and it is not clear to me how one would, since while the
index of a tree is unique among all trees, the index of a child isn't
unique among all children.  I suppose one could set "p" equal to the
address of the desired tree object, but the documentation didn't make
it clear that that would work.

In any event, why is it so difficult to do &tree[CHILD]?  Even in
assembler, this is just a load of the address of tree into an address
register, a load of the index of child ("CHILD") into a data register, a
multiply of CHILD by the size of the object structure, and an add of
the resulting byte offset to the address of the tree (or an indexed
load).  Am I missing something here?

	
Longish .signature follows.  Skip now.

Greg Wageman			DOMAIN: greg@sj.ate.slb.com
Schlumberger Technologies	UUCP:   ...!uunet!sjsca4!greg
1601 Technology Drive		BIX:    gwage
San Jose, CA 95110-1397		CIS:    74016,352
(408) 437-5198			GEnie:  G.WAGEMAN
------------------
"Live Free; Die Anyway."
------------------
Opinions expressed herein are solely the responsibility of the author.

jschmidt@fbihh.UUCP (Jens Schmidt) (06/23/89)

In article <43ed07d6.14a1f@gtephx.UUCP>, covertr@gtephx.UUCP (Richard E. Covert) writes:
> The March/April issue of "Atari Explorer" has an article by John
> Jainschigg titled "An introduction to the resource files". In this article
> John describes how to use the rsc_gaddr() function. John also said that you
> should only attempt to locate the address of "tree" objects. To quote John:
> 
> 	OBJECT *p;
> 	rsc_gaddr( type, index, &p);
> 
> where "type" is an integer between 0 and 16 denoting the type of object
> sought (there are bugs in the function that make it useless for object
> types other then trees; type 0), .....
No, the resource has tables (indexed by type, 0..16) of all kinds of data.
Number 0 are the object trees, which are easy. Number 5 are strings, aka
alerts, they work too. The other data types usually don't exist by themselves
in a resource, but are included in a tree. So to get the address of eg. a
button OK_BUTTN in tree ABOUTBOX you say:
	OBJECT *p;
	rsrc_gaddr (0, ABOUTBOX, &p);
	p += OK_BUTTN;  /* this is pointer-arithmetic, equivalent to
			   p = & p[OK_BUTTN];  */
If you want the address of some item inside that, use eg.:
	char *s;
	s = p->string;
Summary: rsrc_gaddr() does work, but types other than 0 and 5 are mostly
useless, because you don't know the correct index into the resource. Use the
index into the tree instead.
===============================================================================
Jens Schmidt		Email: jschmidt@fbihh.uucp