During a call to GetClipboardData(), the app may be asked to render the data
for a promised format. This will cause us to receive WM_CLIPBOARDUPDATE.
Almost always, the app will have just rendered the requested format and not
made any other changes. Therefore, we don't need to rebuild the Mac pasteboard
from the Win32 clipboard. Doing so can cause a race with the other Mac app
which is querying the pasteboard (for a paste operation, for example). We
basically delete the data we _just_ added and rebuild the list of available
types. The symptom is that the other Mac app sees the available types change
and maybe be incomplete.
In theory, the Windows app could make other changes to the clipboard and this
change would cause us to fail to convey them to the Mac pasteboard. I consider
that very unlikely and the tradeoff to improve the common case is worth it.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Continue exporting in the original format under org.winehq.registered.HTML Format
for fidelity when copying and pasting within Wine.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Renamed it to macdrv_get_pasteboard_formats(), since the "copy" was meant to
convey Core Foundation ownership semantics which no longer apply.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
… as is done in user32's and gdi32's version of the same function.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The relevant Mac-native types, public.utf16-plain-text and public.utf8-plain-text,
are handled by CF_UNICODETEXT and user32 handles the synthesis of CF_TEXT and
CF_OEMTEXT from that.
CF_TEXT and CF_OEMTEXT are still exported and imported with a Wine-specific
type to preserve cross-prefix copy/paste fidelity.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The relevant Mac-native type, com.microsoft.bmp, is handled by CF_DIB and
user32 handles the synthesis of CF_BITMAP and CF_DIBV5 from that.
CF_BITMAP and CF_DIBV5 are still exported and imported with a Wine-specific
type to preserve cross-prefix copy/paste fidelity.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
At least one Mac app, TextWrangler, puts UTF-16 data on the pasteboard with
lines separated by CR (although it uses LF for the UTF-8 form of the same text).
Other Mac apps handle it properly; we should, too.
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Charles Davis <cdavis5x@gmail.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Charles Davis <cdavis5x@gmail.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
New clipboard formats had been registered for them, but that was pointless.
No Windows app would ever expect or make use of such clipboard formats or the
associated pasteboard data.
Piotr Caban