Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!sdsu!crash!alen
From: alen@crash.cts.com (Alen Shapiro)
Newsgroups: comp.sys.mac.programmer
Subject: THINK C 4.0 sublaunch woes (welcome back Rich)/enhancement requests
Summary: sublaunch+doc works except from project-launch
Keywords: sublaunch think C
Message-ID: <1696@crash.cts.com>
Date: 28 Feb 90 17:58:39 GMT
Reply-To: alen@crash.cts.com (Alen Shapiro)
Organization: Crash TimeSharing, El Cajon, CA
Lines: 67

Hey Rich - welcome back. Here's a simple one for you which has been tracked
right down to the line of code that causes the problem.

Seems that when running an application from within the project, the
appparmhandle-info needs to survive the application for THINK C 4.0
to be able to restart after the user-application has run. Under MF
I would have thought this unnecessary, under finder it seems essential.
(though I would not want to be the poor programmer who has to test
if MF is present to switch options on/off :-))

One of the ramifications is that if a user-application performs a sublaunch
for which a startup document is provided, appparmhandle may be resized
and/or relocated causing the restart of THINK C to go into a recursive
loop when the application has finished. Eventually the mac runs out
of stack and bombs.

Program works fine as an application but I can't test/debug within
LSC. (I've #ifdef'd the launch for testing purposes as a work around).

Q1) Could THINK protect its vital info and reinstate it at THINK return-
    from-user-application.
Q2) If no, could you provide me with a couple of lines of code that I
    could insert in my user-application that would recreate the heap
    such that THINK C would not die on return
Q3) If no/yes, how would I detect if I'm running from within a LSC
    project so as not to restore/screw-things-up if my application
    was not started within a project.

I have a small application that I'd be happy to send you that illustrates
the problem down to the single line of code that resizes appparmhandle
so that it may accept the document info for the user-sublaunch.

I'd like to express my delight at being able to work with LSC on the mac
It almost makes banging ones head against the mac development system
fun :-) - seriously though, I enjoy working in LSC. Could you comment
on the following requests please (nothing rude now)?

Would THINK consider enhancing the system to;

1) provide electric-C like support (I type "for(" and the editor adds
    "; ; ) {
  }")
 etc for other C constructs (I type "/*" and the editor types the "*/" but
 leaves the insertion point within the comment block).

2) when the insertion point/selection is off screen, auto scrolling the
   window to keep some of it visible (useful for off-screen finds in long lines)

3) allowing finds and debugging to work when #include name.c occurs
   within a program. I know this is BAD style but I'm trying to support
   an existing program which uses C inclusions in vital places and
   it would be difficult to unwrap without a redesign. The think debugger
   does not recognise lines of C code that are #included as break-pointable
   nor does the multi-file search look through these files

4) a multi-file grep that would allow the user to search a wild-card
   selectable set of files not necessarily found within the project, would
   be great too!!

thanks in advance for you time and attention

--alen the Lisa slayer (learning to slay macs)
...alen%shappy.uucp@crash.cts.com (a mac+ uucp host - what a concept!!)
...alen@crash.cts.com

attention macuucp'ers, I'm working on a multifinder-friendly (backgroundable)
uucp, don't hold you breath but I'll get there yet!!.