home *** CD-ROM | disk | FTP | other *** search
/ Crawly Crypt Collection 1 / crawlyvol1.bin / program / books / progem / resource.4 < prev    next >
Text File  |  1986-11-01  |  33KB  |  725 lines
  1.     Permission  to reprint or excerpt is granted only if the following line
  2.     appears at the top of the article:
  3.  
  4.       ANTIC PUBLISHING INC., COPYRIGHT 1985. REPRINTED BY PERMISSION.
  5.  
  6.  
  7.  
  8.     Professional GEM  by Tim Oren
  9.     Column #4 - The Resource file
  10.  
  11.  
  12.        Welcome  to  the  fourth installment of ST PRO GEM.  We are about to
  13.     delve  into  the mysteries of GEM resource structure, and then use this
  14.     knowledge  to  create  some  useful utilities for handling dialogs.  As
  15.     with  the  past columns, there is once again a download file.  You will
  16.     find it under the name GEMCL4.C in the ATARI 16-bit Forum (GO PCS-58).
  17.  
  18.        The  first  and largest part of the download contains a C image of a
  19.     sample  resource file.  To create this listing, I used the GEM Resource
  20.     Construction  Set  to  create  a  dummy  resource  with  three  dialogs
  21.     including  examples  of  all  object  types,  then enabled the C output
  22.     option  and saved the resource.  If you have access to a copy of RCS, I
  23.     suggest that you create your own listing in order to get a feel for the
  24.     results.   Then, using either listing as a roadmap to the resource, you
  25.     can follow along as we enter...
  26.  
  27.  
  28.     A MAZE OF TWISTY LITTLE PASSAGES
  29.  
  30.        While  a GEM resource is loaded as a block of binary information, it
  31.     is  actually  composed of a number of different data structures.  These
  32.     structures  are  linked  together  in  a rather tangled hierarchy.  Our
  33.     first job is to map this linkage system.
  34.  
  35.        The  topmost  structure  in  a resource file is the resource header.
  36.     This  is  an  array  of words containing the size and offset within the
  37.     resource  of  the  other  structures which follow.  This information is
  38.     used by GEM during the resource load process, and you should never need
  39.     to  access  it.  (The  resource  header does not appear in the C output
  40.     file;  it is generated by the RSCREATE utility if the C file is used to
  41.     recreate the resource.)
  42.  
  43.        The  next structure of interest is the tree index.  This is an array
  44.     of  long  pointers,  each of which addresses the beginning of an object
  45.     tree. Again, you wouldn't normally access this structure directly.  The
  46.     GEM  rsrc_gaddr  call  uses  it  when  finding  trees' addresses.  This
  47.     structure is called "rs_trindex" in the C output.
  48.  
  49.        If  you  look at the contents of rs_trindex you will notice that the
  50.     values  are  integers,  instead  of the pointers I described.  What has
  51.     happened  is  that  RCS  has converted the pointers to indices into the
  52.     object array. (If you actually used the C file to recreate the resource
  53.     file, then the pointers would be regenerated by RSCREATE.)
  54.  
  55.        Now you can follow the link from rs_trindex to the objects stored in
  56.     rs_object.   Take  (for  instance)  the  second entry in rs_trindex and
  57.     count  down  that many lines in rs_object.  The following line (object)
  58.     should start with a -1.  This indicates that it is the root object of a
  59.     tree.  The following objects down to the next root belong to that tree.
  60.     We'll pass over the details of inter-object linkage for now, leaving it
  61.     for a later column.
  62.  
  63.        There  are  a number of different fields in an object, but right now
  64.     we'll  concentrate on two of them: OB_TYPE and OB_SPEC.  The OB_TYPE is
  65.     the  field  which contains mnemonics like G_STRING and G_BOX indicating
  66.     the  type  of  the object. The OB_SPEC is the only field in each object
  67.     which is a LONG - you can tell it by the L after the number.
  68.  
  69.        What's  in  OB_SPEC  depends  on the object type, so we need to talk
  70.     about what kinds of objects are available, what you might use them for,
  71.     and finally how they use the OB_SPEC field.
  72.  
  73.        The  box  type objects are G_BOX, G_IBOX, and G_BOXCHAR.  A G_BOX is
  74.     an  opaque  rectangle,  with an optional border.  It's used to create a
  75.     solid  patch  of color or pattern on which to place other objects.  For
  76.     instance, the background of a dialog is a G_BOX.
  77.  
  78.        A  G_IBOX  is  a hollow box which has only a border.  (If the border
  79.     has  no  thickness,  then the box is "invisible", hence the name.)  The
  80.     favorite  use  for  IBOXes is to hold radio buttons.  There is also one
  81.     neat trick you can play with an IBOX.  If you have more than one object
  82.     (say  an  image and a string) which you would like to have selected all
  83.     at once, you can insert them in a dialog, then cover them with an IBOX.
  84.     Since  the box is transparent, they will show through.  If you now make
  85.     the  box  selectable,  clicking  on it will highlight the whole area at
  86.     once!
  87.  
  88.        The  G_BOXCHAR  is just like a G_BOX, except that a single character
  89.     is  drawn in its center.  They are mostly used as "control points": the
  90.     FULLER,  CLOSER,  SIZER, and arrows in GEM windows are BOXCHARs, as are
  91.     the components of the color selection gadgets in the RCS.
  92.  
  93.        The OB_SPEC for box type objects is a packed bit array.  Its various
  94.     fields  contain  the background color and pattern, the border thickness
  95.     and color, and the optional character and its color.
  96.  
  97.        The  string  type  objects  are  G_STRING,  G_BUTTON,  and  G_TITLE.
  98.     G_STRINGs  (in  addition  to being a bad pun) are for setting up static
  99.     explanatory  text within dialogs.  The characters are always written in
  100.     the "system font": full size, black, with no special effects.
  101.  
  102.        We have already discussed many of the uses of G_BUTTONs.  They add a
  103.     border  around  the  text.   The  thickness  of  a G_BUTTON's border is
  104.     determined by what flags are set for the object.  All buttons start out
  105.     with  a  border thickness of one pixel.  One pixel is added if the EXIT
  106.     attribute  is  set,  and  one more is added if the DEFAULT attribute is
  107.     set.
  108.  
  109.        The  G_TITLE  type is a specially formatted text string used only in
  110.     the  title  bar  of  menus.   This type is needed to make sure that the
  111.     menus  redraw  correctly.   The Resource Construction Set automatically
  112.     handles inserting G_TITLEs, so you will seldom use them directly.
  113.  
  114.        In  a resource, the OB_SPEC for all string objects is a long pointer
  115.     to  a  null  terminated ASCII string.  The string data in the C file is
  116.     shown  in  the  BYTE  array rs_strings.  Again you will notice that the
  117.     OB_SPECs  in  the C file have been converted to indices into rs_string.
  118.     To  find the string which matches the object, take the value of OB_SPEC
  119.     and  count  down  that  many lines in rs_strings.  The next line is the
  120.     correct string.
  121.  
  122.        The  formatted text object types are G_TEXT, G_BOXTEXT, G_FTEXT, and
  123.     G_FBOXTEXT.   G_TEXTs  are  a  lot  like  strings,  except that you can
  124.     specify  a color, different sizes, and a positioning rule for the text.
  125.     Since  they  require more memory than G_STRINGs, G_TEXTs should be used
  126.     sparingly  to  draw attention to important information within a dialog.
  127.     G_TEXTs are also useful for automatic centering of dialog text which is
  128.     changed  at  run-time.   I will describe this technique in detail later
  129.     on.
  130.  
  131.        The  G_BOXTEXT type adds a solid background and border to the G_TEXT
  132.     type.   These  objects are occasionally used in place of G_BUTTONs when
  133.     their color will draw attention to an important object.
  134.  
  135.        The  G_FTEXT  object  is  an  editable  text field.  You are able to
  136.     specify  a  constant  "template"  of characters, a validation field for
  137.     those characters which are to be typed in, and an initial value for the
  138.     input  characters.   You  may  also select color, size, and positioning
  139.     rule for G_FTEXTs.  We'll discuss text editing at length below.
  140.  
  141.        The  G_FBOXTEXT object, as you might suspect, is the same as G_FTEXT
  142.     with  the addition of background and border.  This type is seldom used:
  143.     the  extra  appearance  details  distract attention from the text being
  144.     edited.
  145.  
  146.        The  OB_SPEC for a formatted text object is a pointer to yet another
  147.     type  of  structure:  a TEDINFO.  In the C file, you will find these in
  148.     rs_tedinfo.   Take  the  OB_SPEC  value  from each text type object and
  149.     count  down  that  many  entries  in  rs_tedinfo,  finding the matching
  150.     TEDINFO  on the next line.  Each contains pointers to ASCII strings for
  151.     the  template,  validation,  and  initialization.   You  can find these
  152.     strings in rs_strings, just as above.
  153.  
  154.        There  are  also  fields  for  the  optional  background  and border
  155.     details,  and  for the length of the template and text.  As we will see
  156.     when  discussing  editing,  the  most  important TEDINFO fields are the
  157.     TE_PTEXT  pointer  to  initialized  text  and the TE_TXTLEN field which
  158.     gives its length.
  159.  
  160.        The G_IMAGE object type is the only one of its kind.  A G_IMAGE is a
  161.     monochrome  bit image.  For examples, see the images within the various
  162.     GEM alert boxes.  Note that monochrome does not necessarily mean black.
  163.     The  image  may  be any color, but all parts of it are the SAME color.
  164.     G_IMAGEs  are  used as visual cues in dialogs.  They are seldom used as
  165.     selectable  items  because their entire rectangle is inverted when they
  166.     are  clicked.  This effect is seldom visually pleasing, particularly if
  167.     the image is colored.
  168.  
  169.        G_IMAGE  objects  have  an  OB_SPEC  which is a pointer to a further
  170.     structure  type:  the  BITBLK.   By now, you should guess that you will
  171.     find  it  in  the  C  file in the array rs_bitblk.  The BITBLK contains
  172.     fields  describing  the  height  and  width of the image in pixels, its
  173.     color,nd  it also contains a long pointer to the actual bits which make
  174.     up  the  image.   In  the C file, the images are encoded as hexadecimal
  175.     words and stored in arrays named IMAG0, IMAG1, and so on.
  176.  
  177.        The last type of object is the G_ICON.  Like the G_IMAGE, the G_ICON
  178.     is a bit image, but it adds a mask array which selects what portions of
  179.     the  image  will  be  drawn,  as  well as an explanatory text field.  A
  180.     G_ICON  may  also  specify different colors for its "foreground" pixels
  181.     (the  ones that are normally black), and its "background" pixels (which
  182.     are normally white).
  183.  
  184.        The  pictures  which  you see in Desktop windows are G_ICONs, and so
  185.     are the disks and trashcan on the desktop surface.  With the latter you
  186.     will  notice  the effects of the mask.  The desktop shows through right
  187.     up  to  the  edge  of  the  G_ICON,  and  only  the  icon itself (not a
  188.     rectangle) is inverted when a disk is selected.
  189.  
  190.        The  OB_SPEC  of  an  icon  points  to  another  structure called an
  191.     ICONBLK.   It  is  shown  in  the  C  file  as rs_iconblk.  The ICONBLK
  192.     contains  long  pointers  to  its foreground bit array, to the mask bit
  193.     array,  and  to  the ASCII string of explanatory text.  It also has the
  194.     foreground  and  background  colors as well as the location of the text
  195.     area  from  the upper left of the icon.  The most common use of G_ICONs
  196.     and  ICONBLKs  is  not  in dialogs, instead they are used frequently in
  197.     trees  which  are  built  at  run-time,  such as Desktop windows.  In a
  198.     future  article,  we  will  return  to  a  discussion  of building such
  199.     "on-the-fly" trees with G_ICONs.
  200.  
  201.        Now,  let's recap the hierarchy of resource structures:  The highest
  202.     level structures are the resource header, and then the tree index.  The
  203.     tree  index  points  to  the beginning of each object tree. The objects
  204.     making  up  the  tree are of several types, and depending on that type,
  205.     they  may contain pointers to ASCII strings, or to TEDINFO, ICONBLK, or
  206.     BITBLK  structures.   TEDINFOs  contain  further  pointers  to strings;
  207.     BITBLKs have pointers to bit images; and ICONBLKs have both.
  208.  
  209.  
  210.     PUTTING IT TO WORK
  211.  
  212.        The  most  common  situations  requiring  you to understand resource
  213.     structures  involve  the  use  of  text  and  editable  text objects in
  214.     dialogs.  We'll look at two such techniques.
  215.  
  216.        Often  an  application  requires  two or more dialogs which are very
  217.     similar  except  for one or two title lines.  In this circumstance, you
  218.     can save a good deal of resource space by building only one dialog, and
  219.     changing the title at run time.
  220.  
  221.        It  is  easy  to  go  wrong with this practice, however, because the
  222.     obvious  tactic  of  using  a G_STRING and writing over its text at run
  223.     time  can go wrong.  The first problem is that you must know in advance
  224.     the  longest  title  to  be  used,  and put a string that long into the
  225.     resource.   If  you don't you will damage other objects in the resource
  226.     as  you  copy  in  characters.  The other problem is that a G_STRING is
  227.     always drawn at the same place in a dialog.  If the length of the title
  228.     changes  from  time  to  time,  the  dialog will have an unbalanced and
  229.     sloppy appearance.
  230.  
  231.        A  better  way  to do this is to exploit the G_TEXT object type, and
  232.     the  TEDINFO  structure.   The set_text() routine in the download shows
  233.     how.   The parameters provided are the tree address, the object number,
  234.     and  the  32-bit  address of the string to be substituted.  For this to
  235.     work,  the object referenced should be defined as a G_TEXT type object.
  236.     Additionally,  the  Centered text type should be chosen, and the object
  237.     should  have been "stretched" so that it fills the dialog box from side
  238.     to side.
  239.  
  240.        In  the code, the first action is to get the OB_SPEC from the object
  241.     which  was  referenced.  Since we know that the object is a G_TEXT, the
  242.     OB_SPEC  must  point to a TEDINFO.  We need to change two fields in the
  243.     TEDINFO.   The TE_PTEXT field is the pointer to the actual string to be
  244.     displayed;  we  replace  it  with  the  address  of our new string. The
  245.     TE_TXTLEN  field  is  loaded  with  the new string's length.  Since the
  246.     Centered attribute was specified for the object, changing the TE_TXTLEN
  247.     will  cause  the string to be correctly positioned in the middle of the
  248.     dialog!
  249.  
  250.        Editing  text  also requires working with the TEDINFO structure. One
  251.     way  of  doing  this  is  shown in the download.  The object to be used
  252.     (EDITOBJ)  is  assumed  to  be  a G_FTEXT or G_FBOXTEXT.  Since we will
  253.     replace  the initialized text at run time, that field may be left empty
  254.     when building the object in the RCS.
  255.  
  256.        The basic trick of this code is to point the TEDINFO's TE_PTEXT at a
  257.     string  which is defined in your code's local stack.  The advantages of
  258.     this  technique  are  that you save resource space, save static data by
  259.     putting the string in reusable stack memory, and automatically create a
  260.     scratch string which may be discarded if the dialog is cancelled.
  261.  
  262.        The text string shown is arbitrarily 41 characters long.  You should
  263.     give  yours  a  length  equal  to  the number of blanks in the object's
  264.     template  field  plus  one.   Note that the code is shown as a segment,
  265.     rather  than  a  subroutine.   This is required because the text string
  266.     must  be  allocated  within  the context of the dialog handling routine
  267.     itself, rather than a routine which it calls!
  268.  
  269.        After  the  tree  address  is  found,  the code proceeds to find the
  270.     TEDINFO  and  modify  its  TE_PTEXT  as  described above.  However, the
  271.     length  which  is  inserted  into  TE_TXTLEN must be the maximum string
  272.     length, including the null!
  273.  
  274.        The  final  line  of code inserts a null into the first character of
  275.     the  uninitialized  string.   This  will produce an empty editing field
  276.     when  the  dialog  is displayed.  If there is an existing value for the
  277.     object,  you  should  instead use strcpy() to move it into text[]. Once
  278.     the  dialog is complete, you should check its final status as described
  279.     in  the last article.  If an "OK" button was clicked, you will then use
  280.     strcpy() to move the value in text[] back to its static location.
  281.  
  282.        Although  I  prefer  this  method of handling editable text, another
  283.     method  deserves  mention also.  This procedure allocates a full length
  284.     text  string of blanks when creating the editable object in the RCS. At
  285.     run-time,  the TE_PTEXT link is followed to find this string's location
  286.     in  the  resource,  and  any pre-existing value is copied in. After the
  287.     dialog  is  run,  the  resulting value is copied back out if the dialog
  288.     completed successfully.
  289.  
  290.        Note  that  in  both editing techniques a copy of the current string
  291.     value  is  kept  within  the  application's  data  area.  Threading the
  292.     resource  whenever  you  need  to  check  a string's value is extremely
  293.     wasteful.
  294.  
  295.        One  final  note  on  editable  text objects:  GEM's editor uses the
  296.     commercial  at sign '@' as a "meta-character".  If it is the first byte
  297.     of  the  initialized  text, then the field is displayed blank no matter
  298.     what  follows.   This  can be useful, but is sometimes confusing when a
  299.     user  in  all innocence enters an @ and has his text disappear the next
  300.     time the dialog is drawn!
  301.  
  302.  
  303.     LETTERS, WE GET LETTERS
  304.  
  305.        The  Feedback  section  on  ANTIC ST ONLINE is now functional and is
  306.     producing  a  gratifying  volume of response. A number of requests were
  307.     made  for  topics such as ST hardware and ST BASIC which are beyond the
  308.     intended  scope  of  this  column.  These have been referred to ANTIC's
  309.     editorial staff for action.
  310.  
  311.        So  many good GEM questions were received that I will devote part of
  312.     the  next  column to answering several of general interest.  Also, your
  313.     requests  have resulted in scheduling future columns on VDI text output
  314.     and  on  the  principles  (or  mythology)  of designing GEM application
  315.     interfaces.  Finally,  a  tip  of  the  hat to the anonymous reader who
  316.     suggested  including  the  actual  definitions of all macro symbols, so
  317.     that  those  without  the  appropriate  H files can follow along.  As a
  318.     result  of  this  suggestion,  the  definitions for this column and the
  319.     previous  three  are  included  at  the  end  of  the download.  Future
  320.     articles will continue this practice.
  321.  
  322.  
  323.     STRAW POLL!
  324.  
  325.        I'd  like  to  make  a  practice  of  using the Feedback to get your
  326.     opinions  on  the  column's format.  As a first trial, I'd like to know
  327.     your  feelings about my use of "portability macros" in the sample code.
  328.     These macros, LLGET for example, are used for compatibility between 68K
  329.     GEM systems like the ST, and Intel based systems like the IBM PC.  This
  330.     may  be important to many developers.  On the other hand, omitting them
  331.     results  in more natural looking C code.  For instance, in the download
  332.     you  will  find  a second version of set_text() as described above, but
  333.     without  the portability macros.  So, I would like to know if you think
  334.     we  should  (A)  Keep  the macros - portability is important to serious
  335.     developers,  (B)  Get rid of them - who cares about Intel chips anyway,
  336.     or  (C)  Who cares?  I'll tally the votes in two weeks and announce the
  337.     results here.
  338.  
  339.  
  340.     STAY TUNED!
  341.  
  342.        As  well  as  answers  to  feedback  questions, the next column will
  343.     discuss  how  GEM  objects are linked to form trees, and how to use AES
  344.     calls  and your own code to manipulate them for fun and profit.  In the
  345.     following  installment,  we'll  look at the VDI raster operations (also
  346.     known as "blit" functions).
  347.  
  348.  
  349.  
  350.  
  351. >>>>>>>>>>>>>>>>>>>>>>>>>> Sample C output file from RCS <<<<<<<<<<<<<<<<<<<<
  352.  
  353.                          /* (Comments added)     */
  354. BYTE *rs_strings[] = {               /* ASCII data          */
  355. "Title String",
  356. "Exit",
  357. "Centered Text",
  358. "",
  359. "",
  360. "Tokyo",
  361. "",
  362. "Time: __:__:__",
  363. "999999",
  364. "",
  365. "Time: __:__:__  ",
  366. "999999",
  367. "New York"};
  368.  
  369. WORD IMAG0[] = {                    /* Bitmap for G_IMAGE */
  370. 0x7FF, 0xFFFF, 0xFF80, 0xC00,
  371. 0x0, 0xC0, 0x183F, 0xF03F,
  372. 0xF060, 0x187F, 0xF860, 0x1860,
  373. 0x187F, 0xF860, 0x1860, 0x187F,
  374. 0xF860, 0x1860, 0x187F, 0xF860,
  375. 0x1860, 0x187F, 0xF860, 0x1860,
  376. 0x187F, 0xF860, 0x1860, 0x187F,
  377. 0xF860, 0x1860, 0x187F, 0xF860,
  378. 0x1860, 0x187F, 0xF860, 0x1860,
  379. 0x187F, 0xF860, 0x1860, 0x187F,
  380. 0xF860, 0x1860, 0x183F, 0xF03F,
  381. 0xF060, 0xC00, 0x0, 0xC0,
  382. 0x7FF, 0xFFFF, 0xFF80, 0x0,
  383. 0x0, 0x0, 0x3F30, 0xC787,
  384. 0x8FE0, 0xC39, 0xCCCC, 0xCC00,
  385. 0xC36, 0xCFCC, 0xF80, 0xC30,
  386. 0xCCCD, 0xCC00, 0x3F30, 0xCCC7,
  387. 0xCFE0, 0x0, 0x0, 0x0};
  388.  
  389. WORD IMAG1[] = {                    /* Mask for first icon */
  390. 0x0, 0x0, 0x0, 0x0,
  391. 0x7FFE, 0x0, 0x1F, 0xFFFF,
  392. 0xFC00, 0xFF, 0xFFFF, 0xFF00,
  393. 0x3FF, 0xFFFF, 0xFFC0, 0xFFF,
  394. 0xFFFF, 0xFFF0, 0x3FFF, 0xFFFF,
  395. 0xFFFC, 0x7FFF, 0xFFFF, 0xFFFE,
  396. 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
  397. 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
  398. 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
  399. 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
  400. 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
  401. 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
  402. 0xFFFF, 0xFFFF, 0xFFFF, 0x7FFF,
  403. 0xFFFF, 0xFFFE, 0x3FFF, 0xFFFF,
  404. 0xFFFC, 0xFFF, 0xFFFF, 0xFFF0,
  405. 0x3FF, 0xFFFF, 0xFFC0, 0xFF,
  406. 0xFFFF, 0xFF00, 0x1F, 0xFFFF,
  407. 0xF800, 0x0, 0x7FFE, 0x0};
  408.  
  409. WORD IMAG2[] = {                    /* Data for first icon */
  410. 0x0, 0x0, 0x0, 0x0,
  411. 0x3FFC, 0x0, 0xF, 0xC003,
  412. 0xF000, 0x78, 0x180, 0x1E00,
  413. 0x180, 0x180, 0x180, 0x603,
  414. 0x180, 0xC060, 0x1C00, 0x6,
  415. 0x38, 0x3000, 0x18C, 0xC,
  416. 0x60C0, 0x198, 0x306, 0x6000,
  417. 0x1B0, 0x6, 0x4000, 0x1E0,
  418. 0x2, 0xC000, 0x1C0, 0x3,
  419. 0xCFC0, 0x180, 0x3F3, 0xC000,
  420. 0x0, 0x3, 0x4000, 0x0,
  421. 0x2, 0x6000, 0x0, 0x6,
  422. 0x60C0, 0x0, 0x306, 0x3000,
  423. 0x0, 0xC, 0x1C00, 0x0,
  424. 0x38, 0x603, 0x180, 0xC060,
  425. 0x180, 0x180, 0x180, 0x78,
  426. 0x180, 0x1E00, 0xF, 0xC003,
  427. 0xF000, 0x0, 0x3FFC, 0x0};
  428.  
  429. WORD IMAG3[] = {               /* Mask for second icon */
  430. 0x0, 0x0, 0x0, 0x0,
  431. 0x7FFE, 0x0, 0x1F, 0xFFFF,
  432. 0xFC00, 0xFF, 0xFFFF, 0xFF00,
  433. 0x3FF, 0xFFFF, 0xFFC0, 0xFFF,
  434. 0xFFFF, 0xFFF0, 0x3FFF, 0xFFFF,
  435. 0xFFFC, 0x7FFF, 0xFFFF, 0xFFFE,
  436. 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
  437. 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
  438. 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
  439. 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
  440. 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
  441. 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF,
  442. 0xFFFF, 0xFFFF, 0xFFFF, 0x7FFF,
  443. 0xFFFF, 0xFFFE, 0x3FFF, 0xFFFF,
  444. 0xFFFC, 0xFFF, 0xFFFF, 0xFFF0,
  445. 0x3FF, 0xFFFF, 0xFFC0, 0xFF,
  446. 0xFFFF, 0xFF00, 0x1F, 0xFFFF,
  447. 0xF800, 0x0, 0x7FFE, 0x0};
  448.  
  449. WORD IMAG4[] = {               /* Data for second icon */
  450. 0x0, 0x0, 0x0, 0x0,
  451. 0x3FFC, 0x0, 0xF, 0xC003,
  452. 0xF000, 0x78, 0x180, 0x1E00,
  453. 0x180, 0x180, 0x180, 0x603,
  454. 0x180, 0xC060, 0x1C00, 0x6,
  455. 0x38, 0x3000, 0x18C, 0xC,
  456. 0x60C0, 0x198, 0x306, 0x6000,
  457. 0x1B0, 0x6, 0x4000, 0x1E0,
  458. 0x2, 0xC000, 0x1C0, 0x3,
  459. 0xCFC0, 0x180, 0x3F3, 0xC000,
  460. 0x0, 0x3, 0x4000, 0x0,
  461. 0x2, 0x6000, 0x0, 0x6,
  462. 0x60C0, 0x0, 0x306, 0x3000,
  463. 0x0, 0xC, 0x1C00, 0x0,
  464. 0x38, 0x603, 0x180, 0xC060,
  465. 0x180, 0x180, 0x180, 0x78,
  466. 0x180, 0x1E00, 0xF, 0xC003,
  467. 0xF000, 0x0, 0x3FFC, 0x0};
  468.  
  469. LONG rs_frstr[] = {               /* Free string index - unused */
  470. 0};
  471.  
  472. BITBLK rs_bitblk[] = {            /* First entry is index to image data */
  473. 0L, 6, 24, 0, 0, 0};
  474.  
  475. LONG rs_frimg[] = {               /* Free image index - unused */
  476. 0};
  477.  
  478. ICONBLK rs_iconblk[] = {
  479. 1L, 2L, 10L, 4096,0,0, 0,0,48,24, 9,24,30,8,     /* First pointer is mask */
  480. 3L, 4L, 17L, 4864,0,0, 0,0,48,24, 0,24,48,8};    /* Second is data, third */
  481.                                                  /* is to title string    */
  482. TEDINFO rs_tedinfo[] = {
  483. 2L, 3L, 4L, 3, 6, 2, 0x1180, 0x0, -1, 14,1,      /* First pointer is text */
  484. 7L, 8L, 9L, 3, 6, 2, 0x2072, 0x0, -3, 11,1,      /* Second is template    */
  485. 11L, 12L, 13L, 3, 6, 0, 0x1180, 0x0, -1, 1,15,   /* Third is validation   */
  486. 14L, 15L, 16L, 3, 6, 1, 0x1173, 0x0, 0, 1,17};
  487.  
  488. OBJECT rs_object[] = {
  489. -1, 1, 3, G_BOX, NONE, OUTLINED, 0x21100L, 0,0, 18,12, /* Pointers are to: */
  490. 2, -1, -1, G_STRING, NONE, NORMAL, 0x0L, 3,1, 12,1,    /* rs_strings       */
  491. 3, -1, -1, G_BUTTON, 0x7, NORMAL, 0x1L, 5,9, 8,1,      /* rs_strings       */
  492. 0, 4, 4, G_BOX, NONE, NORMAL, 0xFF1172L, 3,3, 12,5,
  493. 3, -1, -1, G_IMAGE, LASTOB, NORMAL, 0x0L, 3,1, 6,3,    /* rs_bitblk        */
  494. -1, 1, 6, G_BOX, NONE, OUTLINED, 0x21100L, 0,0, 23,12,
  495. 2, -1, -1, G_TEXT, NONE, NORMAL, 0x0L, 0,1, 23,1,      /* rs_tedinfo       */
  496. 6, 3, 5, G_IBOX, NONE, NORMAL, 0x1100L, 6,3, 11,5,
  497. 4, -1, -1, G_BUTTON, 0x11, NORMAL, 0x5L, 0,0, 11,1,    /* rs_strings       */
  498. 5, -1, -1, G_BUTTON, 0x11, NORMAL, 0x6L, 0,2, 11,1,    /* rs_strings       */
  499. 2, -1, -1, G_BOXCHAR, 0x11, NORMAL, 0x43FF1400L, 0,4, 11,1,
  500. 0, -1, -1, G_BOXTEXT, 0x27, NORMAL, 0x1L, 5,9, 13,1,   /* rs_tedinfo       */
  501. -1, 1, 3, G_BOX, NONE, OUTLINED, 0x21100L, 0,0, 32,11,
  502. 2, -1, -1, G_ICON, NONE, NORMAL, 0x0L, 4,1, 6,4,       /* rs_iconblk       */
  503. 3, -1, -1, G_FTEXT, EDITABLE, NORMAL, 0x2L, 12,2, 14,1,  /* rs_tedinfo     */
  504. 0, 4, 4, G_FBOXTEXT, 0xE, NORMAL, 0x3L, 3,5, 25,4,     /* rs_tedinfo       */
  505. 3, -1, -1, G_ICON, LASTOB, NORMAL, 0x1L, 1,0, 6,4};    /* rs_iconblk       */
  506.  
  507. LONG rs_trindex[] = {               /* Points to start of trees in */
  508. 0L,                                 /* rs_object                   */
  509. 5L,
  510. 12L};
  511.  
  512. struct foobar {                    /* Temporary structure used by    */
  513.      WORD     dummy;               /* RSCREATE when setting up image */
  514.      WORD     *image;              /* pointers.                      */
  515.      } rs_imdope[] = {
  516. 0, &IMAG0[0],
  517. 0, &IMAG1[0],
  518. 0, &IMAG2[0],
  519. 0, &IMAG3[0],
  520. 0, &IMAG4[0]};
  521.  
  522.                          /* Counts of structures defined */
  523. #define NUM_STRINGS 18
  524. #define NUM_FRSTR 0
  525. #define NUM_IMAGES 5
  526. #define NUM_BB 1
  527. #define NUM_FRIMG 0
  528. #define NUM_IB 2
  529. #define NUM_TI 4
  530. #define NUM_OBS 17
  531. #define NUM_TREE 3
  532.  
  533. BYTE pname[] = "DEMO.RSC";
  534.  
  535.  
  536. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Title change utility <<<<<<<<<<<<<<<<<<<<<
  537.  
  538.      VOID
  539. set_text(tree, obj, str)
  540.      LONG     tree, str;
  541.      WORD     obj;
  542.      {
  543.      LONG     obspec;
  544.  
  545.      obspec = LLGET(OB_SPEC(obj));           /* Get TEDINFO address  */
  546.      LLSET(TE_PTEXT(obspec), str);           /* Set new text pointer */
  547.      LWSET(TE_TXTLEN(obspec), LSTRLEN(str)); /* Set new length       */
  548.      }
  549.  
  550.  
  551. >>>>>>>>>>>>>>>>>>>>>> Text edit code segment <<<<<<<<<<<<<<<<<<<<<<<<<<
  552.  
  553.      LONG     tree, obspec;
  554.      BYTE     text[41];
  555.  
  556.      rsrc_gaddr(R_TREE, DIALOG, &tree);      /* Get tree address     */
  557.      obspec = LLGET(OB_SPEC(EDITOBJ));       /* Get TEDINFO address  */
  558.      LLSET(TE_PTEXT(obspec), ADDR(str));     /* Set new text pointer */
  559.      LWSET(TE_TXTLEN(obspec), 41);           /* Set max length       */
  560.      text[0] = '\0';                         /* Make empty string    */
  561.  
  562.  
  563. >>>>>>>>>>>>>>>>>>>> Sample 68K only source code <<<<<<<<<<<<<<<<<<<<<<
  564.  
  565.      VOID
  566. set_text(tree, obj, str)
  567.      OBJECT     *tree;
  568.      WORD     obj;
  569.      BYTE     *str;
  570.      {
  571.      TEDINFO     *obspec;
  572.  
  573.      obspec = (TEDINFO *) (tree + obj)->ob_spec;
  574.                                            /* Get TEDINFO address  */
  575.      obspec->te_ptext = str;               /* Set new text pointer */
  576.      obspec->te_txtlen = strlen(str);      /* Set new length       */
  577.      }
  578.  
  579.  
  580. >>>>>>>>>>>>>>>>>>>>>>>>>>>> Symbol definitions <<<<<<<<<<<<<<<<<<<<<<<<<
  581.  
  582.                               /* Window parts */
  583. #define NAME 0x0001
  584. #define CLOSER 0x0002
  585. #define FULLER 0x0004
  586. #define MOVER 0x0008
  587. #define INFO 0x0010
  588. #define SIZER 0x0020
  589. #define UPARROW 0x0040
  590. #define DNARROW 0x0080
  591. #define VSLIDE 0x0100
  592. #define LFARROW 0x0200
  593. #define RTARROW 0x0400
  594. #define HSLIDE 0x0800
  595.  
  596. #define WF_KIND 1                    /* wind_get/set parameters */
  597. #define WF_NAME 2
  598. #define WF_INFO 3
  599. #define WF_WXYWH 4
  600. #define WF_CXYWH 5
  601. #define WF_PXYWH 6
  602. #define WF_FXYWH 7
  603. #define WF_HSLIDE 8
  604. #define WF_VSLIDE 9
  605. #define WF_TOP 10
  606. #define WF_FIRSTXYWH 11
  607. #define WF_NEXTXYWH 12
  608. #define WF_NEWDESK 14
  609. #define WF_HSLSIZ 15
  610. #define WF_VSLSIZ 16
  611.                               /* window messages     */
  612. #define WM_REDRAW 20
  613. #define WM_TOPPED 21
  614. #define WM_CLOSED 22
  615. #define WM_FULLED 23
  616. #define WM_ARROWED 24
  617. #define WM_HSLID 25
  618. #define WM_VSLID 26
  619. #define WM_SIZED 27
  620. #define WM_MOVED 28
  621. #define WM_NEWTOP 29
  622.                               /* arrow messages     */
  623. #define WA_UPPAGE 0
  624. #define WA_DNPAGE 1
  625. #define WA_UPLINE 2
  626. #define WA_DNLINE 3
  627. #define WA_LFPAGE 4
  628. #define WA_RTPAGE 5
  629. #define WA_LFLINE 6
  630. #define WA_RTLINE 7
  631.  
  632. #define R_TREE 0                    /* Redraw definitions      */
  633. #define ROOT 0
  634. #define MAX_DEPTH 8
  635.  
  636.                               /* update flags           */
  637. #define     END_UPDATE 0
  638. #define     BEG_UPDATE 1
  639. #define     END_MCTRL  2
  640. #define     BEG_MCTRL  3
  641.                               /* Mouse state changes    */
  642. #define M_OFF 256
  643. #define M_ON 257
  644.                               /* Object flags           */
  645. #define NONE       0x0
  646. #define SELECTABLE 0x1
  647. #define DEFAULT    0x2
  648. #define EXIT       0x4
  649. #define EDITABLE   0x8
  650. #define RBUTTON   0x10
  651.                               /* Object states     */
  652. #define SELECTED  0x1
  653. #define CROSSED   0x2
  654. #define CHECKED   0x4
  655. #define DISABLED  0x8
  656. #define OUTLINED 0x10
  657. #define SHADOWED 0x20
  658.  
  659. #define G_BOX     20
  660. #define G_TEXT    21
  661. #define G_BOXTEXT 22
  662. #define G_IMAGE   23
  663. #define G_IBOX    25
  664. #define G_BUTTON  26
  665. #define G_BOXCHAR 27
  666. #define G_STRING  28
  667. #define G_FTEXT   29
  668. #define G_FBOXTEXT 30
  669. #define G_ICON    31
  670. #define G_TITLE   32
  671.                               /* Data structures     */
  672. typedef struct grect
  673.      {
  674.      int     g_x;
  675.      int     g_y;
  676.      int     g_w;
  677.      int     g_h;
  678.      } GRECT;
  679.  
  680. typedef struct object
  681.      {
  682.      int           ob_next;       /* -> object's next sibling      */
  683.      int           ob_head;       /* -> head of object's children  */
  684.      int           ob_tail;       /* -> tail of object's children  */
  685.      unsigned int  ob_type;       /* type of object- BOX, CHAR,... */
  686.      unsigned int  ob_flags;      /* flags                         */
  687.      unsigned int  ob_state;      /* state- SELECTED, OPEN, ...    */
  688.      long          ob_spec;       /* "out"- -> anything else       */
  689.      int           ob_x;          /* upper left corner of object   */
  690.      int           ob_y;          /* upper left corner of object   */
  691.      int           ob_width;      /* width of obj                  */
  692.      int           ob_height;     /* height of obj                 */
  693.      } OBJECT;
  694.  
  695. typedef struct text_edinfo
  696.      {
  697.      long          te_ptext;      /* ptr to text (must be 1st)     */
  698.      long          te_ptmplt;     /* ptr to template               */
  699.      long          te_pvalid;     /* ptr to validation chrs.       */
  700.      int          te_font;        /* font                          */
  701.      int          te_junk1;       /* junk word                     */
  702.      int          te_just;        /* justification- left, right... */
  703.      int          te_color;       /* color information word        */
  704.      int          te_junk2;       /* junk word                     */
  705.      int          te_thickness;   /* border thickness              */
  706.      int          te_txtlen;      /* length of text string         */
  707.      int          te_tmplen;      /* length of template string     */
  708.      } TEDINFO;
  709.  
  710.                          /* "Portable" data definitions */
  711. #define OB_NEXT(x)   (tree + (x) * sizeof(OBJECT) + 0)
  712. #define OB_HEAD(x)   (tree + (x) * sizeof(OBJECT) + 2)
  713. #define OB_TAIL(x)   (tree + (x) * sizeof(OBJECT) + 4)
  714. #define OB_TYPE(x)   (tree + (x) * sizeof(OBJECT) + 6)
  715. #define OB_FLAGS(x)  (tree + (x) * sizeof(OBJECT) + 8)
  716. #define OB_STATE(x)  (tree + (x) * sizeof(OBJECT) + 10)
  717. #define OB_SPEC(x)   (tree + (x) * sizeof(OBJECT) + 12)
  718. #define OB_X(x)      (tree + (x) * sizeof(OBJECT) + 16)
  719. #define OB_Y(x)      (tree + (x) * sizeof(OBJECT) + 18)
  720. #define OB_WIDTH(x)  (tree + (x) * sizeof(OBJECT) + 20)
  721. #define OB_HEIGHT(x) (tree + (x) * sizeof(OBJECT) + 22)
  722.  
  723. #define TE_PTEXT(x)  (x)
  724. #define TE_TXTLEN(x) (x + 24)
  725.