Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!waikato.ac.nz!comp.vuw.ac.nz!jwright From: Julian.Wright@comp.vuw.ac.nz (John Julian Wright) Newsgroups: comp.sys.acorn Subject: Re: invoking editors/draw/etc from other app.s Keywords: editors, RAMtransfer, RAMdisc Message-ID: <1991Apr10.031136.9494@comp.vuw.ac.nz> Date: 10 Apr 91 03:11:36 GMT References: Sender: news@comp.vuw.ac.nz (News Admin) Reply-To: jwright@comp.vuw.ac.nz (John Julian Wright) Organization: Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand. Lines: 52 Nntp-Posting-Host: lyall.comp.vuw.ac.nz Originator: jwright@lyall.comp.vuw.ac.nz In article , jwil1@cs.aukuni.ac.nz (JasonCarlyle Williams ) writes: |> 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) Certainly it would need a couple of things added to it, but it wouldn't need to be completely re-written. The Save option on the menu changed to a simple 'non-iconic' option, for example, and the adding of a couple of messages... |> 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. I LIKE this idea. At present only files which are *SAVEd (or equiv.) can be RAMTransferred. Not files which are saved by opening, bputting, and closing. |> Wimp$Scrap could automatically be channelled through this dynamic RAMdisc |> (though not a RAMdisc that pleb users can 'see' on the desktop) if enough Sounds like you are asking for a 'pipe' facility. This would be quite handy too. |> RAM exists for the transfer. Then, Wimp$Scraps will be equivalent to RAM |> transfers when the RAM is available. Not to mention there would be no point trying to support "real" RAM transfers, as the wimp$scrap method was just as good. |> 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. Yes but it's not quite as flexible as a specific message pair for editors. While we are talking about RAMdiscs, how about the ability to create more than one at a time, and the ability to resize them on the fly? The current RAMdisc can be named, but there's not much point... Cheers, Julian. -- ;`````````````````````````````````````````````````````````````````````````````; ; I would if I could but I can't so I won't but I might if I find I can later ; ;,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,; jwright@comp.vuw.ac.nz julian@sideways.gen.ac.nz