Re: Get rid of W->A calls

[hatky]

> Let us know if you need any help.

Just to be sure I got it right, I moved the 
DirectDrawEnumerateExA stuff into
DirectDrawEnumerateExW since there is nothing ascii or
unicode specific in it I think it's ok on it's own now
in DirectDrawEnumerateExA I have these variables:

LPDDENUMCALLBACKEXA lpCallback
pointer to a callback function, the
DirectDrawEnumerateExW get a LPDDENUMCALLBACKEXW (not
match a suprise I guess) 
so do I need to convert it? 
just cast it as (DirectDrawEnumerateExW)?
something else?

LPVOID lpContext
Address of an application-defined context to be passed
to the enumeration callback function each time that it
is called
when they called from W -> A they did:

DirectDrawEnumerateProcData epd;
epd.lpCallback = (LPVOID) lpCallback;
epd.lpContext = lpContext;

and sent in as:
(LPVOID) &epd

Should it just be sent as is?

DWORD dwFlags 
I assume it should be passed as is, for some reason
the opposite call sent 0

Hatky.

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Get rid of W->A calls

[Dimitrie O. Paun]

On Fri, 5 Sep 2003, hatky wrote:
> > Let us know if you need any help.
>
> Just to be sure I got it right, I moved the 
> DirectDrawEnumerateExA stuff into
> DirectDrawEnumerateExW since there is nothing ascii or
> unicode specific in it I think it's ok on it's own now
> in DirectDrawEnumerateExA I have these variables:

You've picked a wrong one to do -- this one is a bit
trickier, because of the callback, and because we
store information internally as ASCII. Do another one
instead, leave this one for now.

Get rid of W->A calls

[hatky]

> You've picked a wrong one to do -- this one is a bit
> trickier, because of the callback, and because we
> store information internally as ASCII. Do another
> one
> instead, leave this one for now.

I am getting the felling this will repeat, why not
just teach me?

Hatky.

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Get rid of W->A calls

[Dimitrie O. Paun]

On Fri, 5 Sep 2003, hatky wrote:
> I am getting the felling this will repeat, why not
> just teach me?

Because I'm a lousy teacher :) Also, it is more productive
to start with simpler examples, so you also do part of the
learning from experience.

Get rid of W->A calls

[hatky]

> Because I'm a lousy teacher :) Also, it is more
> productive
> to start with simpler examples, so you also do part
> of the
> learning from experience.

grr.....

Ok, lets take another one, winhelp.c WinHelpW->A

I take whatever is in WinHelpA and move it into
WinHelpW with the fallowing changes:

-BOOL WINAPI WinHelpW( HWND hWnd, LPCWSTR helpFile,
UINT command, ULONG_PTR dwData )
+BOOL WINAPI WinHelpW( HWND hWnd, LPCWSTR helpFile,
UINT wcommand, ULONG_PTR dwData )

why did they call them wcommand in WinHelpA and
command in WinHelpW ?? (msdn calls them uCommand but
the code uses wcommand...)

-hDest = FindWindowA("MS_WINHELP", NULL);
+hDest = FindWindowW("MS_WINHELP", NULL);

-        if (!(hDest = FindWindowA("MS_WINHELP",
NULL)))
+        if (!(hDest = FindWindowW("MS_WINHELP",
NULL)))

-    return SendMessageA(hDest, WM_COPYDATA,
(WPARAM)hWnd, (LPARAM)&cds);
+    return SendMessageW(hDest, WM_COPYDATA,
(WPARAM)hWnd, (LPARAM)&cds);

and now I need to put a call in WinHelpA to WinHelpW
after converting 
LPCSTR lpHelpFile
?

variables are
    HWND hWndMain,
-- window handler
    LPCTSTR lpszHelp, --in A
    LPCWSTR lpszHelp, --in W
-- file path + posible topic
    UINT uCommand,
-- Type of help requested. 
    ULONG_PTR dwData
--Additional data. either pointers or 0

Hatky.

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Get rid of W->A calls

[Dimitrie O. Paun]

On Fri, 5 Sep 2003, hatky wrote:
> Ok, lets take another one, winhelp.c WinHelpW->A

