Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uwmcsd1!marque!gryphon!cadovax!keithd From: keithd@cadovax.UUCP (Keith Doyle) Newsgroups: comp.sys.amiga.tech Subject: Re: Launching new Tasks in C Keywords: BBS, IPC, tasks, processes Message-ID: <2148@cadovax.UUCP> Date: 13 Jul 88 22:42:40 GMT References:<11752@agate.BERKELEY.EDU> Reply-To: keithd@cadovax.UUCP (Keith Doyle) Organization: Contel Business Systems, Torrance, CA Lines: 85 In article <11752@agate.BERKELEY.EDU> pete@violet.berkeley.edu (Pete Goodeve) writes: >On the other hand, if for some > reason you wanted to invoke one module process from inside another, this > is pretty easy: simplest is to use the AmigaDOS call > > Execute("run module") > > (You would have to use "run" so you would come back to your invoking > module immediately.) You might LoadSeg() and CreateProc() instead, but I > don't see much advantage in that. Both Execute and LoadSeg()/CreateProc() have big problems because they lead to lots of situations that confuse the hell out of novice users. You have to do a Execute("run name:module",0,0); because Execute("run module",0,0); is equivalent to Execute("run df0:module",0,0); or maybe sys:module or something that bears no resemblance to what you are really trying to do. If you *do* do an Execute("run name:module",0,0); then either the novice can't boot off of *his* vanilla workbench disk because the assign name: doesn't get done, or you have to name the disk "name" and if you do that, the novice who forgets after backing up to edit the "copy of " out of the name, thinks the disk is copy protected because it keeps popping up requesters saying "please insert volume 'name' in any drive". You'd be surprised how many novices I've talked to who did edit "copy of" out of the name, but didn't catch the space between "of" and "name". It looks like it's the correct name, but AmigaDos doesn't treat them the same. If you use LoadSeg, you can specify a file without full path name, relative to the current directory which should be the one the original icon was clicked on. As long as all paths are relative to that directory, no assigning or disk-name assumptions have to be made. The problem with LoadSeg though, is if "module" itself want's to open files relative to the directory it is in, unless you can feed to the new CreateProc()'ed process your current directory, it won't work. I haven't yet checked to see if you can feed a created process it's current directory. I'm thinking the only real way to make this all work with a minimum of pain to the novice user, is for the original program to use successive ParentDir()'s to construct its full path name, build and Execute() an 'Assign here: currentdirpath' command and then have everyone use here: to find associated programs and files. Kludgy, but it works. What I'd like to be able to do (if it worked) is this: 1. boot a vanilla workbench, no custom Assigns in startup-sequence required. 2. put application disk in df1: or df2: or ??(and disk can be named anything) 3. click on drawer icon on application disk to open drawer named "appl" which contains subdirectory "stuff". 4. click on application icon in drawer "appl" 5. application does an Execute("run stuff/subpart",0,0); ^^^^^^ note relative to application's current dir, "appl" 6. "subpart" program does an Open("datafile",...). Where datafile is a relative reference (either to "appl" or "stuff", I could work within either constraint). 7. All of this stuff will still work flawlessly if you copy the entire application disk into a subdirectory on a hard disk. Unfortunately, this won't work as step 5 fails with a nonexistant command error reported on the CLI. This would work if run could find the command in the Executing program's current directory. Makes me wonder if a substitute RUN command could be created that would fix the problem. And you can't do an Execute("run :appl/stuff/subpart",0,0);, as that will violate condition 7. If I use the technique I described above constructing an Assign here: command, and the references in 1-7 above become here:stuff/subpart etc. it will work, and only makes the assumption that the Assign command is available. Kinda hate hardcoding Assign commands in programs, but nothing else seems to work, unless I can feed CreateProc it's current directory somehow. I still end up having to ParentDir it up the tree to find out what the complete current directory path is. If anyone can think of another method of meeting the 1-7 criteria above, I'd be glad to hear it. BTW, this also touches on a reason I have a big problem using anybodies *.library for anything useful, as novices don't have the foggiest notion on how to install them. An auto-install program has the problem that the vanilla workbench is too full, requiring something to be deleted. Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170