Re: wined3d: Fix GLSL cnd instruction
On 05/04/07, Fabian Bieler [EMAIL PROTECTED] wrote: According to MSDN the cnd instruction should translate: dst = src0 0.5 ? src1 : src2; This matches the ARB implementation in wined3d and fixes the borders in civ4. Note: On nvidia hardware this patch breaks the outro of Half-Life 2 with dxlevel 80 and GLSL due to a driver bug. You should update the comment above the instruction as well then.
Re: [msi OLE automation] Re: msi patches info pls
Misha Koshelev [EMAIL PROTECTED] writes: As one is looking at the oleview output of the native IDL file, one starts a blank document and begins to make the wine IDL file. One defines all the appropriate interfaces, etc. using the UUID's, names, etc. from the native interface. All the function names and parameter types are declared the same, as well as function attributes, but I should use different names for the parameters and try to put the attributes in a different order (although if I understand correctly the order of these attributes comes from our oleview implementation and not from the interface per se so there shouldn't be any reason to change their order??). That would be fine, anything that is required by the interface can be the same, so that would mean essentially everything except parameter names and help strings. I don't think you need to change the order of attributes from what oleview shows. -- Alexandre Julliard [EMAIL PROTECTED]
Fedora packages, where are they?
Hi, the link on the wine-page to get the Fedora- wine packages points to nowhere. Could this be fixed? Furthermore, anyone know where i can get the wine-rpm for Fedora?
Re: Random X errors caused by recent cursor patch?
I was able to reproduce the badpixmap bug on peachtree 2006 right after
picking a company from the open company dialog. This patch seemed to fix
this (or atleast hide it from being as reproducible as it was). I had some
trouble applying it to current gitwine, but I typed it in manually and it
worked fine.
john
On 4/3/07, Huw Davies [EMAIL PROTECTED] wrote:
On Tue, Apr 03, 2007 at 08:26:59AM -0700, Dan Kegel wrote:
Looks like there's been a regression lately. I'm
getting errors like this
X Error of failed request: BadPixmap (invalid Pixmap parameter)
Major opcode of failed request: 54 (X_FreePixmap)
Resource id in failed request: 0x2a0006a
randomly, about every fourth time I run things that used to
work. A user on c.e.m.w.
http://groups.google.com/group/comp.emulators.ms-windows.wine/msg/1f41dbd21a129f5e
speculates that the recent cursors patch
introduced the regression.
The error doesn't happen often enough to make
a regression test easy, and I haven't tried myself yet.
Hi Dan,
Could you see if this helps? It looks like XRenderFreePicture
actually destroys the underlying pixmap, so we ended up freeing it
twice.
Thanks,
Huw.
--
Huw Davies
[EMAIL PROTECTED]
From 8a76cf26395043428c24851d675c219735bcf502 Mon Sep 17 00:00:00 2001
From: Huw Davies [EMAIL PROTECTED]
Date: Tue, 3 Apr 2007 17:12:32 +0100
Subject: winex11.drv: XRenderFreePicture destroys the underlying storage,
so don't free the pixmap.
To: wine-patches [EMAIL PROTECTED]
---
dlls/winex11.drv/xrender.c | 22 +-
1 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/dlls/winex11.drv/xrender.c b/dlls/winex11.drv/xrender.c
index e03540e..6b86c74 100644
--- a/dlls/winex11.drv/xrender.c
+++ b/dlls/winex11.drv/xrender.c
@@ -85,7 +85,6 @@ struct tagXRENDERINFO
intcache_index;
Picturepict;
Picturetile_pict;
-Pixmap tile_xpm;
COLORREF lastTextColor;
};
@@ -596,7 +595,6 @@ void X11DRV_XRender_UpdateDrawable(X11DRV_PDEVICE
*physDev)
if(physDev-xrender-pict)
{
TRACE(freeing pict = %lx dc = %p\n, physDev-xrender-pict,
physDev-hdc);
-XFlush(gdi_display);
pXRenderFreePicture(gdi_display, physDev-xrender-pict);
physDev-xrender-pict = 0;
}
@@ -605,11 +603,6 @@ void X11DRV_XRender_UpdateDrawable(X11DRV_PDEVICE
*physDev)
pXRenderFreePicture(gdi_display, physDev-xrender-tile_pict);
physDev-xrender-tile_pict = 0;
}
-if(physDev-xrender-tile_xpm)
-{
-XFreePixmap(gdi_display, physDev-xrender-tile_xpm);
-physDev-xrender-tile_xpm = 0;
-}
wine_tsx11_unlock();
@@ -1186,18 +1179,21 @@ BOOL X11DRV_XRender_ExtTextOut( X11DRV_PDEVICE
*physDev, INT x, INT y, UINT flag
if(X11DRV_XRender_Installed) {
/* Create a 1x1 pixmap to tile over the font mask */
-if(!physDev-xrender-tile_xpm) {
+if(!physDev-xrender-tile_pict) {
XRenderPictureAttributes pa;
+Pixmap xpm;
XRenderPictFormat *format = (physDev-depth == 1) ?
mono_format : screen_format;
wine_tsx11_lock();
- physDev-xrender-tile_xpm = XCreatePixmap(gdi_display,
- physDev-drawable,
- 1, 1,
- format-depth);
+
+/* The pixmap will be freed with XRenderFreePicture */
+xpm = XCreatePixmap(gdi_display,
+physDev-drawable,
+1, 1,
+format-depth);
pa.repeat = True;
physDev-xrender-tile_pict =
pXRenderCreatePicture(gdi_display,
-
physDev-xrender-tile_xpm,
+ xpm,
format,
CPRepeat,
pa);
wine_tsx11_unlock();
--
1.5.0.5
Re: [PATCH] kernel32: return copy of environment blockinGetEnvironmentStringsW
Peter Beutner [EMAIL PROTECTED] wrote:
Probably an exception handler should be added inside of RtlFreeHeap
instead.
hm, i vaguely remember reading here that it was prefered not to cover up
crashes produced by passing invalid pointers, unless absolutely necessary.
If the crash is caused by a NULL pointer then the fix is easy and doesn't
require using an exception handler, but it's not possible in this case.
And here we can fix that nicely in some other way.
See attached patch. Would that be acceptable as well?
diff --git a/dlls/kernel32/environ.c b/dlls/kernel32/environ.c
index 414ccbf..f7890cc 100644
--- a/dlls/kernel32/environ.c
+++ b/dlls/kernel32/environ.c
@@ -148,6 +148,10 @@ LPWSTR WINAPI GetEnvironmentStringsW(void)
*/
BOOL WINAPI FreeEnvironmentStringsA( LPSTR ptr )
{
+/* broken app passes ptr it got from GetEnvironmentStringsW */
+if(ptr == NtCurrentTeb()-Peb-ProcessParameters-Environment)
+return TRUE;
+
return HeapFree( GetProcessHeap(), 0, ptr );
}
Personally I think that adding an exception handler or probably just a more
strict consistency check inside of RtlFreeHeap should be better.
--
Dmitry.
Re: [RESEND] regedit: Convert from WCHAR size to maximum required TCHAR size.
Alexandre Julliard wrote: Byeong-Sik Jeon [EMAIL PROTECTED] writes: another soultion: * we can change the IDS_NEWKEY, IDS_NEWVALUE of resource file. * define the UNICODE but these sulution don't fix the regedit's bug. just bug hide... What we should do for regedit, and actually for all our programs, is to convert them to be explicitly Unicode throughout, and build them with #define WINE_NO_UNICODE_MACROS to enforce that there are no TCHARs anywhere. That would be a nice janitorial task... Ah!!! It's a great point. I checked TCHAR, UNICODE, WINE_NO_UNICODE_MACROS, __WINESRC__, ... in header files. Thank you. First step for regedit: regedit must to be build with UNICODE. And, regedit need many fix. Thanks to all...
Re: [RESEND] regedit: Convert from WCHAR size to maximum required TCHAR size.
Byeong-Sik Jeon wrote: Hi, MS-Windows's RegQueryKeyInfo function test result: 1. MSDN means TCHARS when it says 'character' for this function. == No. 2. why RegQueryInfoKey is returning a number that is too small == No. Currently Wine's RegQueryInfoKey set the right values. Sorry, but I think you are wrong. Every Windows function (except for CharNext and CharPrev) that mentions character actually means TCHARs. -- Rob Shearman
Re: comctl32: toolbar[1/4]: avoid using CopyImage as it doesn't work well when the DDBs are RGB565 (fixes bug #7905)
Mikolaj Zalewski [EMAIL PROTECTED] wrote: If the DDB format is RGB565, CopyImage uses an RGB555 intermediate DIB that leads to data loses. This may change the COLOR_BTNFACE pixels slightly and they won't be recognized as transparent anymore. As this bug is also present under Windows, I haven't changed CopyImage but wrote a new function that I hope works correctly. Since it clearly sounds like a CopyImage bug it would be more appropriate to fix CopyImage instead, Microsoft may do that at some point as well. -- Dmitry.
Re: [PATCH] kernel32: return copy of environment blockinGetEnvironmentStringsW
Alexandre Julliard schrieb:
Dmitry Timoshkov [EMAIL PROTECTED] writes:
Peter Beutner [EMAIL PROTECTED] wrote:
@@ -148,6 +148,10 @@ LPWSTR WINAPI GetEnvironmentStringsW(void)
*/
BOOL WINAPI FreeEnvironmentStringsA( LPSTR ptr )
{
+/* broken app passes ptr it got from GetEnvironmentStringsW */
+if(ptr == NtCurrentTeb()-Peb-ProcessParameters-Environment)
+return TRUE;
+
return HeapFree( GetProcessHeap(), 0, ptr );
}
Personally I think that adding an exception handler or probably just a more
strict consistency check inside of RtlFreeHeap should be better.
An exception handler is probably too slow, but yes RtlFreeHeap should
have noticed that this block isn't part of the heap. Try something
like this:
diff --git a/dlls/ntdll/heap.c b/dlls/ntdll/heap.c
index 80ddaf2..61b25db 100644
--- a/dlls/ntdll/heap.c
+++ b/dlls/ntdll/heap.c
@@ -395,7 +395,8 @@ static SUBHEAP *HEAP_FindSubHeap(
while (sub)
{
if (((const char *)ptr = (const char *)sub)
-((const char *)ptr (const char *)sub + sub-size)) return
(SUBHEAP*)sub;
+((const char *)ptr (const char *)sub + sub-size -
sizeof(ARENA_INUSE)))
+return (SUBHEAP *)sub;
sub = sub-next;
}
return NULL;
@@ -783,7 +784,7 @@ static ARENA_FREE *HEAP_FindFreeBlock( HEAP *heap, SIZE_T
size,
*
* Check that the pointer is inside the range possible for arenas.
*/
-static BOOL HEAP_IsValidArenaPtr( const HEAP *heap, const void *ptr )
+static BOOL HEAP_IsValidArenaPtr( const HEAP *heap, const ARENA_FREE *ptr )
{
int i;
const SUBHEAP *subheap = HEAP_FindSubHeap( heap, ptr );
@@ -1003,13 +1004,12 @@ static BOOL HEAP_IsRealArena( HEAP *heapPtr, /*
[in] ptr to the heap */
if (!(flags HEAP_NO_SERIALIZE))
RtlEnterCriticalSection( heapPtr-critSection );
-if (block)
+if (block) /* only check this single memory block */
{
-/* Only check this single memory block */
+const ARENA_INUSE *arena = (const ARENA_INUSE *)block - 1;
-if (!(subheap = HEAP_FindSubHeap( heapPtr, block )) ||
-((const char *)block (char *)subheap + subheap-headerSize
- + sizeof(ARENA_INUSE)))
+if (!(subheap = HEAP_FindSubHeap( heapPtr, arena )) ||
+((const char *)arena (char *)subheap + subheap-headerSize))
{
if (quiet == NOISY)
ERR(Heap %p: block %p is not inside heap\n, heapPtr, block
);
@@ -1017,7 +1017,7 @@ static BOOL HEAP_IsRealArena( HEAP *heapPtr, /* [in]
ptr to the heap */
WARN(Heap %p: block %p is not inside heap\n, heapPtr,
block );
ret = FALSE;
} else
-ret = HEAP_ValidateInUseArena( subheap, (const ARENA_INUSE
*)block - 1, quiet );
+ret = HEAP_ValidateInUseArena( subheap, arena, quiet );
if (!(flags HEAP_NO_SERIALIZE))
RtlLeaveCriticalSection( heapPtr-critSection );
Yes that works. It doesn't crash anymore. Thx for looking into this.
string comparison functions
Hi, Sorry for cross posting. I've already asked same question on wine-users list and only reply redirected me to devel list. What rules are used when Wine libraries compare Unicode strings? I need to know when ascii characters can match their approximate Unicode equivalents. For example: 'U+1D49 MODIFIER LETTER SMALL E' matches 'U+0065 LATIN SMALL LETTER E' on Wine. I am debugging IE javascript security issues. IE6 on Wine (Linux Debian) matches more Unicode equivalents than IE6 on Win98 and WinXP. If you need more information, I can provide sample html that works on Wine and does not work on Win98/XP. I am not C/C++ programmer. I only need to know which library provides mapping of unicode equivalents in string comparison functions. Is it standard C library? glibc 2.3.6 on Debian Etch. -- Tomas
Re: [RESEND] regedit: Convert from WCHAR size to maximum required TCHAR size.
On Thu, 2007-05-04 at 12:03 +0900, Byeong-Sik Jeon wrote: Hi, MS-Windows's RegQueryKeyInfo function test result: 1. MSDN means TCHARS when it says 'character' for this function. == No. 2. why RegQueryInfoKey is returning a number that is too small == No. Currently Wine's RegQueryInfoKey set the right values. Thank you. Wow!! I confess that I have not tested this. I think it is sufficiently counterintuitive that it would be useful if you could submit a test that would demonstrate it, e.g. put a non-SBCS string into the registry in Unicode, query and get it back out, demonstrating that the size returned is the number of lexical characters (plus 1 in Win95/98/me?). And if this is the case then your original fix is still incorrect; we would need to multiply the size not by sizeof(TCHAR) but by the maximum number of bytes required to hold a lexical character (which is presumably going to have to handle UTF-8). Bill
Re: Random X errors caused by recent cursor patch?
On 4/5/07, John Smith [EMAIL PROTECTED] wrote: This patch seemed to fix this (or atleast hide it from being as reproducible as it was). Hide it from being as reproducible? Are you still able to reproduce it at all, now? -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373from=power-email
Re: string comparison functions
Tomas Kuliavas [EMAIL PROTECTED] wrote: What rules are used when Wine libraries compare Unicode strings? I need to know when ascii characters can match their approximate Unicode equivalents. For example: 'U+1D49 MODIFIER LETTER SMALL E' matches 'U+0065 LATIN SMALL LETTER E' on Wine. WideCharToMultiByte translates a unicode string to a multibyte encoding using the specified code page, and then simple strcmp between the resulting string and e will do what you need. I am debugging IE javascript security issues. IE6 on Wine (Linux Debian) matches more Unicode equivalents than IE6 on Win98 and WinXP. If you need more information, I can provide sample html that works on Wine and does not work on Win98/XP. I am not C/C++ programmer. I only need to know which library provides mapping of unicode equivalents in string comparison functions. Is it standard C library? glibc 2.3.6 on Debian Etch. Wine uses tables auto-generated from the data provided by unicode.org, the files are in libs/wine directory. Since the data in Wine and Windows is from different sources there are quite a bit of differences in translations between unicode and code pages. -- Dmitry.
Re: comctl32: toolbar[1/4]: avoid using CopyImage as it doesn't work well when the DDBs are RGB565 (fixes bug #7905)
Since it clearly sounds like a CopyImage bug it would be more appropriate to fix CopyImage instead, Microsoft may do that at some point as well. I was a bit affraid that even Windows Vista has this bug so there might be apps depending on it. However it would be strange for some app to depend on it so if you think it's better to patch CopyImage I'll send a patch for it. Mikolaj Zalewski
Re: Fedora packages, where are they?
On Thu, Apr 05, 2007 at 08:01:01AM +, Louis Lenders wrote: Hi, the link on the wine-page to get the Fedora- wine packages points to nowhere. Could this be fixed? Furthermore, anyone know where i can get the wine-rpm for Fedora? It is in their Extras RPMs. Additionally in my buildservice repositories: http://software.opensuse.org/download/Emulators:/Wine/ Ciao, Marcus
Re: [RESEND] regedit: Convert from WCHAR size to maximum required TCHAR size.
Bill Medland wrote: I confess that I have not tested this. I think it is sufficiently counterintuitive that it would be useful if you could submit a test that would demonstrate it, e.g. put a non-SBCS string into the registry in Unicode, query and get it back out, demonstrating that the size returned is the number of lexical characters (plus 1 in Win95/98/me?). And if this is the case then your original fix is still incorrect; we would need to multiply the size not by sizeof(TCHAR) but by the maximum number of bytes required to hold a lexical character (which is presumably going to have to handle UTF-8). Hi, I cancel this patch. Please see the Alexandre Julliard's comments. The good solution of this problem is #define UNICODE. Thank you.
Re: [RESEND] regedit: Convert from WCHAR size to maximum required TCHAR size.
Robert Shearman wrote:
Byeong-Sik Jeon wrote:
Hi,
MS-Windows's RegQueryKeyInfo function test result:
1. MSDN means TCHARS when it says 'character' for this function.
== No.
2. why RegQueryInfoKey is returning a number that is too small
== No. Currently Wine's RegQueryInfoKey set the right values.
Sorry, but I think you are wrong. Every Windows function (except for
CharNext and CharPrev) that mentions character actually means TCHARs.
Hi,
This is different situation.
Please see the RegQueryInfoKey{A|W}, NtQueryKey, wineserver's reg source
code.
RegQueryInfoKey{A|W} can't process the string.
Thank you.
Re: Fedora packages, where are they?
On Thu, 5 Apr 2007 08:01:01 + (UTC) Louis Lenders [EMAIL PROTECTED] wrote: Hi, the link on the wine-page to get the Fedora- wine packages points to nowhere. Could this be fixed? Furthermore, anyone know where i can get the wine-rpm for Fedora? Sorry that I am a bit behind with the Fedora Extras Packages but there are some bugs I want to clean up before upgrading. Should happen in the next days so. - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB [EMAIL PROTECTED] | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043| mail preferred signature.asc Description: PGP signature
Re: [RESEND] regedit: Convert from WCHAR size to maximum required TCHAR size.
Robert Shearman wrote: Byeong-Sik Jeon wrote: Hi, MS-Windows's RegQueryKeyInfo function test result: 1. MSDN means TCHARS when it says 'character' for this function. == No. 2. why RegQueryInfoKey is returning a number that is too small == No. Currently Wine's RegQueryInfoKey set the right values. Sorry, but I think you are wrong. Every Windows function (except for CharNext and CharPrev) that mentions character actually means TCHARs. Thank you. you are right. 1. MSDN means TCHARS when it says 'in characters' == Yes. I'm sorry to everyboby. 2. MSDN means TCHARS when it says 'in characters' for RegQueryInfoKey's lpcMaxValueNameLen parameter. == No, I think this is missed MSDN documentation. RegQueryInfoKey don't process the 'registry valuename string'
Why double translation on keydown?
Hi all, The current code for keyboard translation goes something like this, if I understood it correctly: * An X11 event arrives with the physical keycode for the key pressed. * Said code is translated into a VKey based on the current keyboard (fair enough) * Keycode is translated into a, well, keycode for Windows. 99% of the cases this is the same one, as it's the same PC keyboard as ever. * The vkey and translated keycode are sent as WM_KEYDOWN or WM_SYSKEYDOWN events. * In all probability, the process calls TranslateMessage * TranslateMessage calls (indirectly) X11DRV_ToUnicodeEx * X11DRV_ToUnicodeEx takes the virtual key, looks it up (using a for loop) in the same table consulted before to find out what the original X11 keycode was. * That vkey is passed, after some manipulation, to XKeysymToKeycode to produce a keycode * Said keycode is passed to XLookupString to get an actual key for it This process seems, to me, overly long and inefficient. It requires building fairly complex lookup tables for both vkey and Windows keycode. I fail to see what is gained. Why not use the following process instead: * An X11 event arrives * Use the native keycode as the keycode. * Translate the vkey as before. * Send WM_(SYS)KEYDOWN as before * In X11DRV_ToUnicodeEx: * Use the keycode to lookup with key using XLookupString I fail to see why the forward and backwards translation is good for. Explanation? Shachar
Re: notepad: Fix the wrong '' operator use.
Byeong-Sik Jeon wrote: FormatMessage( FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM, NULL, error, 0, -(LPTSTR) lpMsgBuf, 0, NULL); +lpMsgBuf, 0, NULL); This patch is wrong. When FORMAT_MESSAGE_ALLOCATE_BUFFER is used FormatMessage() takes a pointer to a pointer.
Re: notepad: Fix the wrong '' operator use.
Felix Nawothnig wrote: Byeong-Sik Jeon wrote: FormatMessage( FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM, NULL, error, 0, -(LPTSTR) lpMsgBuf, 0, NULL); +lpMsgBuf, 0, NULL); This patch is wrong. When FORMAT_MESSAGE_ALLOCATE_BUFFER is used FormatMessage() takes a pointer to a pointer. Oops!!! I'm sorry. I was foolish :-(
Re: [2/2] wined3d: Use GL_EXT_framebuffer_blit for framebuffer-texture blits in BltOverride
On 05/04/07, Fabian Bieler [EMAIL PROTECTED] wrote: From b369a9384beb831dfae6460418d861f30a9cef3e Mon Sep 17 00:00:00 2001 From: Fabian Bieler [EMAIL PROTECTED] Date: Thu, 5 Apr 2007 21:52:44 +0200 Subject: [PATCH] wined3d: Use GL_EXT_framebuffer_blit for framebuffer-texture blits in BltOverride This doesn't work for the general case, ie blitting any surface to another surface. I've got a more complete patch for this in my tree.
Re: Why double translation on keydown?
Shachar Shemesh [EMAIL PROTECTED] wrote: This process seems, to me, overly long and inefficient. It requires building fairly complex lookup tables for both vkey and Windows keycode. I fail to see what is gained. Why not use the following process instead: * An X11 event arrives * Use the native keycode as the keycode. * Translate the vkey as before. * Send WM_(SYS)KEYDOWN as before * In X11DRV_ToUnicodeEx: * Use the keycode to lookup with key using XLookupString X11DRV_ToUnicodeEx is a backend of the Win32 API ToUnicodeEx and it takes a virtual key code. I.e. ToUnicodeEx takes a predefined input and should return data very closely resembling what Windows does. -- Dmitry.
Re: notepad: Use the more explicitly UNICODE character type.
Byeong-Sik Jeon [EMAIL PROTECTED] wrote: Changelog: Use the more explicitly UNICODE character type. Then you have to simultaneously explicitly start using unicode Win32 APIs. I'd suggest you to start with the application that presumably doesn't work properly in multibyte locales and which you already started to look at - regedit, and leave notepad alone until there are real problems discovered. -- Dmitry.
Using signals to turn logging on and off
I tried the patch in the wiki to control logging with f12, but it wasn't quite satisfying, because only one process has the keyboard, so you can only turn one process' logging on and off. This isn't so great if the process you're interested in never has the keyboard. (Like com servers started up during installers.) So I played around with using unix signals instead. And rather than having a signal toggle the enable status, I used one signal for enable and another for disable. The feature is only turned on if you set the WINEDEBUGSIG environment var. Problem is, all I can do is turn logging off; turning it on doesn't work for some reason. Feh. Can somebody spot what I did wrong? It's at http://kegel.com/wine/debugsig.patch It was monkey-see-monkey-do code, to some extent, so I wouldn't be surprised if there's an obvious problem. Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Why double translation on keydown?
Dmitry Timoshkov wrote: X11DRV_ToUnicodeEx is a backend of the Win32 API ToUnicodeEx and it takes a virtual key code. I.e. ToUnicodeEx takes a predefined input and should return data very closely resembling what Windows does. Ok, then maybe we should have TranslateMessage not call that, and use something else instead? This is particularly prominent from this sentence in the ToUnicodeEx documentation (http://msdn2.microsoft.com/en-us/library/ms646322.aspx): The parameters supplied to the ToUnicodeEx function might not be sufficient to translate the virtual-key code because a previous dead key is stored in the keyboard layout. Maybe I don't understand the code well enough, but it seems to me that we report on the dead-key press, but not translate the following character. Is that correct? Shachar
Re: Why double translation on keydown?
Shachar Shemesh [EMAIL PROTECTED] wrote: X11DRV_ToUnicodeEx is a backend of the Win32 API ToUnicodeEx and it takes a virtual key code. I.e. ToUnicodeEx takes a predefined input and should return data very closely resembling what Windows does. Ok, then maybe we should have TranslateMessage not call that, and use something else instead? For instance what? Apparently Windows does use ToUnicodeEx internally in TranslateMessage, if you are planning to change that you have to make sure that current semantics doesn't change. In any case nothing prevents the apps to call ToUnicodeEx on their own while handling WM_KEY messages. This is particularly prominent from this sentence in the ToUnicodeEx documentation (http://msdn2.microsoft.com/en-us/library/ms646322.aspx): The parameters supplied to the ToUnicodeEx function might not be sufficient to translate the virtual-key code because a previous dead key is stored in the keyboard layout. Maybe I don't understand the code well enough, but it seems to me that we report on the dead-key press, but not translate the following character. Is that correct? winex11.drv never reports dead keys to the applications, dead keys are handled internally. -- Dmitry.