OK, I have to warn you I haven't looked at the code,
so I'll just go by what I see in this email.
> I take whatever is in WinHelpA and move it into
> WinHelpW with the fallowing changes:
>
> -BOOL WINAPI WinHelpW( HWND hWnd, LPCWSTR helpFile,
> UINT command, ULONG_PTR dwData )
> +BOOL WINAPI WinHelpW( HWND hWnd, LPCWSTR helpFile,
> UINT wcommand, ULONG_PTR dwData )
>
> why did they call them wcommand in WinHelpA and
> command in WinHelpW ?? (msdn calls them uCommand but
> the code uses wcommand...)

I don't see why, it should be named the same in
both versions if it's encoding independent.
> -hDest = FindWindowA("MS_WINHELP", NULL);
> +hDest = FindWindowW("MS_WINHELP", NULL);

You can't to that directly, as we don't support
Unicode literals. You need to do that by hand:

WCHAR clsName[] = { 'M', 'S', '_', 'W', 'I', 'N', 'H', 'E', 'L', 'P', 0 };
    hDest = FindWindowW(clsName, NULL);
> -
>    if (!(hDest = FindWindowA("MS_WINHELP",
>
> NULL)))
> -
>    if (!(hDest = FindWindowW("MS_WINHELP",
>
> NULL)))

