http://bugs.winehq.org/show_bug.cgi?id=28557
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |damjan.jov@gmail.com Ever confirmed|0 |1
--- Comment #3 from Damjan Jovanovic damjan.jov@gmail.com --- Confirming. With WINEDEBUG='+xdnd' we see how Notepad++ only looks for CF_UNICODETEXT and CF_TEXT, which is why dragging text into it works, but dragging a file doesn't. Neither Thunar, Caja nor Konqueror work for me.
But why?
The source seems to show it using CF_HDROP in only one place, but it does use WM_DROPFILES. A +shell trace shows it calling: trace:shell:DragQueryPoint which is called from PowerEditor/src/Notepad_plus.cpp: --snip-- void Notepad_plus::dropFiles(HDROP hdrop) { if (hdrop) { // Determinate in which view the file(s) is (are) dropped POINT p; ::DragQueryPoint(hdrop, &p); HWND hWin = ::RealChildWindowFromPoint(_pPublicInterface->getHSelf(), p); if (!hWin) return;
if ((_mainEditView.getHSelf() == hWin) || (_mainDocTab.getHSelf() == hWin)) switchEditViewTo(MAIN_VIEW); else if ((_subEditView.getHSelf() == hWin) || (_subDocTab.getHSelf() == hWin)) switchEditViewTo(SUB_VIEW); else { ::SendMessage(hWin, WM_DROPFILES, (WPARAM)hdrop, 0); return; }
int filesDropped = ::DragQueryFile(hdrop, 0xffffffff, NULL, 0); --snip--
Since we see DragQueryPoint() getting called, but not DragQueryFile(), maybe the point is wrong and the function returns early?
Indeed: since Notepad++ ignores the return value of DragQueryPoint(), and passes the returned point directly to RealChildWindowFromPoint(), the point must be in client coordinates. Patching Wine to send WM_DROPFILES with DROPFILES.pt in client coordinates and fNC set to false fixes this bug, see the patch at http://source.winehq.org/patches/data/105219 which I've already submitted.