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

[DocAElstein]

This is Thread post 23 , forum post #post17885
https://www.excelfox.com/forum/showt...ll=1#post17885
https://www.excelfox.com/forum/showt...age2#post17885

---

……. the API, which knows nothing of BSTRs, assumes it is a pointer to an LPSTR (or LPWSTR) ……..
……In the case of passing strings, a pointer is passed, which has the effect of working similar to ByRef in a normal VBA function…..

VB Strings and win32API

This post is based on research and some initial investigations. It will be followed by more development to support and further the knowledge.
For the sake of brevity we will use the convention of historical reference misnomers:
_ ANSI for the 1 Byte, 8 Binary Bit character encoding for the first 256 characters as defined in the Windows code page, and
_ Unicode for the 16 bit 2 Byte Little Endian encoding used by Microsoft to implement Unicode for the first 65536
Unicode or (Microsoft) ANSI?
API ANSI considerations
Let’s get one thing clear: deep in the innards, VB and VBA strings are Unicode. But some aspects of the innards workings of the API Functions ( the API functionAs that most people are familiar with) , do most all things in ANSI, as perhaps do a few other Microsoft things. Perhaps this makes sense, in a broader sense. API controls window things, in one way or another, and a lot of things involving strings goes on, messaging etc. All this can easily be done with things like Askjuszff982jw33i()%, etc.
Historically all API functions exclusively in their string workings used ANSI.
This plays a part in the issue/ problem sparking off these rhetoric musings. So things ANSI will also be considered, since their consideration helps with the final solution

(VBA) Runtime Unicode to ANSI Transfer
In simple terms, VB, albeit having Unicode 16 behind the scenes, only understands ANSI characters
There seems to be no official documentation to the following anomaly. ** However, this sounds reasonable: VB strings are stored in UNICODE, but all API calls are made with ANSI strings. This is accomplished by converting any string passed to an API call to ANSI before the call and back to UNICODE afterwards. While this conversion is transparent to the user most of the time, it makes it impossible to pass a UNICODE string from VB to a DLL via an argument typed As String in a Declare statement. Similarly, any structure which contains strings will go through the double conversion process during an API call. https://i.postimg.cc/28bPrbNj/Runtim...API-string.jpg


We note here, just briefly for now, that for most all the original the API functionAs a later functionW. This goes some way, unclear how much, to make the API function work more with Unicode. Possibly this is just some data, such as that likely to be passed / carried in it.


VB Strings Object
Thinking about a VB Strings as an object, comes partly from hindsight, as I think it helps get to grips with some of the other goings on further down in these rhetoric musings
A string variable itself is usually a "pointer", something like an address ( usually made with 32 bits ), of ( or usually part of, the left hand side start of ) the memory used to hold the actual string.
This variable is often referred to as a data type called BSTR, which is short for Basic String. A BSTR is, in fact, a 32 Bit pointer to a null-terminated Unicode character array (that is preceded by a 4-byte length field).
The thing pointed to and often "got", in a manner of speaking, the "object", will be something like a 1 dimensional array, where the elements are:
For ANSI: a bit close to an array of the characters we might be as layman familiar with, in
their character form,
or
their decimal encoding.
What we see or get, may depend on how we ask…… Example https://eileenslounge.com/viewtopic....297329#p297329 : StrConv("ZAC", vbFromUnicode) - coerced a string into a byte array

For Unicode: something similar….. maybe.
….The Unicode character array that is pointed to by a BSTR must be preceded by a 4-byte length field and terminated by a single null 2-byte character (ANSI = 0).
There may be additional null characters anywhere within the Unicode character array, so we cannot rely on a null character to signal the end of the character array. This is why the length field is vital.
Again, the pointer points to the beginning of the character array, not to the 4-byte length field that precedes the array.
https://postimg.cc/Xpgwq1Ny
Attachment 6147


