From: jpr@sun4.lri.fr (Jean-Pierre Riviere)
Newsgroups: comp.sys.amiga.misc
Subject: Path *and* ALIAS for Workbench
Date: 22 Jul 92 08:31:56 GMT
Organization: Laboratoire de Recherche en Informatique


In article <jbickers.0bms@templar.actrix.gen.nz>,
jbickers@templar.actrix.gen.nz (John Bickers) writes:
|> Quoted from <1992Jul20.124014@hp10.lri.fr> by jpr@hp10.lri.fr
|> (Jean-Pierre Riviere):
|> > I think that Workbench needs a path handling, just like a shell.
|> That
|> > would ease the
|> 
|> > What do you think about it ?

Hey, all of you who answered. First thanks you for this. But then, you
forgot the
*real need* for an handling of *alias* for the *workbench* !

What the hell of path if I have not the xyz-viewer the icon requested ?
With alias, I could say that xyz-viewer = MYviwer and so continue to be
happy :)

even more, we could *also* have several default tools on the icon. That
is alonme is a less good
solution than aliases, and is not very useful with well-made aliases.

What I want is an integreted and no-need-to-write-on-those-icons
mechanism just like the
one that oldfox@rieska.oulu.fi (sorry mate, I forgot your name) told me
about by email :
--------
I don't like the situation either.  My solution is to use a program
called
NewDefTool1.01 which can scan all the icons in a directory and replace
the
tooltypes that you specified in a text file.  For example, my
configuration
file looks like this:

TOOLS:                                       
(#?MuchMore|#?less||#?More)       tools:pager
#?XIcon                           C:IconX    
FILENAME:                                    
Read#?Me#?                        tools:pager
(#?.doc)                          tools:pager 

I'm very satisfied with the program.
------------

Now I can tell you that I still use 1.3. Thus I  was not aware of the
new PATH handling of 2.0.
I'm to upgrade as soon as C= release a new Amiga ;-) (I have to keep my
money for that BIG expense)

|> 
|>     I had something like this, for KS 1.2. It did a path, aliases and
|>     resident programs.
|> 
|>     I looked at doing it for KS 2.0 (in principle it would have been
|>     easier, because SetFunction()ing DOS is much more straightforward,
|>     and various shell things exist to make life nicer), except for one
|>     problem. The new Workbench tries its own path mechanism - if you
|>     watch it with a slick tool like SnoopDOS, it CDs to each directory
|>     on its path, then tries to LoadSeg() or somesuch the file from
|>     that directory.
|> 
|>     My 1.2 program worked by trapping LoadSeg(). Under 2.0, this means
|>     my patch would get called many times for a single user invocation
|>     of a program, which I think sucks. Also, it doesn't help that the
|>     1.2 version was shareware, which no-one registered... :)

I never heard of that program.
Beside, I already have LoadSeg patched cause of Powerpacked-library
executables.
That might explain a little more why none has registered...

|> 
|> --
|> *** John Bickers, TAP, NZAmigaUG.        jbickers@templar.actrix.gen.nz ***
|> ***    "Radioactivity - It's in the air, for you and me" - Kraftwerk    ***
-- 
  Jean-Pierre RIVIERE        |     ///
  LRI - Universite Paris Sud | \\\///
  e-mail : jpr@lri.lri.fr    |  \///