FM@DACTH51.BITNET (08/08/89)
Ok,Ok, Now I know the routing of my messages is O.K. and You all know I
sometimes make typos somewhere. Thanks to all You who corrected me. Sure-
ly noone could have guessed the meaning of the mistyped sentence. I can't
include former postings here (cant't persuade this $#@* VAX not to send them
to the original sender but to the gate at Stanford), and I'm not going to
cite my sentence. Those who know, know, and the others didn't miss anything.
Now to the more serious second subject: I've spent a weekend programming some
Icons, and discovered a undocumented feature. Undocumented? I have three
different GEM - Programmer's Guides, one very recent ("Atari ST Profibuch")
and noone mentions the thing -- but sure at least the people who build
Resource Construction Kits will know this.
All my documentations tell that the struct iconblock looks like
struct iconblock {
...
int ib_char; /* Letter in Icon, e.g. in Disk-Icon */
...
} ICONBLOCK;
(include a 'typedef' above, I forgot it) and this is how the obdefs.h -
files look for every compiler I looked at. BUT -- Say, I have an icon
OBJECT *the_icon; , then the statement
the_icon->ob_spec->ib_pchar = 'A';
leads to an Icon painted white on white. Not useful. In fact, Icons con-
strued with a RCK look like:
the_icon->ob_spec->ib_pchar == 0x1000 + 'A';
I tried this, and it worked. It took me 1 1/2 days to discover that the fault
was not in my pointer forest. Obviously, the ib_char hides in some way the
colour of the icon. I didn't try, how this is done, I guess the two nibbles
of the high-byte contain a number between 0 and 15 each, coding foreground
and background? I'm glad to have my icons working now. But I got very angry
because this was not mentioned in any of my books!
Oliver Bonten
P.S. 'hides' 6 lines above should read: the information about ... is put
in ...