Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!bellcore!texbell!sugar!peter
From: peter@sugar.hackercorp.com (Peter da Silva)
Newsgroups: comp.sys.amiga.tech
Subject: Re: File Requesters
Keywords: REENTRANT FILE REQUESTERS
Message-ID: <3814@sugar.hackercorp.com>
Date: 12 May 89 01:56:19 GMT
References: <6342@ardent.UUCP> <103440@sun.Eng.Sun.COM> <11584@well.UUCP>
Distribution: na
Organization: Sugar Land Unix - Houston
Lines: 36

In article <11584@well.UUCP>, shf@well.UUCP (Stuart H. Ferguson) writes:
> +-- peter@sugar.hackercorp.com (Peter da Silva) writes:
> | In article <>, cmcmanis%pepper@Sun.COM (Chuck McManis) writes:
> | > This is a very simple operation. And to be effective should stay simple. 
> | > 	FileLock = Request("Prompt", DirLock, Access_mode);

> | Too complex. What if I want a file name? What if I want to open it later?
> | How about handling overwritten/nonexistent files?

> | 	Status = Request(Title, Pattern, DirectoryLock, Buffer);

> What if I want a LIST of files?  Like, open a requester and let the user
> select a whole bunch then say OK and crunch on them in sequence.

You can use my InstantApplication tool, which works something like:

	Status = Instant(Title, Pattern, DirectoryLock, Buffer, Funclist);

Where FuncList looks something like:

	struct {
		int (*Function)();
		char *Tag;
	} FuncList[];

And it provides a menu and lets the user can select files and pass them to
your functions. A very early version of what became Browser.

[ locks versus names ]

What Browser uses internally, by the way, is a WBArg structure containing
a lock and a pointer to a filename in the directory referred to by that lock.
This gives you the best of both worlds.
-- 
Peter "Have you hugged your wolf today" da Silva      `-_-'
...texbell!sugar!peter, or peter@sugar.hackercorp.com  'U`