🚀 go-pugleaf

Perry's posting about file requesters made me think just a little bit
about my own preferences on file requesters.

My BIGGEST problem with them is that all that I have seen thusfar
place the FIRST 8 (5, 7 10?) files in the directory as the available
choices and you have to scroll down to get to the file you want.
Often when I am transferring files and so on, I wanna do the files
in sequence, so the file requester should present me with my list
of files, with its pointer positioned WHERE I LAST LEFT IT.

Also related to that same topic, I'd like to see an option that could
be enabled to allow me to delete a file from a file requester, in
addition to all of the other things that the file requester does.
If using a re-entrant file requester, this option should be disable-able
on a per-task basis.  E.G. if I have transferred this file already,
I may want to remove it and therefore not see it in the requester
any more.

Third wish - cacheing of the file directory contents on a per-task
basis, so that it is not necessary to seek all over creation to
build the file list for the requester.  Especially if there are
120 file and so on in a single directory (strange practice, but
it happens).  Suggest that each task pass a pointer to a data
structure of some kind similar to this:

	#define NEWFILEDIR 0
	#define SEARCHFILE 1
	#define ENDFILEDIR 2

	struct FileDir {
		char *dir;	/* pointer to full pathname */
		char *dirlist;  /* pointer to first character of
				 * a string of filenames,
				 * each name a null-terminated string*/
		char *chosen;	/* pointer to the filename that was chosen
				 * or to a string that describes a directory
				 * for which a list is to be built */
		int pathsize;	/* size of the pathname string */
				/* (REDUNDANT, available from strlen) */
		int listsize;	/* size of the filename list */
		int chosensize; /* size of the chosen filename */
				/* (REDUNDANT, available from strlen) */
		int action;	/* what to do this time */
		int sliderpos;  /* where did I leave the slider? */
		struct DateStamp ds; /* when did we build this list */
	};

User allocates one of these data structures for EACH directory
he wishes to cache.  Then sends the address of this data structure
to the file requester.

(BEGIN PSEUDOCODE)

switch (pointer->action)

case NEWFILEDIR - (also to "reuse" an existing one, "pointer" is
			address of start of the data structure,
			does NOT present the file requester to the user)

	if (pointer->path != NULL) 
	    FreeMem(pointer->path, pathsize)
        if (pointer->dirlist != NULL)
	    FreeMem(pointer->dirlist, listsize)
		if chosen == NULL, build path string for CURRENT dir.
		else               build pathstring for CHOSEN dir.
	    pointer->path = AllocMem(sizeof(pathstring+TRAILING NULL)
	    COPY pathstring to pointer->path
	    pointer->pathsize = 1 + strlen(pointer->path)
	    BuildFileList()  [ searches files in chosen path,
				allocates memory for dirlist
				and sets listsize
				and sets datestamp
				and sets slider to first file]
	    return(0) if no errors along the way, else return error value

case SEARCHFILE
	See if file directory's last-modified date is later than
	the datestamp in the data structure.  If directory modified,
	do NEWFILE case, otherwise present the directory from the
	current dirlist. (No disk seeking -- super-speedy because
	the lists are already in memory) If user chooses a directory 
	rather than a file, modify everything in the structure and present 
	the information for that new directory instead.  When user chooses
	a file instead of a directory, return (0) and delete the file
	requestor.  Set sliderpos to have this file name at the top
	of the list the next time the requester is presented.
	User finds the chosen path in "path" and the
	file in "chosen".  Otherwise error code is the return value.

case ENDFILEDIR
	Deallocate everything "attached" to the passed in FileDir
	structure, and set the pointer values to NULL and the
	sizes to zero.

(END PSEUDOCODE)

The reason I propose something like this is then a program can
maintain as many "cached" directories as it wishes, and pass to the
file requester the pointer to the one it wants to choose from.

The above proposal may, of course, be incomplete, but I hope it
gives the re-entrant file requester writers something to think about.

And, for that matter, perhaps this pointer can be part of an AREXX
message so that we get the benefit of AREXX compatibility at the
same time.

Rob Peck			...uunet!ardent!rap