Future Jerry: In some distros yes, in others no. In my example, I fixed that by defining a FileTypeGroup and using it in TextField.Opening.
This also seemed to fix Paul’s issue on Mint–again, at least with my example.
Future Jerry: In some distros yes, in others no. In my example, I fixed that by defining a FileTypeGroup and using it in TextField.Opening.
This also seemed to fix Paul’s issue on Mint–again, at least with my example.
Not in Mint 20.3 Una it’s not, as I posted to the Issue earlier.
Does your example code open the control with AcceptFileDrop? As I’ve said, this was an error of omission that, when corrected, fixed everything for me on a bunch of distros.
Ultimately, what I have found is specific to Cinnamon. Without opening with AcceptFileDrop, DropObject does not fire on Linux. That is probably as it should be. However, on Cinnamon desktops (Gentoo and Mint 22 in my case), one gets the text with the artifact, per Paul’s original post. A breakpoint in DropObject is missed, confirming that the event does not fire and that this is coming not from Xojo, but from elsewhere in Linux/Cinnamon land.
I think a revised ticket should be filed, since the original focused a possible TextField bug and/or the string being returned by Folderitem.NativePath. The issue lies in drag-and-drop behavior with Cinnamon. I might file the ticket myself, but after looking at other platforms. For instance, Mac seems to be indifferent to whether AcceptFileDrop is used (feature or bug?). Also, so far on Linux I don’t seem to be able to filter AcceptFileDrop(i.e, to just “image/jpeg” or something.) Once I allow any filetype, it seems to accept them all.
I’ll edit the ticket at some point or cancel it since it is an OS issue with a workaround and not a Xojo problem.
I appreciate your help in figuring it out!