[comp.sys.acorn] inter application data transfers

jwil1@cs.aukuni.ac.nz (JasonCarlyle Williams ) (04/15/91)

>>OK, guys... You have recently been discussion 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)

>Complete rot!  It would need very little change indeed.  In fact I have
>implemented most of what needs doing by use of the txtedit library in
>C release 3.  It is very simple.

Sorry... I meant 're-compiled'. In other words, you can't just take the bog-
standard !Edit (or !Draw or !Paint) off Apps disc one and get it to work
in this manner. You would have to write some extra code into them, and
recompile them. This is not likely, as they are Acorn's programs, so we
would have to write replacement applications for them.

>>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 think this will need much more work.  The existing filing systems know
>nothing of the WIMP ( as this would require) - and why should they?

Not really, this is a 'special' filing system, built with this in mind.

>>This has several dinky features:
>>
>>Wimp$Scrap could automatically be channeled 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.

>Sounds like you want a pipe.  I guess that would be handy.

Yes. Yes Yes! Please! I want pipes!


>>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")

>The last one needs contact with the WIMP.  Further more the second one
>will create a NEW COPY of edit.  A message would use the existing copy.

Contact with the WIMP is nothing to be afraid of. It doesn't bite. It would
be easy for a FS to send a 'dataload' or similar message, in much the same
way as all FSes already do, just for an internal reason rather than because
the user has clicked/dragged something.

OK,if we're going to be sending DataLoads anyway, modify the statement '*RUN'
to sending a DataLoad (or if you don't know where to send it, do a *RUN the
first time, which gets edit going, and DataLoad subsequent copies- Edit is
clever, when you load a file with the same pathname, it replaces the copy
in the window with the new data from the file. A very dinky feature.

>>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 usage again.

>This is either cumbersome (you have to go menu, dialogue, OK) or need as
>much rewrite as before.

Not really, you can either bash f3 followed by return, or click Menu and
click 'Save'. You don't need to go to the save as dialogue, you don't need
to drag anything anywhere, etc. etc.

>>This could work,

>Any reason for the conditional there ?

Yes. I have experience with other people using supposedly 'standard' ways
of doing things. Everyone tends to do something slightly differntly, so
things can fall over when people don't follow the rules correctly.

>>                 and it would also work with any application regardless
>>of whether it actually had been written with this system in mind.

>A fair point...

I think so. My system is not really incredibly NICE, but the main point
of it is that it will work with all applications. You don't need to re-write
Edit, Paint, Draw, Impression, ARMadeus, Schema, ..... to actually get the
system going.

>>(That should give you something to think about/winge about/ignore, anyway)
>>The Master of the Arcane

>Use messages, that is what they are there for!

Yes, but they won't work for the *general* case very nicely. It's all very
well saying that you want to please edit this file and can I have it back
but that's really a specail case for editing text. What about DrawFiles and
Sprites and ...? Yes, you can do a simple 'please edit this and return it'
message, but then everyone will say 'but wouldn't it be nice if we could
invoke the editor, and tell it to go to line number x, and select word
number y...'

I was just offering an idea (I never said it was a NICE idea!)

The Master of the Arcane.
-- 
New administrater uofa.