JDK-6362095 : Drag and Drop of images to WordPad doesn't work
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-12-12
  • Updated: 2011-03-07
  • Resolved: 2011-03-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b07Fixed
Related Reports
Relates :  
JDK-6507558 - Regression:ImageTransferTest test failed for METAFILEPICT format (WIN32 only)
Description
FULL PRODUCT VERSION :
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
I can't get drag and drop of images to work correctly on windows. I see also that the drag and drop demo on the tutorial page doesn't work either.

http://java.sun.com/docs/books/tutorial/uiswing/misc/dnd.html
(grep for "Run DragPictureDemo")

My test case is trying to drag and drop an image into WordPad. What happens is, I get an image, of the correct size, but filled with a single color.

  From http://access1.sun.com/tutorials/Swing_Tutorial/Dnd-Merlin-Tutorial/3.html and the drag and drop tutorial, I am lead to believe dragging from a java app to a native app should work.

I have posted a message about it a year ago. Unfortunately it simply generated comment asking me how I managed to get drag and drop working in the other direction: from an app to java.
http://forum.java.sun.com/thread.jspa?threadID=567809&messageID=3979708



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
An easy way of reproducing this is to go to

http://java.sun.com/docs/books/tutorial/uiswing/misc/dnd.html
and run the "DragPictureDemo". This is a link called "Run DragPictureDemo" which uses java web start.

Drag images from the window of cute children to word pad. Notice how you get little colored squares insteasd of pictures of cute children. It should be the picture I just dragged.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Drag images from the window of cute children to word pad. Notice how you get little colored squares insteasd of pictures of cute children. It should be the picture I just dragged.When images are dragged and dropped ot word pad i should get the image, not  a big colored square. This is what happens on MacOS X (dragging onto to text edit).
ACTUAL -
Drag images from the window of cute children to word pad. Notice how you get little, picture sized colored squares instead of pictures of cute children.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
No error messages noticed.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Code is on the web at;

http://java.sun.com/docs/books/tutorial/uiswing/misc/example-1dot4/index.html#DragPictureDemo
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
ummm.. use a mac? Not a good solution.
The bug could be reproduced by using copy/paste operations and standard Clipboard viewer clipbrd.exe
The "Picture" clipboard format is defective.
Comments
EVALUATION Umbrella fix from regression daughter CR 6507558
26-12-2006
EVALUATION New regression bug 6507558 was created for last problem.
22-12-2006
EVALUATION Detailed investigation shown that I made the mistake in metafile size calculation for clipboard. That was detected by %root%\test\java\awt\Clipboard\ImageTransferTest. The bug was localized and fixed. In ImageTransferTest detects the difference in Source and Destination raster-images. It has a visual effect: 2 black points in copied image at right-top corner.
18-12-2006
SUGGESTED FIX The approved webrev revision was copied to NFS: /net/jano.sfbay/export/disk29/jcg/1.7.0-dolphin/awt/6362095 URL: http://javaweb.sfbay/jcg/1.7.0-dolphin/awt/6362095/
06-12-2006
EVALUATION The TRY/CATCH_BAD_ALLOC_RET(NULL) pair was not removed from code because macros contain Java exception report generator. In practice it is a good idea to extend code diagnostic by function JNU_ThrowHRESULT to inform Java developer in more details. JNIEXPORT void JNICALL JNU_ThrowHRESULT(JNIEnv *env, HRESULT hr) { LPSTR pszMsg = NULL; FormatMessageA(FORMAT_MESSAGE_ALLOCATE_BUFFER|FORMAT_MESSAGE_FROM_SYSTEM, NULL, hr, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), (LPSTR)&pszMsg, 0, NULL); if ( NULL != pszMsg ) { int nLen = strlen(pszMsg); if (nLen > 1 && pszMsg[nLen - 1] == '\n') { pszMsg[nLen - 1] = 0; if (pszMsg[nLen - 2] == '\r') { pszMsg[nLen - 2] = 0; } } } else { pszMsg = (LPSTR)LocalAlloc(0, 32 * sizeof(CHAR)); if ( NULL != pszMsg ) { enum { WCODE_HRESULT_FIRST = MAKE_HRESULT(SEVERITY_ERROR, FACILITY_ITF, 0x200), WCODE_HRESULT_LAST = MAKE_HRESULT(SEVERITY_ERROR, FACILITY_ITF+1, 0) - 1 }; WORD wCode = (hr >= WCODE_HRESULT_FIRST && hr <= WCODE_HRESULT_LAST) ? WORD(hr - WCODE_HRESULT_FIRST) : 0; if (wCode != 0) { sprintf(pszMsg, "IDispatch error #%d", wCode); } else { sprintf(pszMsg, "Unknown error 0x%08X", hr); } } } JNU_ThrowByName(env, "java/lang/InternalError", pszMsg); if ( NULL != pszMsg ) { LocalFree(pszMsg); } }
04-12-2006
EVALUATION Implemented refactoriong is an example of "waterfall" pattern where each block of code is responsible for deallocation of previous successful call result. This code is easy for logging and debugging - one entry and one exit points. Additianaly, mentioned pattern conserves error code as long as it possible till the "user" level application could solve how to notify about happened problem.
04-12-2006
EVALUATION Fix description: RECT r = { min(0, p.x), min(0, p.y), max(0, p.x), max(0, p.y) }; HDC hemfdc = ::CreateEnhMetaFile(NULL, NULL, &r, NULL); In accordance with CreateEnhMetaFile documentation the rectangle have to be normal (left <= right, top <= bottom) VERIFY(::SetMapMode(hemfdc, MM_HIMETRIC)); if( GDI_ERROR == ::StretchDIBits(hemfdc, 0, iMFHeight, iMFWidth, -iMFHeight, 0, 0, width, height, (LPVOID)array, pinfo, DIB_RGB_COLORS, SRCCOPY)) We are trying to support context-independent metafile. To implement it we have to select correct MM_HIMETRIC map mode. It was not done in old code for both CF_ENHMETAFILE and CF_METAFILEPICT formats. The change in map mode leads to recalculation of destination rectangle in fixed StretchDIBits call. Due to inversed row order in source bitmap the destination height have to be negative. The destination Y coordinate (3d parmeter in StretchDIBits call) is different for CF_ENHMETAFILE and CF_METAFILEPICT formats due to applying MM_ANISOTROPIC map mode at very last moment. MM_ANISOTROPIC map mode changes the Y-axis direction and can be selected just for metafile header.
15-11-2006
EVALUATION It seems that METAFILE format in DataTransferer never worked correctly. At least current implementation produces clipboard data that could not be viewed by standard Clipboard viewer clipbrd.exe and could not be drawn by OLE container in WordPad. The problem with drop in WordPad coursed by requested preferred format CF_METAFILEPICT, but the most of other text processors (MS Word and StarOffice) prefer CF_DIB those has not got a problem. The suggested fix changes StretchDIBits call parameters and set MM_HIMETRIC map mode for metafile draw context (DC). Mentioned fix was tested with copy/paste and DnD operations. In addition I suppose to refactor the code of function Java_sun_awt_windows_WDataTransferer_imageDataToPlatformImageBytes to avoid memory leaks on the level of code design.
14-11-2006