U3364521@ucsvc.ucs.unimelb.edu.au (Lou Cavallo) (11/24/90)
G'day, darren@cbmvax.commodore.com (Darren Greenwald) writes: [...Excerpted from the "does anything use the clipboard" message stream...] > As you noted, its not allowed - the clipboard.device is IFF smart, and > uses the info passed in to determine how much memory its going to need; > a pure ASCII format is currently not possible. Maybe what we need is > tools to make reading/writing of IFF easier (we do have iffparse now). > We may also want to consider a new type of IFF file - call it DATA or > something which means the next X number of characters is just data of > no particular type. IFF TEXT has some limits on what you can put in it, > which means its not really suitable for text editors which allow you > to edit binary sequences (and many Amiga text editors do). > > Darren M. Greenwald | Commodore-Amiga Software Engineering > | USENET: uunet!cbmvax!darren To Darren or anyone else "in the know" ... {I don't know the IFF internals so I'm asking for some help here understanding something Darren said}. Darren says, "We may also want to consider a new type of IFF file ...". If a new file format is needed that does not exist (even if only a little different from an existing one) does a new IFF format have to be invented? Or can you build up such a new file format from reusable existing IFF file format definitions? {If worthwhile I mean.} I would hope that it could be done using reusable file format definitions, as I think that this would make best use of earlier parsing code. As _I_ understand what I've read people say about IFF (file format details only are considered) I'm not able to see how reusability could be featured within IFF specifications? Can a new file format "inherit" (my fuzzy intent is that of OOP style) any features from an existing form? It should be obvious that I don't know anything (essentially) about IFF so please don't flame me too much if I'm "way of base here". yours truly, Lou Cavallo.