wxDropTarget GetData() can fail for long path names on Windows (Issue #26037)
Dietmar Schwertberger
DietmarSchwertberger created an issue (wxWidgets/wxWidgets#26037)Bug description:
I'm using a wxDataObjectComposite with several data objects, including wxFileDataObject
Dropping files from Windows Explorer to my application basically works.
Dropping a file with a long path >260 characters works when I'm testing with local files.
Dropping a file with a long path >260 characters fails, though, when the file is located on a network file share (I think it's a Netapp filer).
Stack trace:
The failure is inside wxDropTarget OnData at the call of GetData():
...\wxWidgets\src\msw\ole\droptgt.cpp(558): 'IDataObject::GetData()' failed with error 0x8007007a (the data area passed to a system call is too small.).
(Actually I'm using a German Windows and get a message in German.)
Is there a way to call GetData() with a longer data area? I had a look at the sources, but could not see how to do this.
Background info: long paths on Windows
For path names longer than 260 characters Windows has an old DOS-like representation like this:
"C:\...\DIRNAM~1\\FILENA~1.TXT"
This representation may have up to 260 characters again and therefore should not cause problems with GetData().
The short representation can be expanded using win32api FindFiles.
When I'm doing a right mouse click in Explorer "Copy as Path" and paste the result into an editor then I get:
- the shortended DOS-like representation on a local file
- the full path name like "\?\G:\foldername1\subfoldername\subsubfoldername...\verylongfilename.txt" on a remote file; I think that
"\\?\"is a prefix that should indicate long names instead of the DOS-like ones.
(If you don't see "Copy as Path", you need to hold the Shift key when right clicking in Explorer.)
I know that there are registry settings to influence handling of long paths. These might be different on the PCs involved.
Patch or snippet allowing to reproduce the problem:
Running the sample is probably pointless if you do a "Copy as Path" and always get the DOS-like representation when you paste it.
The sample is AI generated, but I have verified that it's working in the way described above.
I did not test a pure wxFileDataObject or pasting via clipboard.
(Building and testing is a bit tedious, as VS and wx are on my private PC while I see the issue on company PCs.)
Platform and version information
- wxWidgets version: current master branch (actually I'm using an older version with wxPython, but I have verified on the master branch)
- wxWidgets port: wxMSW
- OS and its version: Windows 11, several versions
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Dietmar Schwertberger
DietmarSchwertberger left a comment (wxWidgets/wxWidgets#26037)The sample:
dnd.cpp.txt
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#26037)We don't pass any buffer size to GetData(), so it's not just a question of increasing it, unfortunately. And I couldn't find any mention of CF_HDROP being incompatible with using long paths, so I'm not sure what should be done here. Maybe CFSTR_SHELLIDLIST would work, but I'd need to set things up to allow me to test it first...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.