Confused with VBA and VB variable addresses and pointers.
-
- 5StarLounger
- Posts: 742
- Joined: 27 Jun 2021, 10:46
Re: Confused with VBA and VB variable addresses and pointers.
>Using the long pointer stuff instead of a string gets us past the Unicorn to "ANSI" first conversion
Yep - there's a bit more to it than that, but essentially correct.
Yep - there's a bit more to it than that, but essentially correct.
-
- 5StarLounger
- Posts: 773
- Joined: 18 Jan 2022, 15:59
- Location: An Englishman, illegally re-routing rivers, in Hof, Beautiful Bavaria. Rule, Britannia!
Experiments with StrTrimA "doing nothing" with string parameters As String, using lots of ChrW( ) characters
Hi
I have been continuing looking in detail at some of the issues raised in this Thread. I possibly still will be for a few days……
In particular I looked a lot at the stuff with the "StrTrim / StrTrimTrick doing nothing experiments" which started here
I extended those experiments quite a bit, (an awful lot actually….)
_ I did some similar experiments with the StrTrimW, so making 4 experiments rather than the 2 above
_ I tried the experiment we did with that one character, ChrW(257) again, but with the a much bigger WUnicorn character range using 65536 characters ( 0 to 65535(FFFF) )
_ I then went on to do something similar but with the StrTrim_ actually doing something
I have not finished yet, and you don’t even want to see all I have done so far, Lol, but, just a few points of interest to be going on with…..
Looking for now just with the very first one of the StrTrinA experiments
_ It looks like you need to be very careful about what characters you are playing with, for a few reasons…..
Although the WUnicorn character list got from ChrW() seems consistent, the list you can get from the Chr() on different computers isn’t consistent. Maybe that makes some sense because Chr() is in some way related to the characters around the decimal code points of 128-255, which, generally, can vary a bit. So that was not so much of a surprise to me
What did surprised me a bit, is that it looks initially as though whether the very first "A" version** , of the StrTrim_ works or not on a character is not dependant directly on you using a ChrW(x) , with x above 255, but rather it depends on if the character you use is in the list you get for Chr(x) , where x is from 0 to 255
Let me say that last bit once again, a bit differently, to make it clear what I am trying to say, as it is very very easy to get confused with these things…..
…So,… Our first experiment involved what I would call the "straight AASI" - That is the StrTrimA where the API declaration code line typically at the top of your code module uses string parameters given As String. (This is probably the way that, for historical reasons, most people would have initially used a win32 API in VBA. Only then later if something went wrong you might have looked further…. )
Our first experiment suggested, or at least inferred to me, that, simply said, … if you use some character above ChrW(255) , then you will likely get a different character back. - Our example used that ā thing ( ChrW(257) ). and the first experiment showed that you will get a simple a back. That might always be true. I am not sure. The point I am trying to make is that it would appear from my further experiments that, the determining factor is not if x is above 255 in ChrW(x), but rather the determining thing is whether the character you use is within those given by Chr(x) with x from 0 to 255. My further experiments suggest you could use a ChrW(x) where x might be over 400. It will depend on what set of characters you get for Chr(x) with x from 0 to 255. That set of characters is almost always a bit different from what you get for ChrW(x) with x from 0 to 255, and sometimes significantly different. To emphasise this last point, take a look at this: https://i.postimg.cc/DwgkfJ0f/Chr-W-244-Chr-W-268.jpg
That screenshot is a tiny bit from a very large file I am working on, and it is showing the situation around the 255 decimal code point area for a Laptop of mine. It is showing the very first experiment around a few of the WUnicorn characters centred on 255.
The number in the middle column is the WUnicorn decimal code point. I am just showing the sub range 244 - 268
The third column shows: On the left WUnicorn character being fed in to the "straight StrTrimA"; and on the right the character coming back; and In the middle is the German word to tell me if the character fed in is the same as that coming out.
The first column shows the Chr(x) of the WUnicorn character being fed in if that character is in the Chr( ) list.
So you can see that the determining factor of if you get out what you put in is whether you use a character in the Chr() list. It is not determined by using a ChrW(x) with x above 255.
( So far my experiments have found a ChrW(x) with x as high as 402 giving the Wahr (True) result in the comparison of what goes in to what comes out
I thought that was an interesting observation worth mentioning.
I am not sure if there is some useful conclusion to draw from this, perhaps one that helps explain a bit more about how these things work?
Alan
Edit P.S I should say that that screenshot above is for a less typical example – That laptop comes originally from Hungary I think. Most other computers I have come from Germany and exhibit the same phenomena, but it is less obvious - there are not as many matches, and they are further away from the 255, so that might explain why the phenomena has not been noticed. More typically you may need to look down at ChrW(x) where x is 338 339 352 353 376 381 382 402,
https://i.postimg.cc/Gt35J77s/More-typi ... ve-255.jpg
( ** or whatever you choose to call it , "ANSI" or whatever, - I use the latest Generical Termsinology standard, AASI )
I have been continuing looking in detail at some of the issues raised in this Thread. I possibly still will be for a few days……
In particular I looked a lot at the stuff with the "StrTrim / StrTrimTrick doing nothing experiments" which started here
I took the thing a bit further in a few ways:SpeakEasy wrote: ↑10 Jan 2025, 12:20.... VB translates the underlying Unicode string to ANSI when passing a string the the API. ANSI API functions then translate that to Unicode, and upon return from the API call the Unicode strings are translated back to ANSI - which VB then turns back into Unicode
..... Here, have an experiment ......Code: Select all
Private Declare Function StrTrim Lib "shlwapi.dll" Alias "StrTrim[B]A[/B]" (ByVal psz As String, ByVal pszTrimChars As String) As Long ' we'll be passing vb string to api Private Declare Function StrTrimTrick Lib "shlwapi.dll" Alias "StrTrim[B]A[/B]" (ByVal psz As Long, ByVal pszTrimChars As Long) As Long ' we'll be passing the StrPtr to API Public Sub trimmy()........ ...........
I extended those experiments quite a bit, (an awful lot actually….)
_ I did some similar experiments with the StrTrimW, so making 4 experiments rather than the 2 above
_ I tried the experiment we did with that one character, ChrW(257) again, but with the a much bigger WUnicorn character range using 65536 characters ( 0 to 65535(FFFF) )
_ I then went on to do something similar but with the StrTrim_ actually doing something
I have not finished yet, and you don’t even want to see all I have done so far, Lol, but, just a few points of interest to be going on with…..
Looking for now just with the very first one of the StrTrinA experiments
_ It looks like you need to be very careful about what characters you are playing with, for a few reasons…..
Although the WUnicorn character list got from ChrW() seems consistent, the list you can get from the Chr() on different computers isn’t consistent. Maybe that makes some sense because Chr() is in some way related to the characters around the decimal code points of 128-255, which, generally, can vary a bit. So that was not so much of a surprise to me
What did surprised me a bit, is that it looks initially as though whether the very first "A" version** , of the StrTrim_ works or not on a character is not dependant directly on you using a ChrW(x) , with x above 255, but rather it depends on if the character you use is in the list you get for Chr(x) , where x is from 0 to 255
Let me say that last bit once again, a bit differently, to make it clear what I am trying to say, as it is very very easy to get confused with these things…..
…So,… Our first experiment involved what I would call the "straight AASI" - That is the StrTrimA where the API declaration code line typically at the top of your code module uses string parameters given As String. (This is probably the way that, for historical reasons, most people would have initially used a win32 API in VBA. Only then later if something went wrong you might have looked further…. )
Our first experiment suggested, or at least inferred to me, that, simply said, … if you use some character above ChrW(255) , then you will likely get a different character back. - Our example used that ā thing ( ChrW(257) ). and the first experiment showed that you will get a simple a back. That might always be true. I am not sure. The point I am trying to make is that it would appear from my further experiments that, the determining factor is not if x is above 255 in ChrW(x), but rather the determining thing is whether the character you use is within those given by Chr(x) with x from 0 to 255. My further experiments suggest you could use a ChrW(x) where x might be over 400. It will depend on what set of characters you get for Chr(x) with x from 0 to 255. That set of characters is almost always a bit different from what you get for ChrW(x) with x from 0 to 255, and sometimes significantly different. To emphasise this last point, take a look at this: https://i.postimg.cc/DwgkfJ0f/Chr-W-244-Chr-W-268.jpg
That screenshot is a tiny bit from a very large file I am working on, and it is showing the situation around the 255 decimal code point area for a Laptop of mine. It is showing the very first experiment around a few of the WUnicorn characters centred on 255.
The number in the middle column is the WUnicorn decimal code point. I am just showing the sub range 244 - 268
The third column shows: On the left WUnicorn character being fed in to the "straight StrTrimA"; and on the right the character coming back; and In the middle is the German word to tell me if the character fed in is the same as that coming out.
The first column shows the Chr(x) of the WUnicorn character being fed in if that character is in the Chr( ) list.
So you can see that the determining factor of if you get out what you put in is whether you use a character in the Chr() list. It is not determined by using a ChrW(x) with x above 255.
( So far my experiments have found a ChrW(x) with x as high as 402 giving the Wahr (True) result in the comparison of what goes in to what comes out
I thought that was an interesting observation worth mentioning.
I am not sure if there is some useful conclusion to draw from this, perhaps one that helps explain a bit more about how these things work?
Alan
Edit P.S I should say that that screenshot above is for a less typical example – That laptop comes originally from Hungary I think. Most other computers I have come from Germany and exhibit the same phenomena, but it is less obvious - there are not as many matches, and they are further away from the 255, so that might explain why the phenomena has not been noticed. More typically you may need to look down at ChrW(x) where x is 338 339 352 353 376 381 382 402,
https://i.postimg.cc/Gt35J77s/More-typi ... ve-255.jpg

( ** or whatever you choose to call it , "ANSI" or whatever, - I use the latest Generical Termsinology standard, AASI )
You do not have the required permissions to view the files attached to this post.
Regards , Ālan , DocÆlstein
, 


-
- 5StarLounger
- Posts: 742
- Joined: 27 Jun 2021, 10:46
Re: Confused with VBA and VB variable addresses and pointers.
>Maybe that makes some sense because Chr() is in some way related to the characters around the decimal code points of 128-255, which, generally, can vary a bit
As I've said previously: Code pages
> it depends on if the character you use is in the list you get for Chr(x) , where x is from 0 to 255
Again, as I said -if the Unicode codepoint maps to a character withing the current extended ANSI character set (which can indeed differ from machine to machine as it consists - normally, but not always - of the 128 ASCII characters plus the 128 characters in the currently selected code page) then that is the character you will get back
How does this conversion/mapping happen. Again, as previously noted, through the internal use of WideCharToMultiByte
>one that helps explain a bit more about how these things work?
I already know how things work ... :-)
By the way, just so we are clear, there's nothing special about StrTrim. I only selected it because it is an API function that takes a string and can be called in such a way that the API call itself does nothing to that string. This was so we could 'see' the internal translations that go on. There are other functions that we might have used.
As I've said previously: Code pages
> it depends on if the character you use is in the list you get for Chr(x) , where x is from 0 to 255
Again, as I said -if the Unicode codepoint maps to a character withing the current extended ANSI character set (which can indeed differ from machine to machine as it consists - normally, but not always - of the 128 ASCII characters plus the 128 characters in the currently selected code page) then that is the character you will get back
How does this conversion/mapping happen. Again, as previously noted, through the internal use of WideCharToMultiByte
>one that helps explain a bit more about how these things work?
I already know how things work ... :-)
By the way, just so we are clear, there's nothing special about StrTrim. I only selected it because it is an API function that takes a string and can be called in such a way that the API call itself does nothing to that string. This was so we could 'see' the internal translations that go on. There are other functions that we might have used.
-
- 5StarLounger
- Posts: 773
- Joined: 18 Jan 2022, 15:59
- Location: An Englishman, illegally re-routing rivers, in Hof, Beautiful Bavaria. Rule, Britannia!
Re: Confused with VBA and VB variable addresses and pointers.
Hi
Thanks for the reply.
Code Pages .. etc. …..if the Unicode code point maps to a character within the current extended ANSI character set (which can indeed differ from machine to machine as it consists - normally, but not always - of the 128 ASCII characters plus the 128 characters in the currently selected code page …..
Ok , thanks. Something along those lines would have been my best guess so far, (based to a large extent on what I have picked up from you so far, and also my further experiments).
I don’t think I would have worded it like that.
I am still not sure if I should
_The terminology of extended ANSI puts me off a bit. We are back to iffy and imprecise terms there, perhaps. In this context, I think, we are using the term ANSI to refer to characters from about the decimal code points 127 to 255, ( or we might be referring to the 0-255. As you say the first half from 0 are usually the same ASCIII things, so mostly we are interested in looking at the second half. ( This is one reason for the introduction of the term AASI , which attempts to give a term for people to use to communicate better in this area ).
I am not sure what the extended means here? (Once in a while you do hear the term extended ASCII to refer to decimal code points 127 to 255, but once again you are on dangerous ground and will get loved or hated by whoever reads it, or you will get loved or hated by the same person, depending on what day of the week the same person reads it.
_._________________
Specifically to code pages
OK, so I picked up a lot from you and my researching in recent weeks on that. I am having some issues there currently….
A minor problem first. It seems hard to find a simple list/ table for any code page, or code pages. This is not an insurmountable problem though, - maybe it's just one of my destinies to produce a few concise simple lists of the code pages likely to be of interest to people. There are some definite errors and inconsistencies in the internet. But that is OK – the internet is not controlled, and there can be problems when the characters used themselves cause problems in what is finally seen . The author's either never noticed or don't care. You just need to be very thorough and careful, that’s all. Perhaps no one has been yet. Understandable when you are playing with tons of characters and they may either cause something unexpected or not look as they should, or won’t copy etc. etc…
Now my main problem just now on this mapping to selected code page
OK, so I have an idea about code pages. But I am not fully there yet on that. Perhaps you have some ideas here as to where I am going wrong…
So. I tired getting the code page from PowerShell using the command chcp – Why? – Because I have not yet googled any other way to get it.
Take two computers. One I have which gives me an untypical 852, and one that gives me the more typical 850. (So far most of my computers give me 850)
Take a look at the table here , or perhaps its easier to see in the uploaded file.
So far I found two list on the internet for code page 852. They are slightly different from each other, and they are not the same as the list I get from Chr(x) with x from 0 - 255
There are more list in the internet for 850, and so far they all look the same, ( or they do once you correct the thing the author missed or ignored, - things like the entry for delete not being there as it got deleted or columns getting a bit disjointed by the characters related to a new line ). But once again the ( repaired ) list does not tie up with that got from Chr(x) with x from 0 - 255
What am I missing? Am I looking at the wrong code pages?
_._________________
I already know how things work ... :-) I figured that out some time ago. I hang on what you say like it's from God almighty himself. I don't always understand it at the time, but often later it helps make things drop in to place.
_.__________________-
Thanks, Alan
Thanks for the reply.
Code Pages .. etc. …..if the Unicode code point maps to a character within the current extended ANSI character set (which can indeed differ from machine to machine as it consists - normally, but not always - of the 128 ASCII characters plus the 128 characters in the currently selected code page …..
Ok , thanks. Something along those lines would have been my best guess so far, (based to a large extent on what I have picked up from you so far, and also my further experiments).
I don’t think I would have worded it like that.
I am still not sure if I should
_The terminology of extended ANSI puts me off a bit. We are back to iffy and imprecise terms there, perhaps. In this context, I think, we are using the term ANSI to refer to characters from about the decimal code points 127 to 255, ( or we might be referring to the 0-255. As you say the first half from 0 are usually the same ASCIII things, so mostly we are interested in looking at the second half. ( This is one reason for the introduction of the term AASI , which attempts to give a term for people to use to communicate better in this area ).
I am not sure what the extended means here? (Once in a while you do hear the term extended ASCII to refer to decimal code points 127 to 255, but once again you are on dangerous ground and will get loved or hated by whoever reads it, or you will get loved or hated by the same person, depending on what day of the week the same person reads it.
_._________________
Specifically to code pages
OK, so I picked up a lot from you and my researching in recent weeks on that. I am having some issues there currently….
A minor problem first. It seems hard to find a simple list/ table for any code page, or code pages. This is not an insurmountable problem though, - maybe it's just one of my destinies to produce a few concise simple lists of the code pages likely to be of interest to people. There are some definite errors and inconsistencies in the internet. But that is OK – the internet is not controlled, and there can be problems when the characters used themselves cause problems in what is finally seen . The author's either never noticed or don't care. You just need to be very thorough and careful, that’s all. Perhaps no one has been yet. Understandable when you are playing with tons of characters and they may either cause something unexpected or not look as they should, or won’t copy etc. etc…
Now my main problem just now on this mapping to selected code page
OK, so I have an idea about code pages. But I am not fully there yet on that. Perhaps you have some ideas here as to where I am going wrong…
So. I tired getting the code page from PowerShell using the command chcp – Why? – Because I have not yet googled any other way to get it.
Take two computers. One I have which gives me an untypical 852, and one that gives me the more typical 850. (So far most of my computers give me 850)
Take a look at the table here , or perhaps its easier to see in the uploaded file.
So far I found two list on the internet for code page 852. They are slightly different from each other, and they are not the same as the list I get from Chr(x) with x from 0 - 255
There are more list in the internet for 850, and so far they all look the same, ( or they do once you correct the thing the author missed or ignored, - things like the entry for delete not being there as it got deleted or columns getting a bit disjointed by the characters related to a new line ). But once again the ( repaired ) list does not tie up with that got from Chr(x) with x from 0 - 255
What am I missing? Am I looking at the wrong code pages?
_._________________
I already know how things work ... :-) I figured that out some time ago. I hang on what you say like it's from God almighty himself. I don't always understand it at the time, but often later it helps make things drop in to place.
_.__________________-
Thanks, Alan
You do not have the required permissions to view the files attached to this post.
Regards , Ālan , DocÆlstein
, 


-
- 5StarLounger
- Posts: 742
- Joined: 27 Jun 2021, 10:46
Re: Confused with VBA and VB variable addresses and pointers.
> The terminology of extended ANSI puts me off a bit
Me too, mea culpa Should have written extended ASCII, but my mind was wandering.
>One I have which gives me an untypical 852, and one that gives me the more typical 850
oh dear - see, 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. So yes, you are looking at the wrong code page(s)
Me too, mea culpa Should have written extended ASCII, but my mind was wandering.
>One I have which gives me an untypical 852, and one that gives me the more typical 850
oh dear - see, 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. So yes, you are looking at the wrong code page(s)
-
- 5StarLounger
- Posts: 773
- Joined: 18 Jan 2022, 15:59
- Location: An Englishman, illegally re-routing rivers, in Hof, Beautiful Bavaria. Rule, Britannia!
Re: Confused with VBA and VB variable addresses and pointers.
Ok , thanks, that GetACP() did Got it ,
' https://i.postimg.cc/Kj0YvV3Z/Windows-CPage-KB1252.jpg
' https://i.postimg.cc/BZVgVzkc/Windows-C ... ry1250.jpg
, and the comparison tables here now look better, - the Chr(x); x = 32-255 and the appropriate Windows code page look identical for the two different sets I so far came across. , (and it was a lot easier to find lists for the windows code pages on the internet)
I had early on figured/ got the idea that Chr(x) was likely linked to the/ a code page somewhere, but went off track when I bumped into the PowerShell given chcp code page, - as far as I recall there was only the reference to code page where I stumbled over that. Also the word windows was also missing in a lot of places where I think it should have often been tacked on to the usage of the words code page
The documentation/Blogs I saw did not help, saying like …. Chr function returns a String containing the character associated with the specified character code. – That is not incorrect , but probably would be better as something along the lines of
…..Chr ( x ) , x = 0 to 255 , function returns a String containing the character associated with the specified decimal character code point, x. Which specific character is "mapped" to one of those x numbers may vary slightly from computer to computer. You can see which characters you have "mapped" , by either
_ Looping through in a simple VBA coding
Or
_ getting the windows code page number ( for example with the GetACP API stuff ) , then looking for a table for that window's code page number
This whole business with character representation in computers is one of the most atrociously imprecisely and often incorrectly or incompletely written about subject I ever came across. It ends up infecting us all and we all go on to make the same mistakes. Perhaps it’s just a subject area with a bit too much for the average Human brain to keep straight in his mind in one go, so we most often slip off track when trying to write something about it.
I am starting writing an extra musing just now.. Interactions with AASI and WUnicorns at the bottom bit .. at the top of that link , to help try and lessen the pain in future.
A question if I may …
The following is definitely not me nitpicking, rather it is just me in my ignorance trying to write something for me that I can understand, or that helps me not missing something later. ( This is not only helpful for me but could be a major advancement for mankind, because if I can understand something written then there won't be many people on this earth that won’t understand it – often the most stupid or ignorant people often make the best teachers…… once they do understand something. So I could be the world's best … one day… )
With reference to this:
' add a Unicode character that is not mapped to the "ANSI" character set in use, (Note this will most likely be a Unicode character above ChrW(255), but there may occasionally be a few Unicode character above ChrW(255) mapped to the "ANSI" character set in use, so choose your character carefully. …. .. (and after that I would probably give a reference to what I am writing just now )…………
Alan
' https://i.postimg.cc/Kj0YvV3Z/Windows-CPage-KB1252.jpg
' https://i.postimg.cc/BZVgVzkc/Windows-C ... ry1250.jpg
Code: Select all
Option Explicit ' https://eileenslounge.com/viewtopic.php?p=324440#p324440
Private Declare Function GetACP Lib "kernel32" () As Long
Sub GetWindoesCP()
Dim CpageNumber As Long
Let CpageNumber = GetACP()
End Sub
' https://i.postimg.cc/Kj0YvV3Z/Windows-CPage-KB1252.jpg
' https://i.postimg.cc/BZVgVzkc/Windows-CPage-SSD2-Hungary1250.jpg
I had early on figured/ got the idea that Chr(x) was likely linked to the/ a code page somewhere, but went off track when I bumped into the PowerShell given chcp code page, - as far as I recall there was only the reference to code page where I stumbled over that. Also the word windows was also missing in a lot of places where I think it should have often been tacked on to the usage of the words code page
The documentation/Blogs I saw did not help, saying like …. Chr function returns a String containing the character associated with the specified character code. – That is not incorrect , but probably would be better as something along the lines of
…..Chr ( x ) , x = 0 to 255 , function returns a String containing the character associated with the specified decimal character code point, x. Which specific character is "mapped" to one of those x numbers may vary slightly from computer to computer. You can see which characters you have "mapped" , by either
_ Looping through in a simple VBA coding
Or
_ getting the windows code page number ( for example with the GetACP API stuff ) , then looking for a table for that window's code page number
This whole business with character representation in computers is one of the most atrociously imprecisely and often incorrectly or incompletely written about subject I ever came across. It ends up infecting us all and we all go on to make the same mistakes. Perhaps it’s just a subject area with a bit too much for the average Human brain to keep straight in his mind in one go, so we most often slip off track when trying to write something about it.
I am starting writing an extra musing just now.. Interactions with AASI and WUnicorns at the bottom bit .. at the top of that link , to help try and lessen the pain in future.
A question if I may …
The following is definitely not me nitpicking, rather it is just me in my ignorance trying to write something for me that I can understand, or that helps me not missing something later. ( This is not only helpful for me but could be a major advancement for mankind, because if I can understand something written then there won't be many people on this earth that won’t understand it – often the most stupid or ignorant people often make the best teachers…… once they do understand something. So I could be the world's best … one day… )
With reference to this:
Would the following , also be correct:
' add a Unicode character that is not mapped to the "ANSI" character set in use, (Note this will most likely be a Unicode character above ChrW(255), but there may occasionally be a few Unicode character above ChrW(255) mapped to the "ANSI" character set in use, so choose your character carefully. …. .. (and after that I would probably give a reference to what I am writing just now )…………
Alan
You do not have the required permissions to view the files attached to this post.
Regards , Ālan , DocÆlstein
, 


-
- 5StarLounger
- Posts: 742
- Joined: 27 Jun 2021, 10:46
Re: Confused with VBA and VB variable addresses and pointers.
>Would the following , also be correct:
> ...but there may occasionally be a few Unicode character above ChrW(255) mapped to the "ANSI" character set in use
No, not really. ChrW will never does any mapping to different characters. The mapping only occurs subsequently when VB internally translates the bytes representing the string. And you are only really aware of it becasue you are sticking your nose into places you were not (or Microsoft would prefer you were not) supposed to go.
> ...but there may occasionally be a few Unicode character above ChrW(255) mapped to the "ANSI" character set in use
No, not really. ChrW will never does any mapping to different characters. The mapping only occurs subsequently when VB internally translates the bytes representing the string. And you are only really aware of it becasue you are sticking your nose into places you were not (or Microsoft would prefer you were not) supposed to go.
-
- 5StarLounger
- Posts: 773
- Joined: 18 Jan 2022, 15:59
- Location: An Englishman, illegally re-routing rivers, in Hof, Beautiful Bavaria. Rule, Britannia!
Re: Confused with VBA and VB variable addresses and pointers.
OK, thanks ,that's enlightening, and also very encouraging. - Generally sticking my nose where it is less conventional to do so, has, on average, finally, been very rewarding. In addition, trying to take a peak where Microsoft would prefer I did not is likely to be morally a highly righteous thing to do, and may get me eternal life, even if it kills me doing so
I think this will do for now….
' Add a Unicode character that is not in the (windows) code page in use. Note: Typically this will be a Unicode character above ChrW(255), but that might not always be the case, so choose the character wisely: If you choose a Unicode character above ChrW(255) that happens to be in the (windows) code page in use, (and usually there are a few, see here https://www.excelfox.com/forum/showthre ... #post24947 ) , then when VB internally translates the bytes representing the string, we will map to the correct character, and this will mess up what ever it is we are trying to demonstrate, which Alan is still got his nose in in trying to figure it out
I think this will do for now….
' Add a Unicode character that is not in the (windows) code page in use. Note: Typically this will be a Unicode character above ChrW(255), but that might not always be the case, so choose the character wisely: If you choose a Unicode character above ChrW(255) that happens to be in the (windows) code page in use, (and usually there are a few, see here https://www.excelfox.com/forum/showthre ... #post24947 ) , then when VB internally translates the bytes representing the string, we will map to the correct character, and this will mess up what ever it is we are trying to demonstrate, which Alan is still got his nose in in trying to figure it out
Code: Select all
Let Ay = "Hello" & ChrW(257) ' Add a Unicode character that is not in the (windows) code page in use. Note: Typically this will be a Unicode character above ChrW(255), but that might not always be the case, so choose the character wisely: If you choose a Unicode character above ChrW(255) that happens to be in the (windows) code page in use, (and usually there are a few, see here https://www.excelfox.com/forum/showthread.php/2824/page2#post24947 ) , then when VB internally translates the bytes representing the string, we will map to the correct character, and this will mess up what ever it is we are trying to demonstrate, which Alan is still got his nose in trying to figure it out
Regards , Ālan , DocÆlstein
, 


-
- 5StarLounger
- Posts: 773
- Joined: 18 Jan 2022, 15:59
- Location: An Englishman, illegally re-routing rivers, in Hof, Beautiful Bavaria. Rule, Britannia!
VBA win32 API Functions and VB(A) strings
Hi,
Before I continue with my experimenting, I thought I would make a first guess as to the final answer(s) I am looking for. I thought it was worth a quick try…
Here we go….
We have these insights, for a "ANSI" API ( MyAPIFunctionA ) when used in VB(A)
VB translates the underlying Unicode string to ANSI when passing a string to the API. ANSI API functions then translate that to Unicode, and upon return from the API call the Unicode strings are translated back to ANSI - which VB then turns back into Unicode .
Using the long pointer stuff instead of a string gets us past the Unicorn to "ANSI" first conversion ( …..there's a bit more to it than that, but essentially correct)
For our very first experiment , the "straight AASI” as I calls it**, we first hit the VB translates the underlying Unicode string to ANSI. This meant, in laymen terms, characters in Chr(x) , x = 0 - 255 (i.e. those in the windows code page for the computer in use ) where "recognised".
Now, I am wondering/ suggesting , that perhaps the StrTrim(Ay, "") rather than doing nothing, is actually not doing anything, in the case of the very first experiment. By that I mean that possibly we by- pass the second pair, ANSI API functions then translate that to Unicode, and upon return from the API call the Unicode strings are translated back to ANSI
So we go straight to the VB then turns back into Unicode .
So, if we pass a character not "recognised" in the characters in Chr(x) , x = 0 - 255 ( those in the windows code page for the computer in use ) , we effectively have done this
…. VB translates the underlying Unicode string to ANSI when passing a string the API. …….. [not done anything here] ….. which VB then turns back into Unicode
The end result, as we saw, (and which I further confirmed across the 0 – 65535 range ) , is that the unrecognised characters come back as something , ( exactly what is a secondary issue for me for the time being ), but that something ain't what they were, as they effectively got "lost" when they weren’t recognised. That ,I am suggesting, is approximately all that happens/happened
( One small extra little things to note here:
_This is not working for ChrW(x) where x is 128 – 159 --- Perhaps this is reasonable as they are some "invisible" WUnicorn characters which will never be in any windows code page? )
In the second experiment, (StrTrimTrick) , we did what I call the "half way house HWH AASI”**. – We used the As long (pointer ) stuff instead of a string, and that gets us passed (by passes ) the VB translates the underlying Unicode string to ANSI when passing a string the the API. …….. ….. which VB then turns back into Unicode
In simple layman terms we have , in a way of speaking, not done anything to the character or characters we pass and get back exactly what we give across the whole 0 – 65535 range
_.________
I am not finished yet…
I took the experiments a stage further. Basically I just made sure the StrTrim was actually doing ( or trying to do ) something. (I gave it a string which included a character it was set to trim off, and I repeated all that using all characters in the 0-65535 range)
In this further new doing something equivalent of the very first experiment , we get no joy at all if we use any ChrW(x) where x is over 255. – Not even for a few as we did in the very first experiment where nothing was being done, ( or rather as I suggest ,we were not doing anything) .
I am wondering perhaps if way way down, in the very deep down innards where something is actually done, ( where not many people's noses or other organic organs have been ), way down here, for the MyAPIFunctionA , only a specific set of characters are recognised, perhaps some default windows code page which by design or coincidence is also what we get for ChrW(x) where x is 0 -127 and 160 – 255**
( There is a couple of extra little things to note here:
_(i) Any Chr( ) is OK, from any windows code page, so it is almost as if the limit has been set on the code point decimal number 255 somehow. In other words the actual number of different characters allowed will be a bit over 256, since the number of unique characters from two different window code pages will be a bit more than 256, since a few characters will be in one code page and not the other.
We seem to have a truncation process chopping off at 255 which we did not see in the not doing anything experiments
_(ii) **This is not working for ChrW(x) where x is 128 – 159 --- Perhaps this is reasonable as they are some "invisible" WUnicorn characters, which will never be in any windows code page? )
In these new experiments, moving then now on , as I did, to the Trick version , the previous Trick makes it worse, and we never get a correct return. I have not thought yet too much about that. But. Maybe it makes sense. - We bypass this, VB translates the underlying Unicode string to ANSI and so then have still WUnicode , which means the next bit … ANSI API functions then translate that to Unicode , is getting a WUnicode , thinking it’s a AASI so that translation will be a mess, pseudo like sort of trying to translate
x y z -----> x 0 y 0 z 0
but it got x 0 y 0 z 0 , so ends up with some such nonsense like this as a translation
x 0 y 0 z 0 -----> x 0 0 0 y 0 0 0 z 0 0 0
( If you look at the actual results, you mostly end up with nothing – that could tie up with a few too many ChrW(0) s flying around. ( And Yes, before you tell me, I do know to expect one extra ChrW(0) to get tacked on to what I get back – I am happy with that ) )
_.___
To finally get the whole thing to work , (which is by the way, the way I already figured out a few weeks ago. After which I found out I wasn't the first to "discover how". ……. Currently I am just trying to understand why. … )
What we need to do is the Trick, and use the MyAPIFunctionW
Perhaps I can hazard a guess now at the main difference between the MyAPIFunctionA and the MyAPIFunctionW , which is that…. way way down in the forbidden zone innards ,
the MyAPIFunctionA does Unicode, withUnicode characters ChrW(x) , x 0 to 255 whatever is in the relevant code page
, and
MyAPIFunctionW does Unicode, with Unicode characters ChrW(x) , x 0 to 65535 and maybe it does not do the translations …….. translate that to Unicode .. translated back to ANSI
_.,__________
How did I do today?
Thanks,
Alan
_._________________
** Generical Termsinology 4 experiment types – see - https://www.excelfox.com/forum/showthre ... #post24946
Before I continue with my experimenting, I thought I would make a first guess as to the final answer(s) I am looking for. I thought it was worth a quick try…
Here we go….
We have these insights, for a "ANSI" API ( MyAPIFunctionA ) when used in VB(A)
VB translates the underlying Unicode string to ANSI when passing a string to the API. ANSI API functions then translate that to Unicode, and upon return from the API call the Unicode strings are translated back to ANSI - which VB then turns back into Unicode .
Using the long pointer stuff instead of a string gets us past the Unicorn to "ANSI" first conversion ( …..there's a bit more to it than that, but essentially correct)
For our very first experiment , the "straight AASI” as I calls it**, we first hit the VB translates the underlying Unicode string to ANSI. This meant, in laymen terms, characters in Chr(x) , x = 0 - 255 (i.e. those in the windows code page for the computer in use ) where "recognised".
Now, I am wondering/ suggesting , that perhaps the StrTrim(Ay, "") rather than doing nothing, is actually not doing anything, in the case of the very first experiment. By that I mean that possibly we by- pass the second pair, ANSI API functions then translate that to Unicode, and upon return from the API call the Unicode strings are translated back to ANSI
So we go straight to the VB then turns back into Unicode .
So, if we pass a character not "recognised" in the characters in Chr(x) , x = 0 - 255 ( those in the windows code page for the computer in use ) , we effectively have done this
…. VB translates the underlying Unicode string to ANSI when passing a string the API. …….. [not done anything here] ….. which VB then turns back into Unicode
The end result, as we saw, (and which I further confirmed across the 0 – 65535 range ) , is that the unrecognised characters come back as something , ( exactly what is a secondary issue for me for the time being ), but that something ain't what they were, as they effectively got "lost" when they weren’t recognised. That ,I am suggesting, is approximately all that happens/happened
( One small extra little things to note here:
_This is not working for ChrW(x) where x is 128 – 159 --- Perhaps this is reasonable as they are some "invisible" WUnicorn characters which will never be in any windows code page? )
In the second experiment, (StrTrimTrick) , we did what I call the "half way house HWH AASI”**. – We used the As long (pointer ) stuff instead of a string, and that gets us passed (by passes ) the VB translates the underlying Unicode string to ANSI when passing a string the the API. …….. ….. which VB then turns back into Unicode
In simple layman terms we have , in a way of speaking, not done anything to the character or characters we pass and get back exactly what we give across the whole 0 – 65535 range
_.________
I am not finished yet…
I took the experiments a stage further. Basically I just made sure the StrTrim was actually doing ( or trying to do ) something. (I gave it a string which included a character it was set to trim off, and I repeated all that using all characters in the 0-65535 range)
In this further new doing something equivalent of the very first experiment , we get no joy at all if we use any ChrW(x) where x is over 255. – Not even for a few as we did in the very first experiment where nothing was being done, ( or rather as I suggest ,we were not doing anything) .
I am wondering perhaps if way way down, in the very deep down innards where something is actually done, ( where not many people's noses or other organic organs have been ), way down here, for the MyAPIFunctionA , only a specific set of characters are recognised, perhaps some default windows code page which by design or coincidence is also what we get for ChrW(x) where x is 0 -127 and 160 – 255**
( There is a couple of extra little things to note here:
_(i) Any Chr( ) is OK, from any windows code page, so it is almost as if the limit has been set on the code point decimal number 255 somehow. In other words the actual number of different characters allowed will be a bit over 256, since the number of unique characters from two different window code pages will be a bit more than 256, since a few characters will be in one code page and not the other.
We seem to have a truncation process chopping off at 255 which we did not see in the not doing anything experiments
_(ii) **This is not working for ChrW(x) where x is 128 – 159 --- Perhaps this is reasonable as they are some "invisible" WUnicorn characters, which will never be in any windows code page? )
In these new experiments, moving then now on , as I did, to the Trick version , the previous Trick makes it worse, and we never get a correct return. I have not thought yet too much about that. But. Maybe it makes sense. - We bypass this, VB translates the underlying Unicode string to ANSI and so then have still WUnicode , which means the next bit … ANSI API functions then translate that to Unicode , is getting a WUnicode , thinking it’s a AASI so that translation will be a mess, pseudo like sort of trying to translate
x y z -----> x 0 y 0 z 0
but it got x 0 y 0 z 0 , so ends up with some such nonsense like this as a translation
x 0 y 0 z 0 -----> x 0 0 0 y 0 0 0 z 0 0 0
( If you look at the actual results, you mostly end up with nothing – that could tie up with a few too many ChrW(0) s flying around. ( And Yes, before you tell me, I do know to expect one extra ChrW(0) to get tacked on to what I get back – I am happy with that ) )
_.___
To finally get the whole thing to work , (which is by the way, the way I already figured out a few weeks ago. After which I found out I wasn't the first to "discover how". ……. Currently I am just trying to understand why. … )
What we need to do is the Trick, and use the MyAPIFunctionW
Perhaps I can hazard a guess now at the main difference between the MyAPIFunctionA and the MyAPIFunctionW , which is that…. way way down in the forbidden zone innards ,
the MyAPIFunctionA does Unicode, with
, and
MyAPIFunctionW does Unicode, with Unicode characters ChrW(x) , x 0 to 65535 and maybe it does not do the translations …….. translate that to Unicode .. translated back to ANSI
_.,__________
How did I do today?
Thanks,
Alan
_._________________
** Generical Termsinology 4 experiment types – see - https://www.excelfox.com/forum/showthre ... #post24946
Regards , Ālan , DocÆlstein
, 


-
- 5StarLounger
- Posts: 773
- Joined: 18 Jan 2022, 15:59
- Location: An Englishman, illegally re-routing rivers, in Hof, Beautiful Bavaria. Rule, Britannia!
Re: Confused with VBA and VB variable addresses and pointers.
Hi
I have a quick question that may help me with my last questions and prognosieyes above
So….
We had this thing a while back, which was a brief statement to something that goes on when you are using the MyAPIFunctionA version…
_ …the blue bit,
VB translates the underlying Unicode string to ANSI when passing a string the the API…………………………………….. ……..
……………………………………………. which VB then turns back into Unicode is something that a few smart people I had already seen writing that they strongly suspected that happened, (but there is no real documentation, I believe – I can’t find any and nor could they)
and
_ The purple bit was good to hear as it made sense to some results of some experiments I was doing.
My question is: what would be the equivalent short statement for the MyAPIFunctionW version ?
_.__________________________
I am fairly sure the blue bit does not change because, even though no one can know for sure, there seems to be a strong census of opinion that Visual Basic does that when talking to api stuff, (possibly as part of some Marshalling stuff. (It does this perhaps as it knows that api’s somehow only speak "ANSI” language despite their innards and entrails working in Unicode) )
I suppose at the end of the day I am hoping to have at least a tiny bit more insight into the differences in the MyAPIFunctionW and the MyAPIFunctionA, other than the only answer anyone seems to know which is that the MyAPIFunctionW is the Unicode version of the MyAPIFunctionA which is the "ANSI" version. That is true of course, but it does not really tell me much.
Possibly I already do know the answer, and just need something that will help drop everything into place.
For example, I do understand pretty well now the differences in types of the LPSTR, LPWSTR pointer & Co., and quite a few other related things, so in the absence of any other insights I will make some mind boggling theory based on that, if I have to, Lol
Thanks
Alan
PS:
The TLDR to the question
This is MyAPIFunctionA “ANSI” stuff
VB translates the underlying Unicode string to ANSI when passing a string to the API. ANSI API functions then translate that to Unicode, and upon return from the API call the Unicode strings are translated back to ANSI - which VB then turns back into Unicode
This is MyAPIFunctionW Unicorn stuff
?????????????????????????????
I have a quick question that may help me with my last questions and prognosieyes above
So….
We had this thing a while back, which was a brief statement to something that goes on when you are using the MyAPIFunctionA version…
That didn’t confuse me at the time, (surprisingly to many I expect, Lol), becauseSpeakEasy wrote: ↑10 Jan 2025, 12:20..... VB translates the underlying Unicode string to ANSI when passing a string the the API . ANSI API functions then translate that to Unicode, and upon return from the API call the Unicode strings are translated back to ANSI - which VB then turns back into Unicode
_ …the blue bit,
VB translates the underlying Unicode string to ANSI when passing a string the the API…………………………………….. ……..
……………………………………………. which VB then turns back into Unicode is something that a few smart people I had already seen writing that they strongly suspected that happened, (but there is no real documentation, I believe – I can’t find any and nor could they)
and
_ The purple bit was good to hear as it made sense to some results of some experiments I was doing.
My question is: what would be the equivalent short statement for the MyAPIFunctionW version ?
_.__________________________
I am fairly sure the blue bit does not change because, even though no one can know for sure, there seems to be a strong census of opinion that Visual Basic does that when talking to api stuff, (possibly as part of some Marshalling stuff. (It does this perhaps as it knows that api’s somehow only speak "ANSI” language despite their innards and entrails working in Unicode) )
I suppose at the end of the day I am hoping to have at least a tiny bit more insight into the differences in the MyAPIFunctionW and the MyAPIFunctionA, other than the only answer anyone seems to know which is that the MyAPIFunctionW is the Unicode version of the MyAPIFunctionA which is the "ANSI" version. That is true of course, but it does not really tell me much.
Possibly I already do know the answer, and just need something that will help drop everything into place.
For example, I do understand pretty well now the differences in types of the LPSTR, LPWSTR pointer & Co., and quite a few other related things, so in the absence of any other insights I will make some mind boggling theory based on that, if I have to, Lol
Thanks
Alan
PS:
The TLDR to the question
This is MyAPIFunctionA “ANSI” stuff
VB translates the underlying Unicode string to ANSI when passing a string to the API. ANSI API functions then translate that to Unicode, and upon return from the API call the Unicode strings are translated back to ANSI - which VB then turns back into Unicode
This is MyAPIFunctionW Unicorn stuff
?????????????????????????????
Regards , Ālan , DocÆlstein
, 


-
- 5StarLounger
- Posts: 742
- Joined: 27 Jun 2021, 10:46
Re: Confused with VBA and VB variable addresses and pointers.
So, just to help with clarity.
API functions do not know anything about VB(A), and just expects to be fed the parameters it expects from whatever language is calling them. And VB(A) doesn't actually know the difference between MyAPIFunctionA and MyAPIFunctionW calls. What it does know, from the function prototype, is whether the API call is expecting a string or not. If it is expecting a string there are two things that happen - the underlying unicode string is converted to extended ascii, and the process of calling the function with the correct prototype ensures that a pointer to that extended ascii string is put on the stack (as we have previously explained), so that the function receives an extended ascii string (which is what we want for a MyAPIFunctionA)
So if the API function declaration does not include a string, then VB doesn't do any preconversion of the underlying string; we then rely on the declaration of the API function and a tiny bit of work from the programmer to ensure that we pass the pointer to the underlying string (unicode) to the API call (rather than VB doing it for us)
In other words, when calling correctly prototyped W functions VB isn't aware that it is passing a string, so no conversion occurs (of course, we can mess about with prototypes and, if we don't know what we are doing, cause havoc ...)
But why did the programmers of VB(A) do all that hard work to get the A functions working? Because VB strings were once extended ascii strings (i.e single byte character representation), and worked just fine with no clever work with the A functions. But then MS decided to change how VB stored strings (for a bunch of reasons, not least of which was it becoming COM-based), but they needed to maintain backwards compatibility, so that calling A functions seemingly worked exactly as it always had.
This may then help us answer your
>what would be the equivalent short statement for the MyAPIFunctionW version
When calling the MyAPIFunctionW the programmer is expected to pass the pointer to the underlying unicode string used by VB, which can be retrieved using StrPtr
API functions do not know anything about VB(A), and just expects to be fed the parameters it expects from whatever language is calling them. And VB(A) doesn't actually know the difference between MyAPIFunctionA and MyAPIFunctionW calls. What it does know, from the function prototype, is whether the API call is expecting a string or not. If it is expecting a string there are two things that happen - the underlying unicode string is converted to extended ascii, and the process of calling the function with the correct prototype ensures that a pointer to that extended ascii string is put on the stack (as we have previously explained), so that the function receives an extended ascii string (which is what we want for a MyAPIFunctionA)
So if the API function declaration does not include a string, then VB doesn't do any preconversion of the underlying string; we then rely on the declaration of the API function and a tiny bit of work from the programmer to ensure that we pass the pointer to the underlying string (unicode) to the API call (rather than VB doing it for us)
In other words, when calling correctly prototyped W functions VB isn't aware that it is passing a string, so no conversion occurs (of course, we can mess about with prototypes and, if we don't know what we are doing, cause havoc ...)
But why did the programmers of VB(A) do all that hard work to get the A functions working? Because VB strings were once extended ascii strings (i.e single byte character representation), and worked just fine with no clever work with the A functions. But then MS decided to change how VB stored strings (for a bunch of reasons, not least of which was it becoming COM-based), but they needed to maintain backwards compatibility, so that calling A functions seemingly worked exactly as it always had.
This may then help us answer your
>what would be the equivalent short statement for the MyAPIFunctionW version
When calling the MyAPIFunctionW the programmer is expected to pass the pointer to the underlying unicode string used by VB, which can be retrieved using StrPtr
-
- 5StarLounger
- Posts: 773
- Joined: 18 Jan 2022, 15:59
- Location: An Englishman, illegally re-routing rivers, in Hof, Beautiful Bavaria. Rule, Britannia!
Re: Confused with VBA and VB variable addresses and pointers.
Thanks
I am/was not far off, but the clarity helps a lot as if I am not sure it's easy to fall off and go wildly off in the wrong place.
I figured api knew nothing about VBA, ( I am not too sure about VB, - I thought perhaps VB and api might be old friends, maybe ones that had lost touch a bit in the 90’s. I know the feeing. It happens, sadly
). Perhaps my thoughts are/ were similar though, even if slightly lateral to that, but amounting perhaps to the same thing, at least as far as trying to understand api workings when used, called from VB(A):
For the time being I did not want to spread my limited brain capacity too thin, for example, in to get in to how apis are running , when they do, in C language stuff I think. So/ But I did got the point I think that api are not running in VB(A) runtime, and so in thinking that, indirectly , my thoughts were somewhere near what you said <… API functions do not know anything about VB(A), and just expects to be fed the parameters it expects from whatever language is calling them ….> So it helps to hear that from you. (Thoughts like that do actually pass my brain often, but they may not always stick, if I don’t hear them from others, - I have learnt that I need to be a bit careful with the thoughts that pass my brain, and refresh them a bit, (or it might be dangerous sometimes to the rest of the world, Lol.) )
I am not clear if function prototype*** and the Declare line are the same thing, but I get the point I think that VB(A) has some process (that might go under the name of marshalling ) to do the "ANSI" – Unicorn … Unicorn –"ANSI" (on string stuff) and it’s the sight of As String that tells it to use that mysterious marshalling thing, when appropriate at the call.
( *** I maybe need to try to research what the word prototype in computing people’s minds might mean?? - In Microwave Electronic Physics, I know what prototype means. I have some of the very best of those prototypes ever produced, hidden in my attic still. I party fled to the Fatherland and hid as a Hermit for 25 years with/ because of those. Without them, Smartphones might be a totally different concept these days. That is why I hate the damm things, (SmartPhones) )
_.________
<….. VB(A) doesn't actually know the difference between MyAPIFunctionA and MyAPIFunctionW calls…> that is a little gem of info that helps me a lot. I never picked that up anywhere yet. That helps me pick the right door in a few places on the journey to find the holy Pale, ( if there is any ,that is, as good as Hof Schlappen Bier, which I doubt)
_.__
<… If it is expecting a string there are two things that happen - the underlying Unicode string is converted to extended ascii, and the process of calling the function with the correct prototype ensures that a pointer to that extended ascii string is put on the stack …..> I almost got that from that Steven Roman’s , Chapter 6 Strings, that you put me on. What he calls a ABSTR gets made, then that is held somewhere temporary and that is the String that VB passes the contents of ( when told to by ByVal in the Declare) and that which it passes , the contents of, is the pointer to the "ANSI" format character array. (That is of the LPSTR Type, which for the MyAPIFunctionA is what is wanted by the api. (It is a ByRef call, of sorts, since it gets a pointer, the second of the two pointers kicking about here ) )
I am not sure if I would say it passes an extended ascii string, but then neither did you ,….. you said , the function receives an extended ascii string which I take as meaning the function will get that when it uses the pointer it gets.
I still do not know the main difference between the MyAPIFunctionW and the MyAPIFunctionA . Perhaps it is so obvious to you that you can’t envisage I haven’t got the point yet. My guess still is, that mainly it just hasn’t got the extra purple bit . ANSI API functions then translate that to Unicode, and upon return from the API call the Unicode strings are translated back to ANSI -
That fits of course with what you said <….When calling the MyAPIFunctionW the programmer is expected to pass the pointer to the underlying unicode string used by VB, which can be retrieved using StrPtr…..>
Whether I got that right or not, a bit of history, with dates, could help me a lot to fit things in that I have read. It is not at all clear from any literature when things came about.
This is my best guess, - it is only partly what you said I think:
Once upon a time there was api. And there was VB strings in "ANSI". And it was good (And maybe api functions always did do Unicode deep down) . Maybe then there was only a single MyAPIFunctionA version
Then when VB Strings turned into Unicorns, they kept, the MyAPIFunctionA as it were/ was, and made the extra MyAPIFunctionW by ripping the purple bit out???
That last bit could be rubbish. I don’t know.
_._____________
I have a feeling that soon I will have a very good understanding of the whole api string passing ByVal ByRef stuff.
But then… I have a slight concern that I might not then understand how in normal VBA procedure Calls it is at all possible to pass a String by value, as , …. using the ByVal there ,should also pass a pointer for the case of a string….
… – there’s something for you or someone to look forward to try to explain to me when I ask in 10 years time. Perhaps the answer is that VBA knows what VBA is and ByVal does not follow the same usual rule if the variable is a string, but rather it knows it is getting a pointer and not the value it is pointing to, as it would get a value with a simple number variable if it uses ByVal ….
_-
Thanks
Alan
_._________________________________
***Edit : - found it: Function Prototype in Computing: a declaration of the function that informs the program regarding the type of value returned. I expect its more to do with the C language that goes and runs the thing. VBA goes to C and says, Hello you boring old low level soul, Here's the function prototype, and the function, with a buffer or two, go see what havoc you can cause for me with that, and i don't want to see ya 'till ya finished, or there will be trouble for sure, for at least one of us....
I am/was not far off, but the clarity helps a lot as if I am not sure it's easy to fall off and go wildly off in the wrong place.
I figured api knew nothing about VBA, ( I am not too sure about VB, - I thought perhaps VB and api might be old friends, maybe ones that had lost touch a bit in the 90’s. I know the feeing. It happens, sadly

For the time being I did not want to spread my limited brain capacity too thin, for example, in to get in to how apis are running , when they do, in C language stuff I think. So/ But I did got the point I think that api are not running in VB(A) runtime, and so in thinking that, indirectly , my thoughts were somewhere near what you said <… API functions do not know anything about VB(A), and just expects to be fed the parameters it expects from whatever language is calling them ….> So it helps to hear that from you. (Thoughts like that do actually pass my brain often, but they may not always stick, if I don’t hear them from others, - I have learnt that I need to be a bit careful with the thoughts that pass my brain, and refresh them a bit, (or it might be dangerous sometimes to the rest of the world, Lol.) )
I am not clear if function prototype*** and the Declare line are the same thing, but I get the point I think that VB(A) has some process (that might go under the name of marshalling ) to do the "ANSI" – Unicorn … Unicorn –"ANSI" (on string stuff) and it’s the sight of As String that tells it to use that mysterious marshalling thing, when appropriate at the call.
( *** I maybe need to try to research what the word prototype in computing people’s minds might mean?? - In Microwave Electronic Physics, I know what prototype means. I have some of the very best of those prototypes ever produced, hidden in my attic still. I party fled to the Fatherland and hid as a Hermit for 25 years with/ because of those. Without them, Smartphones might be a totally different concept these days. That is why I hate the damm things, (SmartPhones) )
_.________
<….. VB(A) doesn't actually know the difference between MyAPIFunctionA and MyAPIFunctionW calls…> that is a little gem of info that helps me a lot. I never picked that up anywhere yet. That helps me pick the right door in a few places on the journey to find the holy Pale, ( if there is any ,that is, as good as Hof Schlappen Bier, which I doubt)
_.__
<… If it is expecting a string there are two things that happen - the underlying Unicode string is converted to extended ascii, and the process of calling the function with the correct prototype ensures that a pointer to that extended ascii string is put on the stack …..> I almost got that from that Steven Roman’s , Chapter 6 Strings, that you put me on. What he calls a ABSTR gets made, then that is held somewhere temporary and that is the String that VB passes the contents of ( when told to by ByVal in the Declare) and that which it passes , the contents of, is the pointer to the "ANSI" format character array. (That is of the LPSTR Type, which for the MyAPIFunctionA is what is wanted by the api. (It is a ByRef call, of sorts, since it gets a pointer, the second of the two pointers kicking about here ) )
I am not sure if I would say it passes an extended ascii string, but then neither did you ,….. you said , the function receives an extended ascii string which I take as meaning the function will get that when it uses the pointer it gets.
I still do not know the main difference between the MyAPIFunctionW and the MyAPIFunctionA . Perhaps it is so obvious to you that you can’t envisage I haven’t got the point yet. My guess still is, that mainly it just hasn’t got the extra purple bit . ANSI API functions then translate that to Unicode, and upon return from the API call the Unicode strings are translated back to ANSI -
That fits of course with what you said <….When calling the MyAPIFunctionW the programmer is expected to pass the pointer to the underlying unicode string used by VB, which can be retrieved using StrPtr…..>
Whether I got that right or not, a bit of history, with dates, could help me a lot to fit things in that I have read. It is not at all clear from any literature when things came about.
This is my best guess, - it is only partly what you said I think:
Once upon a time there was api. And there was VB strings in "ANSI". And it was good (And maybe api functions always did do Unicode deep down) . Maybe then there was only a single MyAPIFunctionA version
Then when VB Strings turned into Unicorns, they kept, the MyAPIFunctionA as it were/ was, and made the extra MyAPIFunctionW by ripping the purple bit out???
That last bit could be rubbish. I don’t know.
_._____________
I have a feeling that soon I will have a very good understanding of the whole api string passing ByVal ByRef stuff.
But then… I have a slight concern that I might not then understand how in normal VBA procedure Calls it is at all possible to pass a String by value, as , …. using the ByVal there ,should also pass a pointer for the case of a string….
… – there’s something for you or someone to look forward to try to explain to me when I ask in 10 years time. Perhaps the answer is that VBA knows what VBA is and ByVal does not follow the same usual rule if the variable is a string, but rather it knows it is getting a pointer and not the value it is pointing to, as it would get a value with a simple number variable if it uses ByVal ….
_-
Thanks
Alan
_._________________________________
***Edit : - found it: Function Prototype in Computing: a declaration of the function that informs the program regarding the type of value returned. I expect its more to do with the C language that goes and runs the thing. VBA goes to C and says, Hello you boring old low level soul, Here's the function prototype, and the function, with a buffer or two, go see what havoc you can cause for me with that, and i don't want to see ya 'till ya finished, or there will be trouble for sure, for at least one of us....
Last edited by DocAElstein on 31 Jan 2025, 10:28, edited 5 times in total.
Regards , Ālan , DocÆlstein
, 


-
- 5StarLounger
- Posts: 742
- Joined: 27 Jun 2021, 10:46
Re: Confused with VBA and VB variable addresses and pointers.
>VBA, ( I am not too sure about VB)
To all intents and purposes, VB and VBA are the same (sure, VBA has some extensions related to it's hosts, lacks the VB forms engine, and added support for 64 bit operation, and can't really be compiled into a standalone .exe - although it does get compiled)
>I am not clear if function prototype*** and the Declare line are the same thing
More or less, yes
>made the extra MyAPIFunctionW by ripping the purple bit out
No, it is more that the purple bit was added to the A functions
>the main difference between the MyAPIFunctionW and the MyAPIFunctionA
Basically it's PSTR versus PCWSTR (all the rest is really just the mechanics of putting the correct pointer on the call stack).
>maybe api functions always did do Unicode deep down
Nope. Or, at least, it depends ... the Win32 API was unicode (well, UCS-2 wide characters - and hence the W function naming - until the release of Windows 2000 when they moved to UTF-16) from the start - but the Windows API existed before win32; Windows 9x was not unicode.
To all intents and purposes, VB and VBA are the same (sure, VBA has some extensions related to it's hosts, lacks the VB forms engine, and added support for 64 bit operation, and can't really be compiled into a standalone .exe - although it does get compiled)
>I am not clear if function prototype*** and the Declare line are the same thing
More or less, yes
>made the extra MyAPIFunctionW by ripping the purple bit out
No, it is more that the purple bit was added to the A functions
>the main difference between the MyAPIFunctionW and the MyAPIFunctionA
Basically it's PSTR versus PCWSTR (all the rest is really just the mechanics of putting the correct pointer on the call stack).
>maybe api functions always did do Unicode deep down
Nope. Or, at least, it depends ... the Win32 API was unicode (well, UCS-2 wide characters - and hence the W function naming - until the release of Windows 2000 when they moved to UTF-16) from the start - but the Windows API existed before win32; Windows 9x was not unicode.
-
- 5StarLounger
- Posts: 742
- Joined: 27 Jun 2021, 10:46
Re: Confused with VBA and VB variable addresses and pointers.
>go see what havoc you can cause for me with that
Yes
Yes
-
- 5StarLounger
- Posts: 773
- Joined: 18 Jan 2022, 15:59
- Location: An Englishman, illegally re-routing rivers, in Hof, Beautiful Bavaria. Rule, Britannia!
Re: Confused with VBA and VB variable addresses and pointers.
Thanks, I have been through all that a few times, and most likely will be a lot again in/for a day or ten as it is helping a lot to drop the penny correctly finally in a few places.
Maybe win32 api could be a good bottom end to my current excursions , it might help my musings to pretend that win32 api is when life on earth began, even though I know it was not: I do actually have a very vague memory myself of people around me trying to get me to think of some strange pretty box type screen contraptions , aka Windows 95 computer stuff, at about the time I emigrated to the Fatherland. I might leave that pre-historic area though for some much later History foray. I do think, like in any technology, having an idea of the history can help a lot in understanding even the most modern stuff.
I am still feeling an urge to get a bit into VB, ( whether VB6 , or the ???? - whatever version is now what would have been called VB.Net.) I do like the idea of developing a form that can be turned into a standalone exe.
But that is a bit in the future, it will depend a bit on how the Wide World Scene develops as I help restrain the Forth Reich here just now.
I really now must put on a spurt and finish my little foray up VB(A)’s (win32) api String skirt, and then quit on that one while I'm ahead, before the Fuhrer comes home and catches me where he'd rather I wasn't.
Thanks again
Alan
Maybe win32 api could be a good bottom end to my current excursions , it might help my musings to pretend that win32 api is when life on earth began, even though I know it was not: I do actually have a very vague memory myself of people around me trying to get me to think of some strange pretty box type screen contraptions , aka Windows 95 computer stuff, at about the time I emigrated to the Fatherland. I might leave that pre-historic area though for some much later History foray. I do think, like in any technology, having an idea of the history can help a lot in understanding even the most modern stuff.
I am still feeling an urge to get a bit into VB, ( whether VB6 , or the ???? - whatever version is now what would have been called VB.Net.) I do like the idea of developing a form that can be turned into a standalone exe.
But that is a bit in the future, it will depend a bit on how the Wide World Scene develops as I help restrain the Forth Reich here just now.
I really now must put on a spurt and finish my little foray up VB(A)’s (win32) api String skirt, and then quit on that one while I'm ahead, before the Fuhrer comes home and catches me where he'd rather I wasn't.
Thanks again
Alan
Regards , Ālan , DocÆlstein
, 


-
- 5StarLounger
- Posts: 742
- Joined: 27 Jun 2021, 10:46
Re: Confused with VBA and VB variable addresses and pointers.
>that might go under the name of marshalling
Meant to mention this in a previous post - this is not marshalling
>an urge to get a bit into VB, (whether VB6 , or the ???? - whatever version is now what would have been called VB.Net
What used to be VB.NET (and is now just VB, in order to be confusing) is, in my opinion, not really VB - it bears certain syntactic similarities, but beneath the covers works very differently (which, by the way, means that much of your research about how things work in VB(A) is not applicable at all) - which can bite you if you are a VB6 programmer; things often do not work the way you might expect (or don't even exist, e.g StrPtr ...). On the other hand, if you are coming to it as a new language it is fine
Meant to mention this in a previous post - this is not marshalling
>an urge to get a bit into VB, (whether VB6 , or the ???? - whatever version is now what would have been called VB.Net
What used to be VB.NET (and is now just VB, in order to be confusing) is, in my opinion, not really VB - it bears certain syntactic similarities, but beneath the covers works very differently (which, by the way, means that much of your research about how things work in VB(A) is not applicable at all) - which can bite you if you are a VB6 programmer; things often do not work the way you might expect (or don't even exist, e.g StrPtr ...). On the other hand, if you are coming to it as a new language it is fine
-
- 5StarLounger
- Posts: 773
- Joined: 18 Jan 2022, 15:59
- Location: An Englishman, illegally re-routing rivers, in Hof, Beautiful Bavaria. Rule, Britannia!
Re: Confused with VBA and VB variable addresses and pointers.
OK, thanks.
I’ll bear that in mind, that what you said about the VB when I finally get around to that. You told me some similar stuff about VB and its history a few times before. I have it all noted.
Very useful to know just now that it isn't Marshalling… Because… I stumbled over a prominent German VBA chap who thinks he discovered the ….VB translates the underlying Unicode string to ANSI when passing a string the API…………………………………….. …….. which VB then turns back into Unicode , and he is telling the World so, at various meetings.
He decided to a call it Marshalling. (I nicked a pic out of one of his rhetorical Fuhrer amusings speeches, and put it in a musing of mine, one which I think you took a peek at a few weeks ago over at excelfox). I have decided to trash that all now and replace it with a lot of api codings using the RtlMoveMemory and rpiBSTRtoByteArray, some of which I got from the chapters up to and including Chapter 6 of Steven Roman’s book. The rest, which are along similar lines, I made up myself using all I learnt in the last few weeks on my VB(A) win32 api excursions . They demonstrate this not marshalling phenomeneye quite well.
Perhaps some of the StrTrimX experiments from this Thread will find their way into it as well. Almost certainly they will if I get my prognosieyes from a few posts back clear enough. Maybe some combination of all that, or not, depending on if it gets too confusing or not. I have a nice lot to choose from, or will have very soon i think.
Then, when I feel I have built up a good bit of ammunition I will hoist up the Union Jack and attack him. In friendly way, though, -his stuff was seriously a help and one of the better Tutorials on VBA api that has helped me a bit get started.
That is what I am doing at this moment, now, tidying up those codings, (which is a bit too many really, and I may have to trash a lot ), now that I think I have a better understanding of it, and all the pointer stuff that goes with it, which is to a large part thanks to your insights here and in a few related Threads, so thanks again.
I’ll bear that in mind, that what you said about the VB when I finally get around to that. You told me some similar stuff about VB and its history a few times before. I have it all noted.
Very useful to know just now that it isn't Marshalling… Because… I stumbled over a prominent German VBA chap who thinks he discovered the ….VB translates the underlying Unicode string to ANSI when passing a string the API…………………………………….. …….. which VB then turns back into Unicode , and he is telling the World so, at various meetings.
He decided to a call it Marshalling. (I nicked a pic out of one of his rhetorical Fuhrer amusings speeches, and put it in a musing of mine, one which I think you took a peek at a few weeks ago over at excelfox). I have decided to trash that all now and replace it with a lot of api codings using the RtlMoveMemory and rpiBSTRtoByteArray, some of which I got from the chapters up to and including Chapter 6 of Steven Roman’s book. The rest, which are along similar lines, I made up myself using all I learnt in the last few weeks on my VB(A) win32 api excursions . They demonstrate this not marshalling phenomeneye quite well.
Perhaps some of the StrTrimX experiments from this Thread will find their way into it as well. Almost certainly they will if I get my prognosieyes from a few posts back clear enough. Maybe some combination of all that, or not, depending on if it gets too confusing or not. I have a nice lot to choose from, or will have very soon i think.
Then, when I feel I have built up a good bit of ammunition I will hoist up the Union Jack and attack him. In friendly way, though, -his stuff was seriously a help and one of the better Tutorials on VBA api that has helped me a bit get started.
That is what I am doing at this moment, now, tidying up those codings, (which is a bit too many really, and I may have to trash a lot ), now that I think I have a better understanding of it, and all the pointer stuff that goes with it, which is to a large part thanks to your insights here and in a few related Threads, so thanks again.
Regards , Ālan , DocÆlstein
, 

