[comp.sys.mac.programmer] why is LSP complaining?

jbrugge@teknowledge-vaxc.ARPA (John Brugge) (12/14/88)

Using LSP 1.11 (waiting for 2.0 upgrade to arrive), I'm getting
either of
	"Illegal address exception"
or	"NIL reference (trap 0)"  (occurs most often)
while processing an update event.  It always occurs at the same
call:
		BeginUpdate(myWindow);
		...<other updating code>
	--->>	DrawControls(myWindow);
		...<other updating code>
		EndUpdate(myWindow);

and it doesn't seem to matter whether I put DrawControls()
between the Begin/EndUpdate -- it always stops at that routine
(the other portions of the update code use myWindow w/no problem).
This just started happening recently, after I tried adding some
code to do printing;  the application had worked fine before then,
so I removed the printing code (all in a seperate file), but
the problem stayed around.

The "Illegal address exception" supposedly is a good indication
that I'm accidently stepping on something I shouldn't be.  And as
they say, it's a difficult one to track down.  I believe them.
The "NIL reference", though, doesn't seem to be referring to myWindow;
after the program halts, I can do writeln's in the Instant window
using myWindow references with no problem.  And I've looked at
myWindow w/LightsBugs at various points before it stops, and it
doesn't look any different than after it stops (nor do any of
the control handles on its control list).

Further, I can build the project as an application and run that
with no problems (range-checking still on during the build).

Particulars: LSP v1.11, System 3.2, Finder 5.3 on a Mac XL(!)
  (although I've duplicated the behavior on a Mac Plus w/a later system)

Thanks for any clues,  (even if it's "wait for 2.0")
John

rj0z+@andrew.cmu.edu (Robert George Johnston, Jr.) (12/15/88)

    I have encountered the exact same problem that you describe. But, the
problem did not have anything to do with the window. It was the control's
fault. (Actually, it was my fault.) I had written a couple of custom
control definition functions, as pascal procedures, and given the
contrlDefProc a pointer to the procedure (@CustomControl).
    Don't do this. The compiled program code moves around, and suddenly,
when you attempt to redraw controls, the DrawControls procedure trys to
call a procedure that was were you told it, but has since then moved.
    Solution: Compile the controls as a code resource (CDEF), and use them
via the resource manager, (you can pass an ID code to NewControl, or use
it through a DITL and a CNTL).

    Rob Johnston.