Clipboard.ContainsImage inconsistent with Clipboard.GetImage

In #493 it was decided that removing metafile support from Clipboard.GetImage is by design. However Clipboard.SetImage and Clipboard.ContainsImage were never adjusted and still support metafiles, this leads to an inconsistent API.

Clipboard.SetImage(new Metafile("example.emf")); // copies the metafile to the clipboard
Clipboard.ContainsImage(); // returns true
Clipboard.GetImage(); // returns null by design, issue #493

• GetImage returning null (instead of throwing an exception) is correct, since all clipboard APIs return null if there is no compatible data available. Since #493 removes compatibility for reading metafiles this is expected behavior.
• ContainsImage returning true if a metafile is present is a bug, it must return false because GetImage will not be able to read the metafile.
• SetImage still supports metafiles so we now have a write-only API which is arguably not a bug, but it may be confusing why you can write metafiles but not read them back. If you want to drop support for metafiles from SetImage as well then it should throw an exception.

Side note: I didn’t test it explicitely but I assume the DataObject APIs behave the same way as the Clipboard APIs and need the same fix.

[merriemcgaw]

I’d like @JeremyKuhne and @lonitra to factor this into their research and planning for resources and clipboard moving forward. BinaryFormatter deprecation and how we decide to handle that might open up some options here.

[weltkante]

Not at all, will create a separate PR for the DataObject changes not directly related to the process crash.