Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!gatech!mcnc!uvaarpa!murdoch!astsun9.astro.Virginia.EDU!gl8f
From: gl8f@astsun9.astro.Virginia.EDU (Greg Lindahl)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Dialog Box Woes
Message-ID: <1990Dec18.051742.835@murdoch.acc.Virginia.EDU>
Date: 18 Dec 90 05:17:42 GMT
References: <1990Dec17.055351.8596@msuinfo.cl.msu.edu>
Sender: news@murdoch.acc.Virginia.EDU
Organization: Department of Astronomy, University of Virginia
Lines: 58

Well, nobody answered this in public, so I'll give it a shot.

In article <1990Dec17.055351.8596@msuinfo.cl.msu.edu> schultzd@kira.uucp (David Schultz) writes:
>I get three bombs in a dialog box prog that I wrote.  I narrowed it
>down to one of two things, but I don't have the documentation on the
>function calls used.
>
>Problem Choice #1:
>	Incorrect use of the rsrc_load() function.  Tim Oren's
>"Professional GEM" says use...
>	ok = rsrc_load(ADDR("blahblah.rsc"));
>	(When I compile under sozobon with GEMFAST lib, I get _ADDR is
>undefined.)
>	Instead, I use ...
>	ok = rsrc_load("blahblah.rsc");	/*This compiles*/

ADDR() is one of the "portability macros" that allows you to write GEM
source that will compile both on the ST and for IBM PC GEM. Few if any
people use them anymore. This is mentioned at the end of Pro GEM IV,
and in part XVI he stops using them.

I think the basic rule is that you can always pretty much delete them.

>Problem Choice #2:
>	Incorrect parameters to form_do().  What exactly is this
>function expecting?

form_do() expects the address of the tree and an integer # of the
first text field. You can get the address of the tree by using
rsrc_gaddr() or by a hack. Let's see, this is how my program TeXShell
loads and displays the menu bar, which was called MYMENU in
the RCS:

#ifdef RCS
  rsrc_load( "texshell.rsc" );
  rsrc_gaddr( 0, MYMENU, &menu_adrs );
#else
  fix_objects();
  menu_adrs = rs_trindex[ MYMENU ];
#endif

  menu_bar( menu_adrs, 1 );

The first version reads in a .rsc file and uses the function call to
get the address. The root of the tree in this case is object 0.

The second version uses the fact that my resource-to-C conversion
program sticks the addresses of the object trees into an OBJECT *
array called rs_trindex. This is a little more obvious if you look at
the output of the conversion program.

>  Is there a limit to the size of box form_do() can
>handle?  (Someone mentioned 25% of the screen.  I need a bigger box.)

I don't know, but if you start small you should be able to get it to
work without bombs. When GEM gets confused, bombs away.

-- greg