Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!hoss!fergvax!231b3678
From: 231b3678@fergvax.unl.edu (Phil Dietz)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: Even MORE features to add to JRCOMM
Message-ID: <1991Feb13.033400.21259@hoss.unl.edu>
Date: 13 Feb 91 03:34:00 GMT
References: <9102130227.AA20204@bisco.kodak.COM>
Sender: news@hoss.unl.edu (Network News Administer)
Organization: Comp Sci and Engr, Univ. of Nebr.
Lines: 45

In article <9102130227.AA20204@bisco.kodak.COM> amusing!lordbah@bisco.kodak.COM writes:
>> The 1.1 release will remove the internal file requester in favor of using
>> req.library and any other external file requester.  A font requester will
>> be added as well.
>> 
>> Unfortunately, this will eliminate the unique ability of the JR-Comm
>> file requester being able to multi-select files from across different
>> directories and volumes, but the gain in using a common requester across
>> different applications should outweigh this.
>> 
>> Comments anyone?
>
>Will it still allow multiple selections within one directory?  I use
>this sometimes when sending files via Zmodem to a UNIX box, and I
>wouldn't like to see it disappear just because of "standards".  I've
>never selected files from more than one directory at a time, though.
>
>--------------------------------------------------------------------
>    Jeff Van Epps    amusing!lordbah@bisco.kodak.com
>                     lordbah@cup.portal.com
>                     sun!portal!cup.portal.com!lordbah

Jack said that the new requester will handle multiple files, but it will NOT
allow the files to be on multiple drives/directories.  Meaning-- you can't
upload a file from df0: and a file from ram: during the same batch upload.
 
Oh well.
 
Phil Dietz
 
ps.  I kinda like the requester JRCOMM has.  It has that neat and quick 
     button that allows you to QUICKLY switch to an assigned drive, 
     a drawer, or a mounted device easily.  If Jack would incorporate
     a BUFFERED option, the requester would be perfect.  True, the argument
     takes precedence about how JRCOMM EATS memory, but when XPR is added,
     and all the pud protocals taken out, the added buffer option should
     still make the executable smaller then before XPR and buffered stuff
     was added.



---                    
   FACT:  the Nebraska Cornhuskers                           Phil Dietz 
          signed a contract to lose the        231b3678@fergvax.unl.edu       
          big games!  Yes, it's true!                 Univ. of Nebraska