Ditto, just do
        if (!(hDest = FindWindowW(clsName, NULL);
> - return SendMessageA(hDest, WM_COPYDATA,
>
> (WPARAM)hWnd, (LPARAM)&cds);
> - return SendMessageW(hDest, WM_COPYDATA,
>
> (WPARAM)hWnd, (LPARAM)&cds);

OK.
> and now I need to put a call in WinHelpA to WinHelpW
> after converting 
> LPCSTR lpHelpFile
> ?

Yes.

Get rid of W->A calls

[hatky]

> OK, I have to warn you I haven't looked at the code,
> so I'll just go by what I see in this email.

That's what I was expecting so I checked it carfully
and copied what seems to mater + I know that if/when I
will submit the patch it will be checked more...
> > why did they call them wcommand in WinHelpA and
> > command in WinHelpW ?? (msdn calls them uCommand
>
> but
> > the code uses wcommand...)
>
> I don't see why, it should be named the same in
> both versions if it's encoding independent.

So should I make it uCommand as in msdn or leave it
wcommand?
> You can't to that directly, as we don't support
> Unicode literals. You need to do that by hand:
> WCHAR clsName[] = { 'M', 'S', '_', 'W', 'I',
>
> 'N', 'H', 'E', 'L', 'P', 0 };
>     hDest = FindWindowW(clsName, NULL);

Ok, I get this but why don't we support Unicode
literals? seems like it makes the code a mess and
there will be another task to clean that up
sometime...
> Ditto, just do
>         if (!(hDest = FindWindowW(clsName, NULL);

No problem.
> OK.

I got 1 right :) yepi.
> > and now I need to put a call in WinHelpA to
>
> WinHelpW
> > after converting 
> > LPCSTR lpHelpFile
> > ?
>
> Yes.

And the code goes like this:?
    INT len;
    LPSTR file;
    BOOL ret = FALSE;

if (!lphelpFile) return WinHelpW( hWnd, NULL,
command, dwData );

len = MultiByteToWideChar( CP_ACP, 0, helpFile,
-1, NULL, 0, NULL, NULL );
    if ((file = HeapAlloc( GetProcessHeap(), 0, len
)))
    {
        MultiByteToWideChar( CP_ACP, 0, helpFile, -1,
file, len, NULL, NULL );
        ret = WinHelpW( hWnd, file, command, dwData );
        HeapFree( GetProcessHeap(), 0, file );
    }
    return ret;

Wait, if I change lpHelpFile to Unicode then I should
change also:

+#include "wine/unicode.h"
or should it be
+#include <unicode.h>?

-        nlen = strlen(lpHelpFile) + 1;
+        nlen = strlenW(lpHelpFile) + 1;

-        strcpy(((char*)lpwh) + sizeof(WINHELP),
lpHelpFile);
+        strcpyW(((char*)lpwh) + sizeof(WINHELP),
lpHelpFile);

and I assume 
    if (lpHelpFile)
is still ok, right?

hatky.

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Get rid of W->A calls

[Dimitrie O. Paun]

On Fri, 5 Sep 2003, hatky wrote:
> So should I make it uCommand as in msdn or leave it
> wcommand?

I'd change both to uCommand as per msdn.
> > WCHAR clsName[] = { 'M', 'S', '_', 'W', 'I',
> >
> > 'N', 'H', 'E', 'L', 'P', 0 };
> >     hDest = FindWindowW(clsName, NULL);

Don't forget Robert's advice, use:
    static const WCHAR clsName[] ...
> Ok, I get this but why don't we support Unicode
> literals? seems like it makes the code a mess and
> there will be another task to clean that up
> sometime...

Yes, it is inconvenient, but some Unix compilers
don't support 16-bit Unicode literals, so we're stuck
with that for the moment.
> And the code goes like this:?
>     INT len;
>     LPSTR file;

^
      LPWSTR
> BOOL ret = FALSE;
>
> if (!lphelpFile) return WinHelpW( hWnd, NULL,
>
> command, dwData );
> len = MultiByteToWideChar( CP_ACP, 0, helpFile,
>
> -1, NULL, 0, NULL, NULL );
>     if ((file = HeapAlloc( GetProcessHeap(), 0, len
> )))
>     {
>         MultiByteToWideChar( CP_ACP, 0, helpFile, -1,
> file, len, NULL, NULL );
>         ret = WinHelpW( hWnd, file, command, dwData );
>         HeapFree( GetProcessHeap(), 0, file );
>     }
>     return ret;
>
> Wait, if I change lpHelpFile to Unicode then I should
> change also:
>
> +#include "wine/unicode.h"

This is good.
> or should it be
> +#include <unicode.h>?

This will not work.
> -
>    nlen = strlen(lpHelpFile) + 1;
> -
>    nlen = strlenW(lpHelpFile) + 1;

Yes...
> -
>    strcpy(((char*)lpwh) + sizeof(WINHELP),
>
> lpHelpFile);
> -
>    strcpyW(((char*)lpwh) + sizeof(WINHELP),
>
> lpHelpFile);

Yes.
> and I assume 
>     if (lpHelpFile)
> is still ok, right?

Right.

Get rid of W->A calls

[hatky]

Ok, one last line:

strcpy(((char*)lpwh) + sizeof(WINHELP),
lpHelpFile);

I do not realy get what it means.... (but I know it
shouldn't be this way becouse I get a warning:

passing arg 1 of `strcpy' from incompatible pointer
type

lpHelpFile is a LPCWSTR unicode variable and 
lpwh is of type WINHELP*
where WINHELP

typedef struct
{
    WORD size;
    WORD command;
    LONG data;
    LONG reserved;
    WORD ofsFilename;
    WORD ofsData;
} WINHELP;

Hatky.

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Get rid of W->A calls

[hatky]

> passing arg 1 of `strcpy' from incompatible pointer
> type

Sorry I ment trying strcpyW gets 
../../windows/winhelp.c:167: warning: passing arg 1 of
`strcpyW' from incompatible pointer type

and strcpy gets
../../windows/winhelp.c:167: warning: passing arg 2 of
`strcpy' from incompatible pointer type

I think I need a W to A copy or some kind of
convert...

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Get rid of W->A calls

[Dimitrie O. Paun]

On Fri, 5 Sep 2003, hatky wrote:
> Ok, one last line:
>     strcpy(((char*)lpwh) + sizeof(WINHELP),
>
> lpHelpFile);

I don't have time now to look at the code, but
this is rather strange, I think you want this:

strcpyW((LPWSTR)(((char*)lpwh) + sizeof(WINHELP), lpHelpFile);

Get rid of W->A calls

[Eric Pouech]

hatky wrote:
> Ok, one last line:
>     strcpy(((char*)lpwh) + sizeof(WINHELP),
>
> lpHelpFile);
>
> I do not realy get what it means.... (but I know it
> shouldn't be this way becouse I get a warning:
>
> passing arg 1 of `strcpy' from incompatible pointer
> type
>
> lpHelpFile is a LPCWSTR unicode variable and 
> lpwh is of type WINHELP*
> where WINHELP
>
> typedef struct
> {
>     WORD size;
>     WORD command;
>     LONG data;
>     LONG reserved;
>     WORD ofsFilename;
>     WORD ofsData;
> } WINHELP;

note also that the content of data (and its type) depends on the command 
parameter, and in some cases data is a string.
But, I don't know if WinHelpW expects unicode or ansi strings in that 
case... this should be tested on windows before
A+