home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / os / os2 / apps / 9552 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  1.9 KB

  1. Path: sparky!uunet!gatech!prism!gt1610c
  2. From: gt1610c@prism.gatech.EDU (Michael Kenneth McGaugh)
  3. Newsgroups: comp.os.os2.apps
  4. Subject: Re: Drag and Drop Compression
  5. Message-ID: <78650@hydra.gatech.EDU>
  6. Date: 20 Dec 92 19:13:05 GMT
  7. References: <1992Dec19.234613.12909@waikato.ac.nz> <BzIptG.D2n@ucunix.san.uc.edu>
  8. Organization: Georgia Institute of Technology
  9. Lines: 30
  10.  
  11. In article <BzIptG.D2n@ucunix.san.uc.edu> kreinddm@ucunix.san.uc.edu (David M Kreindler) writes:
  12. >I called IBM Tech Support the other day, and asked 'em to tell me how an
  13. >app could be set up to accept multiple files via the drag-n'-drop method
  14. >from the desktop.  I was told that it's a 'program design issue': i.e.,
  15. >if you want to be able to drag multiple files to a single application,
  16. >and have the application run (as a single invocation of the program) on
  17. >the bunch of files passed, you have to *write* the program that way --
  18. >there's no way to set up the WPS to pass multiple arguments to a single
  19. >program by the drag'n'drop method if it wasn't designed as such from
  20. >scratch.  FYI.
  21.  
  22. Could someone write a small program (WPS/SOM aware) to accept multiple
  23. files being dropped onto it, and then pass all of these to any arbitrary
  24. app such as zip.  I once tried something similar with REXX.  If n files
  25. were dropped onto the program object for this REXX script, n instances
  26. of this script would start.  However, the first one would open up a
  27. system wide queue, and the others would know that they were not the first
  28. one since the queue would already exist.  They would each write there
  29. argument to the queue, and then the first one would pass all of these
  30. arguments to zip.  I never got it working write since timing was a 
  31. problem.  Perhaps it would have been easier with named pipes, but I
  32. have no experience with named pipes.
  33.  
  34. Ken.
  35.  
  36. -- 
  37. M. Ken McGaugh
  38. Georgia Institute of Technology, Atlanta Georgia, 30332
  39. uucp:      ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt1610c
  40. Internet: gt1610c@prism.gatech.edu
  41.