Unicode API
in [Visual Basic]
|
Prev: System Timer Callback?
Next: Any thoughts? Application error .data not place into memory because of an I/O error
From: Nobody on 4 Aug 2010 14:08 "Kevin Provance" <k(a)p.c> wrote in message news:i39vpn$394$1(a)news.eternal-september.org... > I'm curious. > > By accident, my particular API viewer was generating W versions of APIs I > commonly use. I only caught it because the APIs were failing. > > Specifically I was using FindWindowEx. > > The declare for the W was exactly the same as the A, the difference being > the Alias. So why would it fail? I'm on XP SP3, which I assumed > supported > unicode apis. > > And when I say fail, the return value was 0, versus the desired window > handle. In your case, the W version was seeing an ANSI string and was looking for dual zero as a null terminator. So it probably interpreted it as Chinese string of unknown length :-) Personally, I prefer not using aliases with W functions, and use them as is(FindWindowExW). This makes the code compatible of whatever source code library I have and most code samples. With W functions, you always need to pass your strings as "ByVal StrPtr(s)", and "ByVal 0&" or vbNullString to pass null string.
From: Kevin Provance on 4 Aug 2010 15:31 "Tom Shelton" <tom_shelton(a)comcast.invalid> wrote in message news:i3c7it$f86$1(a)news.eternal-september.org... : : LOL... Then you and kev are probably the biggest trolls here. Trollish behavior right there, yet again dragging me into his sick obsessions where I have not even weighed in. If that isn't trollish behaviour, I don't know what is. Get over me Skelton. I can't and won't give you what you want. I'm sorry Rob left this group, but I will not fill that void he left in your life. I prefer women. <g>
From: Mike Williams on 4 Aug 2010 15:44 "Tom Shelton" <tom_shelton(a)comcast.invalid> wrote in message news:i3c7it$f86$1(a)news.eternal-september.org... >>After serious thinking Mike Williams wrote : >> No. That is not a requirement. Trolls are happy to troll >> whether they started the thread or not. > > LOL... Then you and kev are probably the biggest trolls here. Well that conclusion you have just drawn does not even make sense. No sense at all. It is not a conclusion that can logically be drawn from the statement you have drawn it from. It is a nonsensical conclusion. However, nonsense seems to be the stock in trade of dotnet trolls such as yourself, so it is not unexpected. Mike
From: Satchmo on 10 Aug 2010 11:16 Nobody wrote: > Personally, I prefer not using aliases with W functions, and use them as > is(FindWindowExW). This makes the code compatible of whatever source code > library I have and most code samples. But, wouldn't this cause an error if the code is executed in a Win95/98/Me machine? Because these systems do not support Unicode (W), but ANSI (A) functions. What I have been doing lately is checking for the high-order bit from the GetVersion() function. Only Windows NT, 2000, and above have this bit set to 0. I use that to determine whether I call the "A" or the "W" version. Of course that is to write code that is compatible with old Windows (95/98/Me). Although, I'm wondering if all that is worth the trouble, since I personally do not know anyone who still uses those old OSs. > With W functions, you always need to > pass your strings as "ByVal StrPtr(s)", and "ByVal 0&" or vbNullString to > pass null string. That's what I've been doing lately and it has always worked, but that seems to apply only to "W" functions that have those parameters as inputs. What do we do for those string parameters that are outputs? Thanks! -Satchmo
From: Nobody on 10 Aug 2010 12:03
"Satchmo" <don.tspa.m(a)dontdo.spam.not> wrote in message news:i3rqgc$p7s$1(a)news.eternal-september.org... > Nobody wrote: > >> Personally, I prefer not using aliases with W functions, and use them as >> is(FindWindowExW). This makes the code compatible of whatever source code >> library I have and most code samples. > > But, wouldn't this cause an error if the code is executed in a Win95/98/Me > machine? Because these systems do not support Unicode (W), but ANSI (A) > functions. Yes, but you need to check the OS version before using a function that came after Windows 95, or the minimum OS that you are trying to support. VB6 and all its OCX's require Windows 95 minimum, so if you use a function in later OS, try to document the minimum OS to use, perhaps in top of the source file that it appears in, or in project documentation. > What I have been doing lately is checking for the high-order bit from the > GetVersion() function. Only Windows NT, 2000, and above have this bit set > to 0. I use that to determine whether I call the "A" or the "W" version. > Of course that is to write code that is compatible with old Windows > (95/98/Me). Although, I'm wondering if all that is worth the trouble, > since I personally do not know anyone who still uses those old OSs. I think you can use the "Microsoft Layer for Unicode", but for each function that it supports, you have to replace the DLL name in the Declare from something like "Kernel32" to "UnicoWS.dll", and put "UnicoWS.dll" in the same folder as the EXE. It's actually easier to use this DLL in VB rather than C++. C++ developer have to do things to fool the linker so they can use that DLL instead of Kernel32.dll, User32.dll, etc. When using "UnicoWS.dll", you always call the W function with the same name in "UnicoWS.dll" and use "ByVal StrPtr(s)", or "ByVal 0&" to pass the parameters, and in turn, "UnicoWS.dll" would call the OS version of the function directly(In NT), or after doing the necessary Unicode to ANSI conversion when running under Windows 9x. >> With W functions, you always need to >> pass your strings as "ByVal StrPtr(s)", and "ByVal 0&" or vbNullString to >> pass null string. > > That's what I've been doing lately and it has always worked, but that > seems to apply only to "W" functions that have those parameters as inputs. > What do we do for those string parameters that are outputs? Same syntax for input and output. |