I have an app where users can copy and paste columns of numbers from other apps into mine.
Excel and other apps put a carriage return or CR/LF after each row’s contents, so I parse the incoming clipboard data based on LF/CR or just CR depending on the platform.
However, it turns out that Apple Numbers uses a carriage return before every entry, and then another one at the very end of the clipboard text.
This produces a phantom empty first cell. I could assume that users would never copy a blank cell as the first entry, but I know there are cases where that’s what the data is, so that’s what should be pasted.
So how do I make logical sense of this extra CR and know when it’s meaningful and when it’s not? Is there a RawData type I can look for to see when the data is coming from Numbers?
if the user DID copy data with a blank cell as the first entry…wouldn’t it have TWO CR at the beginning?
One to start the blank cell, and one to start the “2nd” cell
dim cellData() as string
cellData=split("X"+stringofData,endofline)
Notice… I get 0A which makes sense since LF is standard for OSX, while you say you get OD
but if I run your “code” I get what you say… which in my opinion is WRONG, since it should be OA for both EXCEL and NUMBERS
and the order should be the SAME (which for any other program it IS
Personally I “think” it has to do with how XOJO is dealing with the clipboard, as in EXCEL there is no “default” formatting, but in NUMBERS there is (shading in 1st row/col), although in NUMBERS it doesn’t seem to matter where you cut the cells from
The plot thickens, indeed. I copied from Excel (MS Office 2008) and Numbers and pasted into 0xED (my favorite Hex editor) and got the same results from both apps, EXCEPT that Numbers used 0A and Excel used 0D.
Which sure makes it look like there’s a problem with the Xojo Clipboard, and I don’t see any workarounds. I hate telling my users that unexpected results aren’t my fault…
Hopefully one of the Xojo engineers will read this and clarify what’s happening!
Years ago when I first started dealing with the clipboard, the Mac documentation mentioned that the application can and should copy the data to the clipboard in multiple formats so that the destination application could then take its pick of the best format to use. For example, Numbers could be copying both formatted and unformatted text as well as a Numbers internal format (for formulas etc.). I don’t know if the clipboard still works the same way, but if so, you may have to check that you’re using the correct clipboard data.
I tried to find a similar one for Mac, but wasn’t able to locate any. From dealing with the clipboard years ago on Mac (pre-OSX) each data type had a four character type code similar (and in many cases identical with) four character file types, such a TEXT, PICT, etc. There were quite a few different ones, for all of the different image formats and various data structures. I was using Think Pascal in those days, and you had to go digging through the info in the clipboard object to find the data in the format that you were looking for.
This is probably moot, because I just fired up one of my old XOJO projects to see how it is handled, and realized that you are given only two choices: text or picture. So, obviously XOJO is picking and choosing which of the many clipboard formats to present to you, and you don’t have any choice.
I think there are some utility programs that will allow you to examine the contents of the clipboard to see all of the formats of the data currently available. If you can find one that is suitable, then maybe you can use some alternative code to extract it (either a plug-in or some declares).
You could check to see if the raw data type com.apple.iwork.TSPNativeData exists, and if so, you know that it came from one of the iWork apps.
Also, UTI’s public.utf8-plain-text and NSStringPboardType have no leading CR
while UTI’s TEXT and com.apple.traditional-mac-plain-text have a leading CR