"Phil Krylov" <[EMAIL PROTECTED]> wrote:
> Still it is not the best. Now, WM_CHARs posted by PostMessageA and
> dispatched using GetMessageA work well (are converted back and forth). But
> when the message loop uses GetMessageW, these WM_CHARs come to the window
> procedure as 4-byte "garbage" (WC
On Tue, 26 Jul 2005 21:26:29 +0900
"Dmitry Timoshkov" <[EMAIL PROTECTED]> wrote:
> "Phil Krylov" <[EMAIL PROTECTED]> wrote:
>
> > Oh sorry. For some reason I thought that HIWORD(wParam) is used for some
> > other data. Here is a new patch, is it ok?
>
> Looks good to me, let's see if Alexandre l
On Fri, 5 Aug 2005 13:22, Dmitry Timoshkov wrote:
> I very carefully have read your mail, the code, and the results you have
> got. Did you try to remove SetCPGlobal calls and see whether it actually
> changes anything?
Obviously you didn't, because if you did you'd realise that each program
per
"Troy Rollo" <[EMAIL PROTECTED]> wrote:
> > I skipped everything else since the tests apparently do not run on a proper
> > (or rather expected) locale, and the results basically show what you would
> > get on an english locale without SetCPGlobal hacks.
>
> You clearly neither read my message ve
On Fri, 5 Aug 2005 12:59, Dmitry Timoshkov wrote:
> I skipped everything else since the tests apparently do not run on a proper
> (or rather expected) locale, and the results basically show what you would
> get on an english locale without SetCPGlobal hacks.
You clearly neither read my message ver
"Troy Rollo" <[EMAIL PROTECTED]> wrote:
> I have just finished running a series of tests using the attached programs -
> msgchar, msgchar2 and msgchar3.
>
> * The short version:
>
> WM_CHAR messages are delivered "immediately" whether sent by SendMessage or
> PostMessage.
Actually not immedia
Troy Rollo wrote:
On Wednesday 27 July 2005 18:40, Dmitry Timoshkov wrote:
I also disassembled
kernel32.dll to see how it populated CP_ACP (if I recall correctly it
populated it from a registry key under either HKEY_CURRENT_CONFIG or
HKEY_LOCAL_MACHINE, so perhaps a change in the r
Troy Rollo <[EMAIL PROTECTED]> writes:
> On the other hand SendMessageA of any character to an A window procedure
> (regardless of any DBCS rules that might apply) ought to pass the character
> through immediately.
>
> This means that ideally, if the window is not a unicode window, then there
On Wednesday 27 July 2005 19:22, Filip Navara wrote:
> Actually it affects the CP_THREAD_ACP code page, but not CP_ACP.
Interesting. I wasn't previously aware of this. It isn't used anywhere in
Wine (it's returned, but nothing ever calls a routine with CP_THREAD_ACP). I
suspect not a whole lot
On Wednesday 27 July 2005 18:40, Dmitry Timoshkov wrote:
>> > I also disassembled
> > kernel32.dll to see how it populated CP_ACP (if I recall correctly it
> > populated it from a registry key under either HKEY_CURRENT_CONFIG or
> > HKEY_LOCAL_MACHINE, so perhaps a change in the registry could caus
"Troy Rollo" <[EMAIL PROTECTED]> wrote:
> > Did you test specifically A->W conversion of the message data or something
> > else?
>
> I tested the CP_ACP conversions and the GetACP call.
Actually you didn't answer the question. GetACP() by itself shows nothing,
only actual API tests could show so
On Wednesday 27 July 2005 18:16, Dmitry Timoshkov wrote:
> Did you test specifically A->W conversion of the message data or something
> else?
I tested the CP_ACP conversions and the GetACP call. I also disassembled
kernel32.dll to see how it populated CP_ACP (if I recall correctly it
populated
"Troy Rollo" <[EMAIL PROTECTED]> wrote:
> Locale doesn't affect the A->W translation. I know that is counter-intuitive
> and it surprised me when I found out (and verified) this. The system dialogs
> where you can change these things tend to obscure this.
Did you test specifically A->W conversi
On Wed, 27 Jul 2005 15:28, Dmitry Timoshkov wrote:
> Take into account that threads can belong to different processes. Another
> thing that we may want to take into account (that needs a test though) is
> whether a thread locale affects the translation.
Locale doesn't affect the A->W translation.
"Troy Rollo" <[EMAIL PROTECTED]> wrote:
> Locales don't affect the ANSI code page - that is determined either at boot
> time or by the most recent call of the process to SetGlobalCP (NT only). I
> could write a test for this, but I won't have time to do it until about a
> week from now.
Take i
On Wed, 27 Jul 2005 13:20, Dmitry Timoshkov wrote:
> "Troy Rollo" <[EMAIL PROTECTED]> wrote:
> > This means that ideally, if the window is not a unicode window, then
> > there should be no A->W->A translation.
>
> What is the source and target threads are running in different locales?
> That's the
"Troy Rollo" <[EMAIL PROTECTED]> wrote:
> This means that ideally, if the window is not a unicode window, then there
> should be no A->W->A translation.
What is the source and target threads are running in different locales?
That's the point in conversion to unicode for the interthread PostMessa
On Tue, 26 Jul 2005 17:31, Dmitry Timoshkov wrote:
> > What about the character codes which can't be converted?
>
> A->W conversion doesn't have that problem
That is not necessarily true. A DBCS lead byte without a valid trail byte will
result in failure in an A->W conversion.
In fact translatin
"Phil Krylov" <[EMAIL PROTECTED]> wrote:
Oh sorry. For some reason I thought that HIWORD(wParam) is used for some
other data. Here is a new patch, is it ok?
Looks good to me, let's see if Alexandre likes it as well.
--
Dmitry.
Hi Dmitry,
On Tue, 26 Jul 2005 16:56:31 +0900
"Dmitry Timoshkov" <[EMAIL PROTECTED]> wrote:
> The key word is "the whole" wparam. So, there is no need to truncate it
> by using LOWORD.
Oh sorry. For some reason I thought that HIWORD(wParam) is used for some
other data. Here is a new patch, is it
"Phil Krylov" <[EMAIL PROTECTED]> wrote:
> > One solution is to translate the whole wparam.
>
> How do you see it? Example: I do a
>
> PostMessageA(hwndAnsi, WM_CHAR, 0xF301, 0);
>
> map_wparam_AtoW takes the "\x01\xF3" string, translates it to Unicode via
> CP_ACP (for CP1251, this would be p
On Tue, 26 Jul 2005 16:31:50 +0900
"Dmitry Timoshkov" <[EMAIL PROTECTED]> wrote:
> "Phil Krylov" <[EMAIL PROTECTED]> wrote:
>
> > > This patch is not correct. All messages which potentially go through
> > > wineserver
> > > should be posted/sent via unicode.
> >
> > OK, then how you would sugge
"Dmitry Timoshkov" <[EMAIL PROTECTED]> wrote:
> > What about the character codes which can't be converted?
>
> A->W conversion doesn't have that problem, A->W translation either if
Of course the last A->W should be read as W->A, i.e.:
"W->A translation either if ..."
--
Dmitry.
"Phil Krylov" <[EMAIL PROTECTED]> wrote:
> > This patch is not correct. All messages which potentially go through
> > wineserver
> > should be posted/sent via unicode.
>
> OK, then how you would suggest to solve the problem described in previous
> messages of this thread?
One solution is to tra
On Tue, 26 Jul 2005 16:04:22 +0900
"Dmitry Timoshkov" <[EMAIL PROTECTED]> wrote:
> This patch is not correct. All messages which potentially go through
> wineserver
> should be posted/sent via unicode.
OK, then how you would suggest to solve the problem described in previous
messages of this thr
"Phil Krylov" <[EMAIL PROTECTED]> wrote:
> Translate Unicode<->ANSI message wParams only when window type
> (ANSI/Unicode) does not match message handling function postfix
> (PeekMessageA/W etc.).
This patch is not correct. All messages which potentially go through wineserver
should be posted/sen
On Tue, 26 Jul 2005 10:15:58 +1000
Troy Rollo <[EMAIL PROTECTED]> wrote:
> If you call SendMessageW under native Windows the translation happens. If you
> call SendMessageA it does not. This is all exactly what I would expect.
>
> By my test, sending 0xf301 with SendMessageA gets 0xf301 on Windo
On Tue, 26 Jul 2005 09:29, Phil Krylov wrote:
> I could remove map_wparam_AtoW() and map_wparam_WtoA() from
> dlls/user/message.c, but probably somebody needs that translation. Does
> anybody have an idea of a better fix for that bug?
If you call SendMessageW under native Windows the translation
28 matches
Mail list logo
