Tests Copying, Pasting, API Cliipboard issues. and Rough notes on Advanced API stuff

[DocAElstein]

Some initial observations and conclusions
Some of these conclusions and observations may change as time goes on and I try many different computers, but provisionally, as notes to possibly come back to and update

The character lists used in my experiments
The VBA ChrW( ) function seems to give a consistent list across different computers
The VBA Chr( ) and Excel CHAR( ) give identical results on any computer. (So from now on observations for the Chr( ) also apply to the CHAR( ) )
The Chr( ) as expected is always the same characters across the 0-127 (ASCII) range. Above 127 the characters got from Chr( ) can vary on different computers. They do not seem to match the characters from the published tables based on the code page I obtain from chcp in PowerShell . They wouldn’t. … interrogating the code page from a (DOS) command such as chcp gives you the MS-DOS code page, not the windows code page .... You need to look at the GetACP API call The match with the characters from the relevant windows code page and Chr(x) is then the same ( https://www.excelfox.com/forum/showt...ll=1#post24947 )

Observations for the StrTrim doing nothing to a character, (or maybe not actually doing anything to a character – subtle different…. Maybe….)
Some conventions for these observation musings:
"OK"
If something is "OK", it means the character fed in via the variable, Ay , seems to be the same as that coming back in that variable. So this means results like
Ê Wahr Ê ( Wahr on my mostly German computers is True in English )
"Wonky"
"Wonky" means I may not always get the OK results, but that at this stage I do not have enough results to be more precise.
"Don't work"
Something like "don't work" / not work, or similar means I mostly get a mismatch with what comes out compared to what goes in, but once again, at this stage I can't be more precise


It may be easier to "work backwards"…

The full WUnicorn
The full WUnicorn appears to return the character it gets across the full 0 - 65535 decimal (Hex FFFF ) code point range

The half way house WUnicorn
The half way house WUnicorn is OK up to 127. From 128 to 255 it can be a bit wonky. Above 255 you may only occasionally find the odd Wahr ( True ) match to in and out

The half way house ASII
This appears to give the same "perfect" results as for the full WUnicorn for the case of StrTrim doing nothing to a character, (or maybe not actually doing anything to a character)

The straight ASII
Based on the first occurrence I saw of this, with the StrTrimA I was expecting this to not work above 255. At first glance this appeared to be the case. However as a result of looking more carefully, and also trying out a lot of computers I was able to see some anomalies , above 255 and also below 256

_ For the Chr( ) characters the straight ASSI works (True result) across the 0-255 range

_ For the ChrW( ) the story is interesting. These anomalies are such that not only do we see it working sometimes above 255 but also occasionally not working below 256
Over the ASCII decimal code point range, 0 to 127 it mostly works, (True result)
Going up to 160 it is mostly False
From 160 to 255 they can all be True on a computer, or I have seen it approximately 50 50
Above 255 to approximately 400 you can get just a few correct on one computer or about a third on another
Here is an example for a computer with windows code page 1250
https://i.postimg.cc/0jFgS1ZG/Straig...D2-CP-1252.jpg