Path: utzoo!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!math.fu-berlin.de!uniol!unido!gmdzi!strobl From: strobl@gmdzi.gmd.de (Wolfgang Strobl) Newsgroups: comp.sys.mac.misc Subject: Re: give me solid facts: why is the mac better than MeSsy DOS/WINDOWS Message-ID: <4249@gmdzi.gmd.de> Date: 9 Mar 91 02:25:17 GMT References: <12337@goofy.Apple.COM> <4194@gmdzi.gmd.de> Organization: GMD, Sankt Augustin, F. R. Germany Lines: 117 francis@zaphod.uchicago.edu writes: >In article <4194@gmdzi.gmd.de> strobl@gmdzi.gmd.de (Wolfgang Strobl) writes: > The Macs clipboard support seems to be written for transporting > something between applications running one after the other, so the >Well, often you have to. See below. > restriction to a few clipboard formats and the necessity to actually >Did you read the explanation I posted? You can put *anything* on the >Mac's Clipboard. The name of the format is four characters; that's >not few, by any stretch of the imagination. I do not doubt that. But there is a tendency to use only a a few at the same time - during one cut/paste action -, because it simply may consume far to much space and time to actually create all these different clipboard formats at the same time. The theoretical upper limit of 2^32 possible clipboard formats doesn't help at all. > create and copy all the supported formats at the same time. While > Windows allows the same style of interation between programs, the > prefered method is to generate a request to render a clipboard format > only if an application actually asks for a copy of the clipboard > content in this format. >Wait a minute. Who does the reformatting? Windows? That would pretty >definitely limit you to one set of formats, wouldn't it? No. The sending application - the one handling the request of the user to cut/copy something - does. The following scenario describes what happenes: Application A (a drawing program, for example), gets the request to copy something to the clipboard. It is able to deliver the data in three different formats, bitmap, picture and text. It has the bitmap anyway, so it it does a SetClipboardData(BITMAP,). The clipboard remembers the format type and stores the data. (Nothing new, so far). Then application A does a SetClipboardData(PICTURE,<>). The clipboard remembers the format type and the fact that there is no data delivered, yet. Application A does the same with text. Some time later, the user switches to application B (a text program, for example). The user just has opened a picture frame and does a paste. The application knows from context that the user wants to paste graphics, so it asks Windows to GetClipboardData(PICTURE). Windows knows that the announced clipboard content in the picture format hasn't been created yet, so it sends a message RENDERFORMAT(PICTURE) to application A. Application A processes the message by creating the data and does a SetClipboardData(PICTURE,), i.e. repeats the "copy to clipboard" operation, this time with a filled container. Application B - and the user - didn't notice this short interlude, and application b now has the requested data and handles it at the users request, for example by filling the frame with the requested picture. It is like buying something by mail. The shop makes a list what it has and sends it to you, you select something and order it, the shop puts it into a packet and sends it to you. Replace the shop by application A and yourself by application B, and you get the picture. :-) > And if the >apps do the reformatting, then you can't do it after quitting (unless >you relaunch the whole bloody app just to switch formats!). This has to be handled, of course. Windows does it by sending a RENDERALLFORMATS to the terminating application, so that it has a chance to deliver everthing it has announced but not yet delivered to the clipboard. The idea to relaunch an application just to get at its data isn't as bad as you seem to think, but it is not necessary in this case. >On a Mac, an app puts out everything it can, all together, for the >simple reason that users *do* sometimes/often/always (depending on >system and user) quit between making their copy and using it. (In >fact, since the Clipboard gets stored on disk, the system may have >been restarted and the app deleted since the copy was made! Try >reformatting then!) This is of course not possible. But as long as the application is running, there is no need to create data only to throw it away. >Granted, it would save some RAM/disk resources to be able to get away >with copying in only one format at a time--but (1) you don't usually >copy all that much at once, and (2) Macs before Sys7 don't have IAC, >which would be necessary if you were to request reformatting like >this, and (3) putting it into all the formats you can do saves the >user time later on. (Suppose the app this came from was on a disk >currently off-line. Assuming that the system remembers where it >is--no great task for a Mac [Macs remember stuff about removed disks >until told to forget--wonderful feature, even if it *is* a legacy of >the 1-drive Skinny]--the user will be asked to swap disks to make a >copy! Ugh. And let's not even THINK about what happens if you take a >year-old item out of the Scrapbook.) >All in all, while I see that Window's way saves some storage space, I >really think Mac's way is easier on the user. (Provided I've >understood Windows right. Perhaps some actual details, please?) See above. I could post actual code, but this probably would bore most readers of this newsgroup, so I try to describe it in English (I'd rather like to do it in German, really!). In this case, the Windows way saves both time and space, and is completely transparent to the user. The advantages of this "lazy evaluation" style are: it it gives the user more freedom, because he can decide how to view the copied data when it is *used*, not when it is copied. It gives the application designer more freedom, because he does not have to trade one clipboard format for another, because all together would be to costly to process. Wolfgang Strobl #include