Path: utzoo!attcan!uunet!nuchat!sugar!peter
From: peter@sugar.uu.net (Peter da Silva)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Amiga Roadblocks to User Friendliness
Keywords: ASSIGNS
Message-ID: <3151@sugar.uu.net>
Date: 24 Dec 88 14:09:49 GMT
References: <9407@gryphon.COM> <1410010@hpcvca.HP.COM> <9910@gryphon.COM> <9946@gryphon.COM>
Organization: Sugar Land Unix - Houston, TX
Lines: 36

In article <9946@gryphon.COM>, keithd@gryphon.COM (Keith Doyle) writes:
> Now. Program B wants to use data files that are in the same directory
> as program B.  Program B also has to read a config file to find out what
> it's current directory is if it perhaps can't assume that an assign is
> available.  We are using the config file as a workaround for the lack
> of an assign, a facility which we DO have, so why not use it?

But this isn't the same thing as startup assigns, which hang around all the
time. There's nothing wrong with having PROGB (or PROGA, for that matter)
looking for an assign (set pr_WindowPtr to -1, then tru to Lock() the assigned
name) and only going to S:PROGB.CONFIG if it needs to. Also, there's nothing
very large in S:. If the disk activity bothers you copy it to RAM:.

> Ultimately, the best way to fix all these problems is to fix Execute() to
> correctly inherit the path of the parent process even when the parent was 
> invoked from an icon.

This is the bottom line. Execute() has serious brain damage, and I hope it's
fixed in 1.4. However, there is a workaround. Have PROGB called in a workbench
environment (CreateProc, then pass a startup message). PROGB can get its
current directory from WBStartup->sm_ArgList[0].wa_Lock. The code to do this
in the general case is available from the binary groups. It's completely clean,
there's no fudges and kludges needed to do it, and you get absolute verific-
ation that the program completed (your startup message is returned). If you
like I will repost my example program.

> In that instance, 99 percent of the reasons one
> needs startup assigns go away.  Startup PATH ADDs may still be necessary
> however, and there's no amount of config-file reading an application will
> be able to do to cure it if the PATH ADD is required to get to the application
> in the first place.

PATHs are irelevant to the Workbench, and presumably CLI users will be
sophisticated enough to know how to do these themselves.
-- 
Peter "Have you hugged your wolf today" da Silva  `-_-'  peter@sugar.uu.net