home *** CD-ROM | disk | FTP | other *** search
/ The Datafile PD-CD 5 / DATAFILE_PDCD5.iso / utilities / t / tornado / Guide / 7 < prev    next >
Encoding:
Text File  |  1995-09-23  |  6.0 KB  |  108 lines
  1. I/O, OLE and hotlinking
  2. -=-=-=-=-=-=-=-=-=-=-=-
  3.  
  4. Tornado does all disc i/o while multitasking, including when an
  5. executable is being loaded in from a !Run file. Tornado does this by
  6. providing *-commands to load in code while multitasking. A background
  7. operation hourglass appears during this. Also, any i/o operations are done by
  8. Tornado, including serial, parallel, disc and inter-application i/o.
  9. Sometimes the i/o is done without the application's knowledge or involvement.
  10.    For a start, all low-level serial and parallel i/o is done using SWI
  11. Tornado_IOOp. Block gbpb taking more than 1cs to perform gets broken into
  12. blocks and transferred while multitasking, although the calling task can have
  13. the SWI return control instead so full application functionality is retained
  14. (Basic programmers would need this the most - C and assembler images can be
  15. multithreaded in this case). I/o is done using the serial block drivers for
  16. the serial port, and with a specialised replaceable driver for the parallel
  17. port.
  18.    For more generalised use, i/o can be directed at tserial:, tparallel:,
  19. tprinter: and anything else that is added by third-party producers (eg;
  20. tethernet:). For the printer, tprinter: in fact is a FIFO buffer which takes
  21. in input and spits out output to the printer as fast as it can. I/o to
  22. tprinter: is also done while multitasking, unless the app wishes to retain
  23. full functionality. I/o to tserial: actually directs i/o to whatever is the
  24. currently selected serial driver(s) (can be different for different apps).
  25. Also, multiple apps can access the serial port at once, using a system like
  26. the input focus. The access requirements for eg; tethernet: have yet to be
  27. finalised.
  28.  
  29. That's general i/o. For more usual i/o like disc i/o, there's a different
  30. setup. For a start, applications do not know that a user has requested that a
  31. file be loaded into that application. Nor does an application know if the
  32. user saves the file out of it. Or if the user has OLEd a file currently
  33. loaded in. Or, for that matter, if the application has _any_ files loaded in
  34. at all. [1]
  35.    How is this possible? Well, tornado applications are written to edit one
  36. file and one file only. *Tornado* handles the loading in of _multiple_ files.
  37. Also, tornado applications do not /load/ in files, they rather replace an
  38. existing (possibly empty) one. For example, loading in a tornado app and then
  39. loading a file into that actually replaces the blank file which is
  40. considered to be already loaded in with the one being loaded in. [2]
  41.    This means that the user OLEing a drawfile in a DTP frame simply does the
  42. following:
  43.    * User does OLE special-key & click.
  44.    * Tornado receives this, and checks the filetype of the file loaded into
  45. the frame in the DTP (i)
  46.    * Tornado checks the apps currently loaded in, and sees if any of them can
  47. load the file (ii), and if none are loaded in it checks to see if any
  48. suitable apps have been seen by the filer (iii)
  49.    * Tornado tells the receiving app to *replace* the currently loaded blank
  50. file with this file here, and passes it the address of the file loaded into
  51. the DTP package. It also tells the new-found editor where to open its editor
  52. window if appropriate eg; directly over the frame containing the original,
  53. scaled to the correct zoom factors etc. (iv)
  54.    * From now on, any modifications made to the shared file is accompanied
  55. with a message sent to all tasks with access to that file requesting that
  56. they redraw that file (v)
  57.  
  58.  (i) Tornado knows the filetype of every file loaded in because *it* does the
  59. loading in.
  60.  (ii) Tornado knows which filetypes each app loaded in can edit (without
  61. conversion) because the app declares them in its Tornado script file.
  62.  (iii) Tornado knows which filetypes each app on disc can edit because they
  63. are declared in the !Boot file of every app on disc. Tornado can build a
  64. 'map' of the disc by checking the disc for tornado apps, extracting what
  65. files they can load and compiling them into a list. When the Tornado filer is
  66. written, any changes made to the directory structure (ie; the user moves a
  67. file from here to there) will also update the list. Otherwise, or to save
  68. memory, Tornado can simply register any apps seen by the filer.
  69.  (iv) All files loaded into all tornado apps are stored in a central
  70. reservoir maintained by Tornado, and this lives in RMA. See the appropriate
  71. file about this.
  72.  (v) All files are redrawn by the Tornado renderers, which are available to
  73. all tornado apps. See the approriate file about this.
  74.  
  75. From the above, you can see how the user dragging a file from the filer to a
  76. tornado app would work, and dragging a file from another app to an app, and
  77. hotlinking a whole bunch of files together. It's even possible that a single
  78. file could be shared over a network eg; an alteration to a file on one
  79. station would affect all copies all over the network (and beyond). This would
  80. allow teachers to monitor what any student is doing.
  81.  
  82. Note also, that all files loaded in and saved out go through tfs: (if
  83. present). The file is loaded while multitasking into tfs:, and loaded into
  84. the app from there. A file is saved to tfs:, from where it is copied to disc
  85. under multitasking. This ensures constant multitasking.
  86.  
  87. See also the file about subtasks, as subtasks play a more than notable part
  88. in implementing i/o.
  89.  
  90.  
  91.  
  92.  
  93.  
  94. [1] Note that in fact, no tornado application can have a file loaded into it.
  95. The file in fact is loaded into tornado, and tornado passes the editing of
  96. the file to the app the user assigned to it by dragging the file onto the
  97. icon of that app. Ie; the app doesn't maintain its own list of files. Nor can
  98. it distinguish between files passed to it by tornado. When a user alters a
  99. file, tornado informs the app owning the editor window and passes it the
  100. address of the file. The editor modifies the file, and tornado shows any
  101. changes onscreen.
  102.  
  103. [2] In other words, multiple files 'loaded' into an app are really a list of
  104. files _associated_ with that app. When one is altered, the app is called to
  105. do it. As far as the app is concerned, it can edit one file and one file only
  106. - whatever the file tornado passes to it.
  107.  
  108.