Prev: System Timer Callback?
Next: Any thoughts? Application error .data not place into memory because of an I/O error
From: Kevin Provance on 3 Aug 2010 16:56
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.
From: Bob Butler on 3 Aug 2010 16:58

"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.
>

Most likely because VB converted the Unicode string before calling the
function so the buffer it got was essentially garbage. You can call the
unicode versions but you have to either pass a byte array or use StrPtr or
some such method to side-step the default conversions.




From: Tom Shelton on 3 Aug 2010 17:08
Kevin Provance pretended :
> 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.

Well duh... if it was exactly the same as the A version then it was
wrong. If you are going to use the unicode version, declare the
lpszClass and lpszWindow parameters as Longs and use StrPtr to pass the
address of the string variables... Alternately, use a typelibe declared
version.

--
Tom Shelton


From: Tom Shelton on 3 Aug 2010 17:21
Kevin Provance pretended :
> 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.

And for some code...

Option Explicit

Private Declare Function FindWindowEx Lib "user32" Alias
"FindWindowExW" ( _
ByVal hwndParent As Long, _
ByVal hwndChildAfter As Long, _
ByVal lpszClass As Long, _
ByVal lpszWindow As Long) As Long



Private Sub Command1_Click()
Dim calc As String
calc = "Calculator"
MsgBox FindWindowEx(0, 0, 0, StrPtr(calc))
End Sub

--
Tom Shelton


From: Mike Williams on 3 Aug 2010 17:42
"Tom Shelton" <tom_shelton(a)comcast.invalid> wrote in message
news:i3a0gl$gqs$1(a)news.eternal-september.org...

> Well duh... if it was exactly the same as the A version
> then it was wrong. If you are going to use the unicode
> version, declare the lpszClass and lpszWindow parameters
> as Longs and use StrPtr to pass the address of the string
> variables... Alternately, use a typelibe declared version.

Alternately? Why would he want to keep swapping between the two different
methods? Why not simply use StrPtr or alternatively use a typlelib version?
Surely that would make more sense than to keep swapping around?

Mike


 |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: System Timer Callback?
Next: Any thoughts? Application error .data not place into memory because of an I/O error