Path: utzoo!mnetor!tmsoft!torsqnt!jarvis.csri.toronto.edu!rutgers!ucsd!ucbvax!hplabs!pyramid!bjb
From: bjb@pyramid.pyramid.com (Bruce Beare)
Newsgroups: comp.sys.mac.programmer
Subject: Problem with LSC 4.0 debugger.
Message-ID: <85031@pyramid.pyramid.com>
Date: 19 Sep 89 16:21:29 GMT
Distribution: na
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 32

The think C 4.0 debugger is not able to show stack variables for
functions that are 1 or more calling frames "up" the stack. For instance,
put a breakpoint at the the severe error code in the errors class and
execute some code that creates a window with a WINDid that is not in
the project resource file. Your stack trace would look something like:

	Cobjectsdir: Iobjectsdir
	CTearoffMenu:Itearoffmenu
 ---->	Cwindow:Iwindow
 |	CheckResource
 |	CError:SevereMacError
 |
 |
The Cwindow:Iwindow stack frame calls CheckResource just after a call
of GetResource('WIND', WINDid). Since WINDid was not in the resource
file, the CheckResource will call SevereMacError.

My complaint is that I can't use the "data" window to look at the
value of WINDid in Cwindow:Iwindow - because it is a stack variable.
This behavior of LSC's Debugger is silly. It has all of the information
it needs - it knows the stack offset of WINDid (it can display it if
we put a breakpoint in the function Cwindow:Iwindow - before calling 
CheckResource), and it knows how to trace through the stack frames.
It just doesn't bother to display the information.

I've discussed this with Think's support - Darell (sp?), and he has agreed
that this "would be a useful feature" and might be looked at in a future release. 
My intention here is to raise the point for discussion and hopefully convince
Think that it is a real deficiency that should be addressed soon.


Bruce Beare