home *** CD-ROM | disk | FTP | other *** search
/ The Datafile PD-CD 3 / PDCD_3.iso / pocketbk / developmen / lpcs / README.TXT < prev   
Text File  |  1994-04-24  |  4KB  |  96 lines
  1. Notes on C programming examples of Link Paste
  2. =============================================
  3.  
  4. Files in this zip (lpaste3.zip)
  5. -------------------------------
  6. readme.txt      This file
  7. lp.h            Header file
  8. lpclnt.c        Source code for example link paste "client"
  9. lpserv.c        Source code for example link paste "server"
  10. lpclnt.img      Built example link paste client
  11. lpserv.img      Built example link paste server
  12.  
  13. Background
  14. ----------
  15. See Chapter 14 in the "Object Oriented Programming Guide" in volume 3
  16. of the C SDK for a general discussion about link paste clients and
  17. servers.  Note: this discussion is in part in terms of object
  18. oriented programming, but you may find the definitions of the various
  19. link paste formats helpful, if nothing else.
  20.  
  21. (The "Object Oriented Programming Guide" can be downloaded, in W4W2
  22. format, eg as the file OODOC201.ZIP in the FLIST of the psion/sibosdk
  23. conference on CiX.)
  24.  
  25. What the files all do
  26. ---------------------
  27. Copy the .IMG files to an \IMG\ directory on an S3 or S3a.
  28. Find their names under the RunImg icon and press Enter on them to
  29. start them running.
  30.  
  31. LpServ.IMG apparently does nothing.  But if you make it foreground,
  32. and then task to another application that supports "Bring" and choose
  33. the "Bring" menu command, the current time and date, as text, will
  34. appear in that application.  LpServ.IMG provides this data to any
  35. application that asks for it.
  36.  
  37. LpClnt.IMG asks you to press 'F' to, in effect, Bring data from
  38. whichever application (if any) currently has any available.  It then
  39. shows the name of this application, together with a selection of the
  40. available "formats" that you can choose.  Make your choice and see a
  41. hex dump of the data actually brought.
  42.  
  43. The two source files are reasonably well commented.
  44.  
  45. Differences from previous releases of these files
  46. -------------------------------------------------
  47. (Skip this section if you never had a previous version)
  48.  
  49. 1. There is an unstated limit, in system code, as to how much data
  50. can be "brought" in any one stage of the transaction.  This limit is
  51. 256 bytes.  The original LpClnt asked for 512 bytes at a time, which
  52. could result in random damage.
  53.  
  54. (Note: this limit only applies when the data is fetched from an
  55. editor, using one of the system defined formats.  If you are doing
  56. some "native" link pasting with your own format, you can choose to
  57. transmit data in larger chunks than this.)
  58.  
  59. 2. In the "middle" stages of a link paste transaction, the link
  60. client has to tell the server, each time, the maximum number of
  61. characters it can handle at that time.  This value has to be passed
  62. as the second word of the "arguments" structure, with the address of
  63. the buffer to receive the character being the first word.
  64.  
  65. In the original LpClnt code, this second parameter was not being set
  66. up correctly, so that a random amount of data was actually being
  67. requested.
  68.  
  69. 3. If the client wishes to terminate the transaction before the data
  70. available from the server is exhausted (as can happen when the user
  71. presses ESC midway through the hex dump in LpClnt), it is the FIRST
  72. word of the argument structure that needs to be set to zero. 
  73. However, the earlier code in LpClnt and LpServ treated the SECOND
  74. word as the relevant one in this regard.  Result: system apps could
  75. be left indefinitely hung up, in some cases.
  76.  
  77. 4. There was some confusion between the TYPE values for the different
  78. formats, as raw integers (1, 2, 4) and the MASK values formed by
  79. shifting 1 left these number of times (ie 2, 4, 0x10).
  80.  
  81. In fact, the MASK values should only be used in communications with
  82. the Window Server - when you specify which types you can supply, if
  83. requested, whereas in the communication between the client and
  84. server, the TYPE value should always be used (since you can only ask
  85. for one type at a time).
  86.  
  87. 5. LpClnt now handles the case of there not being any link paste data
  88. available.
  89.  
  90. 6. All explicit reference to the process control block (E_PROC data
  91. structure) of the link client has been removed, and the explicit call
  92. to p_iosignaln, passing the I/O semaphore for the application, has
  93. been replaced by simply calling p_iosignal the requisite number of
  94. times.
  95.  
  96.