Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!pasteur!ames!amdahl!rtech!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Dialog Crash
Keywords: Get/Set IText?
Message-ID: <7476@hoptoad.uucp>
Date: 30 May 89 21:28:47 GMT
References: <1415@ns.network.com>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 69

In article <1415@ns.network.com> jmh@ns.UUCP (Joel Halpern 424-1606) writes:
>In an application I am attempting to write, I have a dialog with one
>edittext item (item 2).  When the dialog is requested from the menu,
>the routine starts with:
>
>char strbuf[60];
>GetDItem(dialog, 2, handle);

Incorrect call to GetDItem.  Both MPW and LSC would flag this as having
too few parameters.  Check the calling sequence in Inside Mac.  Even
after you correct this to include "itemType" and "box", you will have
to watch your VAR parameters; that "handle" needs to be "&handle".  LSC
would *not* flag this error, since it only checks argument sizes to
toolbox traps, and a pointer to a handle is the same size as a handle.

>/* set the string at strbuf+1 to the desired display */
>trbuf[0] = strlen(strbuf+1);
>SetIText(handle, strbuf);

Could work, assuming there's a C string of no more than 58 characters
at strbuf + 1.  But how'd that get there?  If you called GetIndString,
you need to provide a 256-character buffer.  If you put it as a string
constant, shame on you....

>Then I enter a loop:
>
>do {
>	ModalDialog(dialog, &theItem);

Incorrect call to ModalDialog.  I can't believe this would run even
once without crashing, because you are passing your dialog pointer as
the address of a filter routine.  The PC will be JSR'd to the dialog
pointer, and havoc will ensue.  Is this the actual code?  If not,
there's no way the net will be able to find your problem.

>	if (theItem == 2) {
>		GetDItem(dialog, theItem, handle);
>		GetIText(handle, strbuf);
>		/* process input */

For all we know, the crash might be in "process input"....

>	}
>} while (theItem != 1 && tehItem != exititem);

Clearly not the actual code; your references to "tehItem" and "trbuf"
make that clear.  However, I would beware of passing any string of less
than 256 characters to a routine like GetIText or GetIndString that
takes a Str255.  It's definitely not safe with GetIText, since the user
can crash your program just by entering more than 59 characters in this
case; many implementations of GetIndString also assume they can use a
256-character buffer.  Also, you've called GetDItem wrong again.

>This all works fine the first time I call it.  However,
>the second time, the whole system hands.

This code wouldn't even compile, much less run.  Please use cut and
paste in your terminal emulator to post the actual code.  However, my
guess would be that you need to be using "&handle" in the GetDItem
calls and all the other problems are artifacts in retyping the code,
not present in the orginal.  The GetDItem calls wouldn't compile as you
have them, and the ModalDialog call would crash every time, practically
guaranteed by God.
-- 
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
"Disclaimers are for running-dog lackeys of the bourgeoisie; free-thinking
members of the proletariat such as myself have their own opinions, and do
not need to express those of their oppressive capitalistic employers!
Nyah!" -- James Heath