Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!van-bc!ubc-cs!fornax!mcdonald
From: mcdonald@fornax.UUCP (Ken Mcdonald)
Newsgroups: comp.sys.mac.programmer
Subject: THINK C problems followup, suggestions
Message-ID: <390@fornax.UUCP>
Date: 3 Mar 90 23:04:55 GMT
Distribution: na
Organization: School of Computing Science, SFU, Burnaby, B.C. Canada
Lines: 41

A little while ago, I sent out a message concerning problems I was having
with THINK C 4.0--it wouldn't print properly, and it caused system
crashes after quitting the program.  This is the followup to that, along
with some suggestions--and kudos!

I messed around with THINK C for quite a while, trying to get the printing
to work.  No go, it kept on spewing out gibberish.  Finally, I replaced
all my system files.  Now THINK C wouldn't print at all.  In desperation,
I tried to print from FullWrite, which graciously informed me that it
couldn't print until I chose a printer.  When it did print, it also
spewed gibberish.  The problem--a loose printer cable!

Moral--just because two problems occur together, don't assume they have
the same cause.  Because THINK C was causing my system to crash, I assumed
it was the reason for my printer spewing gibberish, when the real reason
was because I had moved the printer.

Suggestion--THINK C really oughta warn people if they haven't chosen a
printer.  As it is, it just doesn't do anything, and I spent a good half-
hour trying to get it to work before I clued into the problem.

The second problem, that of the system crashing after I exit from THINK C
(even when I haven't run any of my own code) still remains, although it
seems to have been reduced after I turfed a bunch of INITs.  I haven't been
able to track down the exact problem, and don't really have the time to
put a lot of effort into it.

On the plus side, the last few days mark the first time I've had to
really use THINK C.  The debugger is wonderful!  Congrats all 'round,
Rich, to you and the people involved in this language.  One suggestion
here--I find myself running debugging sessions which are very similar
to one another, in that I want to look at the same variables, set the
same breakpoints, etc.  It would be nice if there were a way for the
debugger to remember these settings.  It would be even nicer if, right
in the source code, a programmer could specify where breakpoints should
be set, which expressions should appear in the data window, etc.

Hope the above has been of some use.  To someone.  Somewhere.

Ken McDonald
{mcdonald@cs.sfu.ca}