Bug 250246 - ImageTransfer.isSupportedType() gives different result than fetching content from clipboard
Summary: ImageTransfer.isSupportedType() gives different result than fetching content ...
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.4   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Duong Nguyen CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-09 05:12 EDT by Marco mvmsoft CLA
Modified: 2019-09-06 16:15 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marco mvmsoft CLA 2008-10-09 05:12:54 EDT
Build ID: Version: 3.4.0 Build id: I20080617-2000

Steps To Reproduce:
1. write app using the code pasted below
2. open ms ppt 2003 on windows, create an autoform box, select and copy it
3. check if isExternalClipboardContentSuitable() returns true --> wrong behavior: returns false
4. get the clipboard content using getImageFromClipboard() --> returns the image data


More information:
I want to implement copy/paste of images from MS-PPT to eclipse rcp app. The paste action is enabled using method isExternalClipboardContentSuitable() below; the content is fetched using getImageFromClipboard() below.

The test says no suitable ImageTransfer stuff available on clipboard; but fetching it succeeds.

   public static boolean isExternalClipboardContentSuitable() {
        // TODO: fix
        // check if clipboard contains image
        Clipboard clipboard = new Clipboard(Display.getCurrent());
        boolean enabled = false;
        try {
            TransferData[] available = clipboard.getAvailableTypes();
            for (TransferData transfer : available) {
                if (ImageTransfer.getInstance().isSupportedType(transfer)) {
                    enabled = true;
                    break;
                }
            }
        } finally {
            clipboard.dispose();
        }
        return enabled;
    }

    public static ImageData getImageFromClipboard() {
        Clipboard clipboard = new Clipboard(Display.getCurrent());
        ImageData imageData = null;
        try {
            imageData = (ImageData) clipboard.getContents(ImageTransfer.getInstance());
        } finally {
            clipboard.dispose();
        }

        return imageData;
    }
Comment 1 Steve Northover CLA 2008-10-10 11:49:13 EDT
Duong to investigate.
Comment 2 Duong Nguyen CLA 2008-10-10 18:01:33 EDT
The problem is that our ImageTransfer only supports "CF_DIB" and isSupportedType only checks whether this type id is one of the available type in the clipboard. In this particular case "CF_DIB" type is not available.

However, the clipboard has an "autoConvert" feature that will attempt to convert the data to the requested type when it can. In this particular case, it's able to convert one of the available type (most likely CF_BITMAP) to CF_DIB. As the result, you can get the image even though the ImageTransfer type reported that the type is not available.

We need to provide a new API for clipboard to query whether the data type is available. 
   on win32, the native call is QueryGetData
   on wpf, the native call is Clipboard_ContainsData

I have not checked GTK and MAC. However, if the equivalent native call is not supported on these platforms, we can revert back to just checking for type id for a match as we do now.

NOTE: This will require new API for Clipboard.
Comment 3 Eclipse Webmaster CLA 2019-09-06 16:15:35 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.