Question. The problem thats trying to be solved is apps being able to paste after the application exits, right? Has anyone entertained the idea of not letting the application fully exit until the clipboard changes? On Sun, 2003-09-07 at 05:35, Mike Hearn wrote: > So, the thread about clipboards and the patch Hongli posted piqued my > interest in how Windows did things. A bit of research on MSDN and some > experiments with Office 97 reveal the following (some of which is new to > me): > > * Windows has two clipboards, the legacy clipboard which operates as you > might expect given the discussions here and is stored, well, who knows > where, and an OLE/DCOM based clipboard. The two interoperate to some > extent. > > * Often, both are used at once. For instance, if you select some cells in > Excel 97 and copy them, you have a choice of formats to paste them into > Word with, including Formatted Text (RTF), and an embedded Excel document. > The RTF comes from the standard clipboard, and obviously embedded Excel is > done via OLE. > > * Many formats are only available via the OLE clipboard while the > originating application is running. These formats are lost when the app > closes. For instance while Excel is running, you can paste as a bitmap. If > you close it, you can only paste as text. > > * Data transfers via OLE are seemingly done by marshalling an an interface > specified by OLE onto the clipboard as another format type, which is then > demarshalled into the context of the application being pasted into. DCOM > deals with the RPC. These formats disappear (removed either explicitly by > the app, or by the framework, I don't know which) when the source app > closes. The interface used here supports other forms of content > negotiation, as well as the ability to receive updates when it changes. > > BTW, the old style clipboard, where the copied data is buffered by the OS, > seems to beofficial deprecated: > > Follow these guidelines in using the Clipboard: > * Use the OLE Clipboard mechanism now to enable new capabilities in the > future. While the standard Clipboard API will be maintained, the OLE > mechanism is the future of data transfer. > * Use the OLE Clipboard mechanism if you are writing an OLE application or > you want any of the OLE features, such as drag and drop. > * Use the OLE Clipboard mechanism if you are providing OLE formats. > > So basically what MSDN is saying is, "Use the OLE clipboard". Which leads > to some interesting conclusions, like the fact that we appear to be > heading in a direction that Microsoft is explicitly leaving. > > The other interesting thing is that the "new" style clipboard is based on > X style IPC-on-paste, not explicit data transfers. I wrote something about > that on xdg-list a while ago, where it was (rightly) shot down as being > too blue sky. Fixing the current system seems more important. But, it's > worth bearing in mind for the future what the competition is up to. > > I have no info on the MacOS clipboard, sorry. > > thanks -mike > > _______________________________________________ > desktop-devel-list mailing list > desktop-devel-list gnome org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Bob Smith <bob thestuff net>
Attachment:
signature.asc
Description: This is a digitally signed message part