home *** CD-ROM | disk | FTP | other *** search
/ The Fred Fish Collection 1.5 / ffcollection-1-5-1992-11.iso / ff_disks / 200-299 / ff281.lzh / MRARPFile / MRARPFile.DOC < prev    next >
Text File  |  1989-11-20  |  3KB  |  65 lines
  1.  
  2.             MRARPFile - Extended ARP File Support
  3.             Mark Rinfret, 10/89
  4.             Public Domain
  5.  
  6. This package constitutes a non-approved (at this time) extension to the ARP
  7. (Amiga  Resource  Project) programmer's support library.  It is intended to
  8. be used with ARP version 1.3 and higher.
  9.  
  10. I  like  ARP.   I  would  like all of my utilities to take advantage of its
  11. shared  library  and  resource  tracking.   While  attempting  to convert a
  12. program  which  appeared  on the net not long ago, I realized that it would
  13. have  been  nice, had ARP provided the FGets/FPuts routines.  Sure, you can
  14. simulate  FPuts with FPrintf, but that's kludgy.  You're still left hanging
  15. in the breeze when it comes to FGets.  So, I started writing...
  16.  
  17. As  usually happens, the tail started shaking the dog.  I spent all my free
  18. time  this weekend cooking up this package and the original goal has yet to
  19. be completed.  Hopefully, you'll find the effort worth it.
  20.  
  21. This   package  provides  an  orthogonal  set  of  routines  which  support
  22. generalized  I/O  with  resource  tracking (and early release, if you want)
  23. while  using  the  ARP  library.   There  are essentially 3 tracked objects
  24. associated with a file:
  25.  
  26.     - a structure describing the file
  27.     - the file itself
  28.     - an optional buffer
  29.  
  30. Access  to  files  is  gained  via  the  OpenARPFile function.  A companion
  31. routine, CloseARPFile, will release all resources associated with the file.
  32. You  need  not  call it, however, as ARP will release any as yet unreleased
  33. objects when the ARP library is closed.
  34.  
  35. File  buffering  is  optional,  and recommended when using the FGetsARP and
  36. FPutsARP  routines (typically used with text files).  A SeekARPFile routine
  37. allows you some freedom of access, in both input and output files, properly
  38. managing the optional buffers.
  39.  
  40. While  implementing  these  routines, I ran into a strange problem with the
  41. "LastTracker"  method  (actually a call to IoErr()).  Randomly, it seems, I
  42. would  get  a  -1L  rather  than  a  valid "struct DefaultTracker" pointer.
  43. However,  it  seems  that  register  A1  always contains the correct value.
  44. Therefore,  I wrote a little assembly language function which will retrieve
  45. A1  for  you.   In  order  for  it  to  be  effective,  it *MUST* be called
  46. immediately  after  calling  an  ARP  routine  which  allocates  a  tracked
  47. resource.  Example:
  48.  
  49.     myBuffer = ArpAllocMem(8192L, MEMF_PUBLIC|MEMF_CLEAR);
  50.     myTracker = StoreTracker();
  51.     if ( ! myBuffer ) {
  52.         ...Buffer not allocated? myTracker is invalid, then...
  53.     }
  54.  
  55. Please see the embedded documentation in the source for more usage info.  I
  56. feel  this  is  just  another  of those little hacks that anyone could have
  57. done,  but  I needed it and thus appointed myself to do it.  I hope some of
  58. you  out  there  find  it  useful.  I'd appreciate hearing any constructive
  59. comments that you might have.
  60.  
  61.                                             Mark Rinfret
  62.  
  63.                                             mrr@amanpt1.Newport.RI.US
  64.                                             BIX: markr
  65.