Currently our clipboard implementation on Windows employs
standard Clipboard API. In order to address issues like
4475722, 4696186, 4451371, 4808793 and one mentioned in
the comments section, it should be rewritten using
the OLE data transfer mechanism.

###@###.### 2004-07-27
###@###.### 2004-07-27
On Windows, when a Java app places data into the system
clipboard, then the app is queried for data in each available
data flavor. This may be expensive (e.g., lead to freezing of
the app for some time) if data are available in multiple flavors
(e.g., plain text, html text, image). However, data from the
clipboard are requested in only 1-2 flavors typically.
Our current implementation of the Windows clipboard is based on
Win32 functions SetClipboardData(), GetClipboardData() in essence.
I propose to change this inefficient behavior so that
data in a chosen flavor are queried only on demand of an app
that performs paste; in short, we'll use the functions
OLESetClipboard(IDataObject*), OLEGetClipboard(IDataObject**)
and the COM interface IDataObject.

Motivation

(a) Performance improvement, as explained above.

(b) Microsoft Vista applications will mostly use the way of accessing
the clipboard using IDataObject COM interface since it's the only
way WinFX SDK provides. (Evidences will be given below.)

(c) Data in some clipboard formats (at least Shell clipboard formats)
can only be transferred via IDataObject and thus we'll clear the way
for further improvements of our clipboard data transfer.

(d) There is the RFE 4808793 (Allow initiation of drags without local data)
that requests us to allow initiation of drags and copying of files that
aren't available locally, which becomes more popular on SDN.
To implement this RFE on Windows, we need to support some
Shell clipboard formats, therefore, according to (c),
we need to have the feature 'OLE clipboard' implemented.

(e) Improve commonality across platforms: Windows clipboard
behavior will be similar to the clipboard behavior on X platforms:
data set into the clipboard will be queried only on demand.

(f) Several bugs (partially) caused by prefetching data in
all flavors will disappear.

-----------------------------------------------------------


Below are my findings, which acknowledge the fact that Microsoft Vista
applications will mostly use the way of accessing the clipboard using
IDataObject COM interface, compatible with the proposed way.

1.
http://msdn.microsoft.com/windowsvista/about

Developer Platform Evolution

An evolution for both Win32? and WinFX? begins with Windows Vista-era
advances to the .NET Framework. These two programming models will
enable every developer to target the advances in Windows Vista,
including improved presentation and communication subsystems, improved
connectivity, and substantial advances in the core security,
manageability, and reliability of Windows.

It's important to note that Windows Vista is heavily emphasizing both
application compatibility (existing applications should always just
run) and developer compatibility (all features are accessible through
both WinFX and Win32). All existing source code and programming skills
apply for Windows Vista developers, whether they're C++/MFC developers
or Visual Basic .NET/Windows Forms developers.

2.
http://www.microsoft.com/com/default.mspx

Is COM still supported? Is it going away?

COM is a feature of Windows. Each version of Windows has a support
policy described in the Windows Product Lifecycle. COM continues to be
supported as part of Windows. COM is a feature of the next version of
Windows, Windows Vista.

3.
http://winfx.msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/T_System_Windows_Forms_Clipboard.asp
http://winfx.msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/T_System_Runtime_InteropServices_ComTypes_IDataObject.asp

WinFX SDK provides only one way for setting/getting data to/from
the clipboard: via the Clipboard class, which uses IDataObject
COM interface. So new Vista applications will mostly use this
way of accessing the clipboard.