dim c as new Clipboard
dim s as string = c.Text
dim sUTI as string = c.RawData("public.utf8-plain-text")
dim sNSP as string = c.RawData("NSStringPboardType") ' this doesn't work at all
c.close
I go to Finder, select 2 files and copy.
Clipboard Viewer https://langui.net/clipboard-viewer/ correctly reports the data under the ‘public.utf8-plain-text’ flavor:
00000000: 74 65 73 74 32 2e 74 78 74 0d test2.txt.
00000010: 74 65 73 74 31 2e 74 78 74 test1.txt
I go to Finder, select the same 2 files and option-copy to copy the pathnames. Clipboard Viewer again reports what’s expected (as does pasting into eg BBedit):
(sUTI is also wrong, and sNSP is blank, probably because the “NSStringPboardType” identifier cannot be interpreted, even tho Clipboard Viewer says this flavor is also there).
Looking closely, the 1st Finder copy uses CR (0D) as the delimiter, whereas the path copy uses LF (0A) (why i have no idea).
Conclusion: xojo’s clipboard gets stumped by plain text LFs.
No. That text with 0a as LF work correctly in Xojo.
Only happens when you copy Finder files as Pathnames (using Option+Copy). The only reference I have is that ‘Clipboard Viewer’ shows 0a in both cases, so I’m not sure why it fails with Finder files as Pathnames.
I don’t think there’s a framework bug here or you would have seen an issue with the tests I asked you to rerun.
Passing different pasteboard types will yield different data back. When interacting with data that’s not yours (like Finder), you sometimes need to investigate how to correctly read it.
If I were at me desk, I could look. The best I can do from bed is pointers.
both Items with Pathnames show on BBEdit (2 lines)
selected the 2 lines on BBEdit to copy
Xojo Clipboard code now shows both
same behavior with 4 finder items, only 1 shown directly from Xojo Clipboard code, all 4 show with BBEdit, select/copy from BBEdit then all 4 show in Xojo.
This is probably not what you wanted to hear, but MBS has a solution.
Var p As NSPasteboardMBS = NSPasteboardMBS.generalPasteboard
System.DebugLog(String.FromArray(p.types, EndOfLine))
Var s As String = p.stringForType(p.NSPasteboardTypeString)
System.DebugLog(s)
Thx Scott, it’s exactly what I wanted to hear because that’s the solution i came to last nite, but was too tired to post, so you beat me to it. MBS saves the day again.
For me, this just means BBEdit puts what you expect in the clipboard, which the Finder didn’t (in other words, the Finder copies data in a way you have yet to understand and pasting and copying using BBEdit turns that to “standard text”).
But what’s incomprehensible is that the public.utf8-plain-text bytestreams are identical in both cases, both 0A-delimited.
No idea how this could even be possible.
I don’t know if you have access to @Sam_Rowlands’ AppKit, but in his macOS Declares & External Methods the pasteboard contents are extracted as an NSArray of items (each with potentially one or more flavours).
Maybe the Xojo Clipboard is limited for some reason to the first item in the pasteboard array?
Edited to add: I tested the copying of multiple filepaths in the AppKit app, and each file entry is a separate item in the NSArray. Hopefully that tells us something?
The clipboard may hold several flavours at once. So it’s fairly possible it contains both an UTF8 flavour (which is limited to only the first item in the Finder, e.g. if the Finder implements it that way (this easily happens for historical reasons)) and another flavour, that BBEdit knows about and has the ability to paste. Then, when you paste-copy in BBEdit, this is turned as UTF8/plain text only and you see it differently since the clipboard contains a different set of flavours.
yes this must be it, there must be an intermediate step such that public.utf8-plain-text version is created by xojo from what’s on the clipboard, not by the Finder.
So I revise my conclusion: xojo is unable to parse multiline text entries generated by the Finder’s option-copy, whereas BBEdit and TextEdit can, but curiously, Word and Apple’s own Pages cannot.
Clipboard flavors are very different depending on whether you ‘copy’ or ‘option-copy’ multiple items form the Finder.
with all due respect Tim, when BBEdit, TextEdit, ClipBoard Viewer, Curio, GoogleDocs, and MBS are able to extract what I expect (and what actually is) on the clipboard, while Xojo cannot, then I conclude there is a problem with the latter.
I’m sure there are complexities under the hood that account for this anomaly, but the point of Xojo is to insulate us from this, unless we choose otherwise.
When you say “You have to do work to access that whole array.”, sure if ur so inclined, but to me c.Text should do the simple thing it’s supposed to. The above apps seem to know how to do this as expected (admittedly a number of others cannot either). A lot of times yes, “it’s my code” does apply, but in this case i’ll have to disagree.
