c.Text retrieves incorrect (incomplete) data

[AlbertoD]

@Peter_Stys

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.

@Peter_Stys

but curiously, Word and Apple’s own Pages cannot.

@Tim_Parnell

The data is stored in an array

Peter, create a Feature Request and ask Xojo to convert the array to text separated with 0A as the working solutions do.

[Peter_Stys]

Alas, I don’t submit FR’s or bug reports anymore because (almost) invariably my reports don’t get enough “votes”, so languish for years and never get fixed (another conversation entirely). I’m hoping Xojo folks read the forum, and if they see this and feel it’s important, they’ll fix it.

[AlbertoD]

Too bad you don’t open tickets anymore.
I don’t think Xojo will change anything as Apple Pages works the same (without a feature request).

[Arnaud_N]

@Peter_Stys

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.

You’re occulting the fact that Pages (and a few others) also don’t handle it.
And, most products you describe have already been coded; Xojo is just a programming language and it’s up to you to handle the tool as necessary.
(of course, I recognise that as long as you think Xojo is the culprit, you won’t think it matters to try the code in other ways, but you have to be sure your code is correct before thinking it’s Xojo’s fault).

@Peter_Stys

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.

Xojo can’t do much if we don’t write code .

@Peter_Stys

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.

It does.
The Finder stores at least 2 flavours in the clipboard, as have already been determined:
1: an utf8 string that stores only the first selected item; it’s what Clipboard.Text retrieves.
2: another flavour, yet to be determined and handled in your code, containing all the paths, that some apps like BBEdit happen to handle.
You must find the correct flavour and retrieve it from your code. Xojo has no way to return (nor know) all the flavours in a single method call.

You may think of it like a similar “issue”: Finder labels and tags. Historically, the Finder only provided labels (colours and labels). Then, eventually, support for tags was added (a list of customisable labels). At that point, what should legacy labels return when there are several tags set? Apple chose to return just the first tag when one wants to query the legacy label API.
We can just assume the same about paths: the utf8 version had a legacy purpose and had to be kept around, and you must use another flavour to query the “new” way.

@Peter_Stys

The above apps seem to know how to do this as expected (admittedly a number of others cannot either).

They are handling other flavours, which you need to do as well.
Again, Xojo won’t do something if you don’t tell it to (and hopefully so, otherwise we wouldn’t have control on what we do).

[Peter_Stys]

I understand all points made. However, if I asked most people the following question:

“If you select 2 items in the Finder and do a copy, what plain text do you expect to get from the clipboard?”

I think i can guess what most would say, but maybe I’m in the minority.

[Arnaud_N]

@Peter_Stys

“If you select 2 items in the Finder and do a copy, what plain text do you expect to get from the clipboard?”

I think i can guess what most would say, but maybe I’m in the minority.

I understand your expectation, but I’d say it’s a Finder issue, because it doesn’t provide the path in the standard flavour.