LPSTR LPWSTR LPTSTR data types
There is a pseudo data type, LongPtr which has, or will adjust itself appropriately, to the format required for the pointer of a string variable. This can be used to store the pointers as shown in the above Penis Pointer diagram. This is likely to be useful based on the tip above…. ….. the API, which knows nothing of BSTRs, assumes it is a pointer to an LPSTR (or LPWSTR…..) …..
In documentation we distinguish three pointer types that can be stored in the LongPtr : An LPSTR string is defined as a pointer to a null-terminated ANSI character array. However, because the only way that we can tell when an LPSTR string ends is by the location of the terminating null, LPSTRs are not allowed to contain embedded null characters. Similarly, an LPWSTR is a pointer to a null-terminated Unicode character set with no embedded nulls. (The W in LPWSTR stands for Wide, which is Microsoft's way of saying Unicode.) )
Pointers in general seem to be flexible things, and we have a LPTSTR which will effectively view the final character string as appropriate: LPTSTR, designates a general type that can be compiled for either Windows code pages or Unicode.
VarPtr( ) strPtr( )
We can get the pointer from a string (the address of the real UNICODE string buffer), using the strPtr function. It seems to be one of those important historical facts, not so well publicised, that this was introduced to help overcome problems when Unicode was introduced around the 95/97 VB 4/5. All VB strings are stored in UNICODE, but all API calls are made with ANSI strings. This is accomplished by converting any string passed to an API call to ANSI before the call and back to UNICODE afterwards. While this conversion is transparent to the user most of the time, it makes it impossible to pass a UNICODE string from VB to a DLL via an argument typed As String in a Declare statement.
Unicode strings are converted to ANSI strings when using the declare statement as Win 95 didn't do Unicode.

Sub VBptr() '    https://stackoverflow.com/questions/47499525/why-is-the-result-of-varptrbyval-str-the-same-as-strptrstr-vb6/47500197#47500197
Dim BSTR As String ' BSTR is a 32 Bit pointer to a null-terminated Unicode character array (that is preceded by a 4-byte length field).
'  VarPtr( ) returns the starting address of the memory area in which a variable is stored
'                        VarPtr(ByVal ) - Strings passed ByVal pass the address of the first character of the containing string in the BStr.
'                                             StrPtr( ) does the same, but makes sure it eturns the address of the real UNICODE string buffer
Debug.Print VarPtr(BSTR); VarPtr(ByVal BSTR); StrPtr(BSTR); StrPtr(ByVal BSTR)
'              1307644          0                    0              0
 Let BSTR = "Alan"
Debug.Print VarPtr(BSTR); VarPtr(ByVal BSTR); StrPtr(BSTR); StrPtr(ByVal BSTR)
'              1307644       141549884          141549884      141549884
' So VarPtr(BSTR) is the address of the Pointer. In that is the address of the first character, which VarPtr(ByVal ) should get, and might, and StrPtr most likely will. There isnt one if the variable is not filled

Dim Poynter As Long, Trget As String, Rslt As Variant
 Let Poynter = VarPtr(BSTR)
 VBGetTarget Trget, Poynter, LenB(BSTR)
Dim ByteArr() As Byte
'Call WtchaGot_Unic_NotMuchIfYaChoppedItOff(Trget) ' "A" & Chr(0) & "l" & Chr(0) & "a" & Chr(0) & "n" & Chr(0)
 Let ByteArr() = Trget
Call DBugPrntArr(ByteArr())  '  {65, 0, 0, 0, 108, 0, 0, 0, 97, 0, 0, 0, 110, 0, 0, 0}
Debug.Print BSTR, Trget      '     ?? - Trget might be anything            A l a n

End Sub

_._________________
It looks like we may be getting at some tools to assist us in the issues…. Let's see if we can find some more

_.______________________________

Some Tools for my research
_1 StrPtr(), and LongPtr – see last bits above
_2 Byte() Type Arrays and strConv()
……
A Unicode string, the final array object, is just a memory buffer so we can hack it. Which is what The StrConv Hacker Function
does…. This, and the Byte() Type Arrays in general , give both interesting and useful results, as well as a being great tools for researching the issues under consideration,…….
…… next post

---

Ref
https://web.archive.org/web/20201201...t/tips/varptr/ https://stackoverflow.com/questions/...-strptrstr-vb6
https://web.archive.org/web/20201113...rconv-function
** Page 35, Steven Roman's book, Win32 API Programming: when we pass a string to an external function, VB translates the string from Unicode to ANSI