schultzd@kira.uucp (David Schultz) (12/17/90)
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*/
Problem Choice #2:
Incorrect parameters to form_do(). What exactly is this
function expecting? Is there a limit to the size of box form_do() can
handle? (Someone mentioned 25% of the screen. I need a bigger box.)
Anyway, hope thats enough. Please help me out on this one!
--
----- David W. Schultz -----
----- uunet!frith!schultzd -----
----- Work Phone: (517)-353-8891 -----
-- "Since my opinions are mine, I won't tell you who I work for." --gl8f@astsun9.astro.Virginia.EDU (Greg Lindahl) (12/18/90)
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
teexand@ioe.lon.ac.uk (Andrew Dawson) (12/19/90)
In <1990Dec17.055351.8596@msuinfo.cl.msu.edu> schultzd@kira.uucp (David Schultz) writes: >"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 a macro which takes an address and breaks it into 2 16 bits numbers. This is essentially a hangover from PC-GEM days. If your GEM libraries are correct, you can lose the ADDR > Incorrect parameters to form_do(). What exactly is this >function expecting? Is there a limit to the size of box form_do() can >handle? (Someone mentioned 25% of the screen. I need a bigger box.) (This is from memory only). I think you pass two parameters. The first is the address of the resource tree. The second should be zero unless your dialog has editable text objects, in which case it should be the resource index of the editable text object that the cursor is to be placed at. I believe some documentation tells you to pass -1 instead of 0 if no editable text strings are used, which is incorrect (I hope I got this the right way round!). I don't think there is a limit on size as long as it will fit on the screen. 25% is the size of the redraw buffer and applies to menus and alerts only. When your dialog is removed, a series of redraw events will be sent to the owner(s) of the windows underneath. Note that having too large a dialog may restrict the resolutions in which your application will work. -- Andrew Dawson, Computer Centre, University College London, Gower Street, London WC1E 6BT, England. JANET: ccaaand@uk.ac.ucl EARN/BITNET: ccaaand@ucl.ac.uk INTERNET: ccaaand%ucl.ac.uk@nsfnet-relay.ac.uk UUCP: ...!ukc!ucl.ac.uk!ccaaand