alen@crash.cts.com (Alen Shapiro) (03/01/90)
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!!.siegel@endor.harvard.edu (Rich Siegel) (03/01/90)
In article <1696@crash.cts.com> alen@crash.cts.com (Alen Shapiro) writes: > >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. Icky! >Q1) Could THINK protect its vital info and reinstate it at THINK return- > from-user-application. Not easily at the present time; the simplest workaround is to not muck with AppParmHandle. >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. You know you're running as a project if HomeResFile of CODE 1 is not equal to CurResFile. Under these conditions, you could conceivably restore the AppParmHandle to designate that your project (gotten from CurApName and CurApVRefNum) should be reopened; this may fool THINK C into reopening the project after you've run it. The safest way would be to not mess with it at all. >Would THINK consider enhancing the system to; [requests deleted] We will consider any and all suggestions. R. ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "When someone who makes four hundred and fifty dollars an hour wants to tell you something for free, it's a good idea to listen." ~~~~~~~~~~~~~~~