MAC.ROMOS@applelink.apple.com (Ian Hendry) (05/23/89)
In article <1386@ndmath.UUCP> dierks@ndmath.UUCP (Tim Dierks) writes: > I'd like to see including a precompiled file add its source and any >files > it includes to this menu. That way I could include the precompiled MacHeaders, > but still be able to bring up the header files it was compiled from, >which I > use as a reference farily often. ... > they could also be included in the Multi-File search dialog box. I agree 100%! One thing I would NOT like to see is a huge list of includes (MacHeaders usually has a lot of files) when I option-clicked on the title bar. Still, I often find myself wishing there was some easy way to get at those includes. Perhaps a hierarchical menu for the precompiled includes at the top or bottom of the other includes...? Well something anyway... Ian Hendry MAC.ROMOS@applelink.apple.com Make sure my name is in the subject of any Email, or post replies to network. TE: 408-974-4737 Disclaimer: It was all HIS idea anyway! Nothing I say reflects anything my employer means... or anything I mean for that matter.
pcossenb@rodan.acs.syr.edu (Paul C. Ossenbruggen) (05/23/89)
While on the subject of improvements to LSC, which I have been using for about three years, I thought I would add some of my rather small suggestions. When LSC opens the resource file that has the same name as your project with the .rsrc extension it does not check to see if that resource file is already open from another application. This is a major problem when you are using ResEdit and LSC together in a Multifinder environment because, depending on is going on at the time, the machine may hang badly if you accidentally forget to close the resource file in ResEdit and try to run your program. I have tried to resolve this problem by checking ResError() before the program does anything else but it still crashes. Any suggestions? So it would be really nice if LSC put up a dialog box saying that the resource file is already open - sort of like ResEdit does. Another problems was with the Find... dialog doing multi-file searches. I have found a undocumented feature (at least I can't find it) which greatly improves the situation. It was a slow procedure to click on the Multi-file search button to select all of the .c files. The solution I found was to type Command-A in the main Find dialog and LSC will check all the .c files in the project. This is so much faster. So this really is not a problem now, but it was just chance that I found that solution. Had anyone else known that? There needs to be a better way to handle multiple small code resources. I had this project once that needed lots of little code resources to be loaded in while the program was running. It was a real pain to have a separate project for each of the little code resources. Especially since, they all shared a common header file and if I changed the header I would have to reload each project file one by one and recompile them. I suppose MPW would be better for something like this (I can't afford that). It is sometimes useful to have more than one copy of LSC running at one time. However, the Debugger does not know what to do when you have two copies of LSC running with the Debugger on. Last time I tried it it crashed. Either LSC should not allow this or it should allow two debugger sessions to be run. I also agree that there should be some easy way to get to the files in the Macheaders file or to access reference files. How about a user configurable menu that allows you to attach files that you frequently look at. Right now I put the entire reference file in comments, add a .c extension and add it to my project. There ought to be a better way. I find the LSC programming environment is wonderful. I really want to thank Think for the symbolic debugger. It has saved me an incredible amount of time. I can hardly wait for Object C and later C++. - Paul ------------------------------------------------------------------------------- | Paul C. Ossenbruggen pcossenb@rodan.acs.syr.edu | | Syracuse University rspco@suvm.bitnet | | pcossenb@sunrise.acs.syr.edu |
MAC.ROMOS@applelink.apple.com (Ian Hendry) (05/25/89)
In article <1575@cmx.npac.syr.edu> pcossenb@rodan.acs.syr.edu (Paul C. Ossenbruggen) writes: > When LSC opens the resource file that has the same name as your project with > the .rsrc extension it does not check to see if that resource file is already > open from another application. This is a major problem when you are using > ResEdit and LSC together in a Multifinder environment because, depending on > is going on at the time, the machine may hang badly if you accidentally forget > to close the resource file in ResEdit and try to run your program. If APPL_CREATOR is defined to be your signature type (appl CREATOR) which is present anyway, Try adding the following ugly hack to your InitMac function after you initialize the managers: if (0 == (h=GetResource(APPL_CREATOR,0)))/* check to see if I can get at my resources */ { SysBeep(1);SysBeep(1);ExitToShell(); } else ReleaseResource(h); If your resource file is open in another app(ResEdit), the GetResource will fail and you will exit with some beeps to let you know what happened. > There needs to be a better way to handle multiple small code resources. I had > this project once that needed lots of little code resources to be loaded in > while the program was running. One thing you might try is a trick from ??MacTutor?? where you load the resource at the start of your program and patch it so that calls made to the resource get sent to your application instead...namely the same source code included in your app. Eats memory, but it also buys you the use of the source level debugger with your CODE resources. An example of the resource patching is as follows: { ProcPtrproc; Ptrpointer; proc = (ProcPtr )__Xmain; h = GetResource('LDEF',129); HNoPurge(h); pointer = (Ptr )StripAddress((Ptr )*h); asm { Move.lpointer,A0 Move.w#0x4EF9,(A0)+; JMP$Absolute Move.lproc,(A0) }; } I include the source code for the LDEF 129 in my application project and put a #define main __Xmain at the top of the LDEF's source code. Make sure that the segment containing the LDEF source does not get unlocked or purged or the pointer will be invalid. Obviously you could make this a function if you had a lot of resources that you were developing. When you are done with development, just recompile the code resource without the "#define main __Xmain", remove the patch code, and copy the resource into your App resource file. Along the same line I would like to see an option for a NON-DESTRUCTIVE BUILD. That is a build that does not erase the file that you are building, only the resources you are replacing. If you are developing a CDEV/INIT both the CDEV and the INIT are separate projects and you cannot build them both into one file (say in your system folder for convenience). Building the CDEV deletes the destination file and any resources in it including the INIT and vis versa. It would be nice if I could specify that I would like these project to only replace: (1) resources that I was building and (2) resources in the .rsrc file. It would save a lot of needless ResEdit work. Ian Hendry MAC.ROMOS@applelink.apple.com Make sure my name is in the subject of any Email, or post replies to network. TE: 408-974-4737 Disclaimer: It was all HIS idea anyway! Nothing I say reflects anything my employer means... or anything I mean for that matter.
gillies@m.cs.uiuc.edu (05/25/89)
Here is a suggestion for LSC access to header files. This is the
method used in the XDE/MESA development environment:
The editor/compiler has a source-file search path. The path is part
of the LSC configuration information, set via "Preferences" or
something. It would normally have a list of directories, such as
"PRO80:LSC:Mac.h PRO80:LSC:Unix.h ...".
Imagine editing a source file (start.c) and you want to refer to
"stdio.h". You first select the text "stdio.h" and then invoke the
menu command "QuickOpen" or something. The system takes the selection
"stdio.h", and looks for the file along the search path. If it finds
the file, then it opens it in a new window.
This is a really speedy way to follow links (not just "include" links)
between source files; I unconditionally recommend it.
Don Gillies, Dept. of Computer Science, University of Illinois
1304 W. Springfield, Urbana, Ill 61801
ARPA: gillies@cs.uiuc.edu UUCP: {uunet,harvard}!uiucdcs!gillies