Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!waikato.ac.nz!aukuni.ac.nz!jwil1 From: jwil1@cs.aukuni.ac.nz (JasonCarlyle Williams ) Newsgroups: comp.sys.acorn Subject: invoking editors/draw/etc from other app.s Summary: RTFMessage Keywords: editors, RAMtransfer Message-ID: Date: 9 Apr 91 23:42:22 GMT Sender: news@ccu1.aukuni.ac.nz (News Owner) Organization: University of Auckland, New Zealand. Lines: 36 Nntp-Posting-Host: aucs7.cs.aukuni.ac.nz OK, guys... You have recently been discussiong the idea of invoking editors (Edit, Draw, etc.) from within another App. along the lines that the editor will pass you back the file when finished with it... It's actually nigh on impossible to do this with current app.s (i.e. Edit would probably have to be re-written to handle this special case) How about a sort of RAM filing system for this? When you want to do a transfer, you "save" your file to the RAMFS, which automatically (dynamically) 'creates' a disc just for that one file. This has several dinky features: Wimp$Scrap could automatically be channelled through this dynamic RAMdisc (though not a RAMdisc that pleb users can 'see' on the desktop) if enough RAM exists for the transfer. Then, Wimp$Scraps will be equivalent to RAM transfers when the RAM is available. Extra twiddly bits could be given to the FS when you save a file to it: e.g. *SAVE file to RAMFS *Run file (to invoke !Edit on it) (And set 'twiddly bit' "return the file to me") Then when user clicks 'save' in Edit, it saves back to this RAMFS and the RAMFS sends you a DataLoad request or similar to get you to re-load the file for your own useage again. This could work, and it would also work with any application regardless of whether it actually had been written with this system in mind. (That should give you something to think about/winge about/ignore, anyway) The Master of the Arcane (P.S. Howcum this stupid nn puts this silly message at the end of my posts...?) -- New administrater uofa.