Delphi edit control created in Unicode instead of ANSI mode
Hi Frank, One of your theming patches ( http://www.winehq.org/hypermail/wine-cvs/2005/08/0313.html ) has caused a problem in many Delphi applications. The edit controls of Delphi applications are now created in Unicode mode. I hope you have an idea why this happens... Of course Delphi applications are ANSI and expect ANSI controls in their windows. If you believe that this is a real problem, you won't need to read the rest of this email :-) Because the Delphi edit controls are now in Unicode mode, the messages sent to them have to be translated from ANSI to Unicode and back. When a program reads the "Text" property of a TEdit control, Delphi sends a WM_GETTEXTLENGTH message. Wine doubles the return value when translating back from Unicode to ANSI because of double-byte character sets. (dlls/user/winproc.c) Now Delphi gets the doubled text size (should be no problem because WM_GETTEXTLENGTH only returns an upper limit of the text size, but Delphi doesn't regard this fact). Because Delphi does NOT use zero-terminated strings, Delphi will return a string that has twice the size of the text in the edit control and contains a '\0' character. If the application then concatenates this string with another string and passes the result to a Windows API function, the API function will only see the first string because of the '\0' character. I've discovered the problem because installers created by InnoSetup ( http://www.innosetup.com/ ) are now failing. You may use my simple Delphi demo program to test the bug: http://www.michael-kaufmann.ch/WINE/DelphiEdit.zip Regards Michael
On 04.09.2005 16:47, Michael Kaufmann wrote:
Hi Frank,
One of your theming patches ( http://www.winehq.org/hypermail/wine-cvs/2005/08/0313.html ) has caused a problem in many Delphi applications. The edit controls of Delphi applications are now created in Unicode mode. I hope you have an idea why this happens... Of course Delphi applications are ANSI and expect ANSI controls in their windows.
I know.
Because the Delphi edit controls are now in Unicode mode, the messages sent to them have to be translated from ANSI to Unicode and back. When a program reads the "Text" property of a TEdit control, Delphi sends a WM_GETTEXTLENGTH message. Wine doubles the return value when translating back from Unicode to ANSI because of double-byte character sets. (dlls/user/winproc.c)
Windows (2k+ at least) in this case actually also sends a Unicode WM_GETTEXT in this case and determines the true ANSI length from the Unicode string. Wine should (IMO) be fixed to do the same. Try this patch: http://www.winehq.org/pipermail/wine-patches/2005-August/020285.html Unfortunately, it is as-is not CVS-worthy... -f.r.
Hi, Does Windows XP use Unicode controls too if theming is on?
Because the Delphi edit controls are now in Unicode mode, the messages sent to them have to be translated from ANSI to Unicode and back. When a program reads the "Text" property of a TEdit control, Delphi sends a WM_GETTEXTLENGTH message. Wine doubles the return value when translating back from Unicode to ANSI because of double-byte character sets. (dlls/user/winproc.c)
Windows (2k+ at least) in this case actually also sends a Unicode WM_GETTEXT in this case and determines the true ANSI length from the Unicode string. Wine should (IMO) be fixed to do the same.
I can confirm this. Windows 2000 does not truncate any text or return doubled text lengths (even if it could according to the MSDN docs). We need to improve Wine's automatic message translation a lot! Some examples of A->W message translations: WM_GETTEXTLENGTH: Windows sends WM_GETTEXTLENGTH and WM_GETTEXT LB_GETTEXTLEN: LB_GETTEXTLEN, LB_GETTEXT CB_GETLBTEXTLEN: CB_GETLBTEXTLEN, CB_GETLBTEXT LB_GETTEXT: LB_GETTEXTLEN, LB_GETTEXT, LB_GETTEXT CB_GETLBTEXT: CB_GETLBTEXTLEN, CB_GETLBTEXT, CB_GETLBTEXT
Try this patch: http://www.winehq.org/pipermail/wine-patches/2005-August/020285.html Unfortunately, it is as-is not CVS-worthy...
I think you could use SendMessageW instead of calling the window proc directly. But apart from that, why is the patch not CVS-worthy? Regards Michael
On 05.09.2005 11:23, Michael Kaufmann wrote:
I think you could use SendMessageW instead of calling the window proc directly.
Yeah... since UnmapMsg32ATo32W is used for both in-process and inter-process communications, just using SendMessageW() is more correct and less hassle than messing with window procs directly.
But apart from that, why is the patch not CVS-worthy?
Due how the WM_GETTEXT is "dispatched" (ie calling the proc) - but that would be solved with SendMessageW(). -f.r.
But apart from that, why is the patch not CVS-worthy?
Due how the WM_GETTEXT is "dispatched" (ie calling the proc) - but that would be solved with SendMessageW().
I've found another problem: Reading the window proc address with GetWindowLong won't work for subclassed windows. We need to pass the window proc as a parameter to UnmapMsg32ATo32W (and probably also to other mapping functions). Maybe it's even better to use CallWindowProcW instead of SendMessageW. Regards Michael
On 05.09.2005 14:49, Michael Kaufmann wrote:
I've found another problem: Reading the window proc address with GetWindowLong won't work for subclassed windows. We need to pass the window proc as a parameter to UnmapMsg32ATo32W (and probably also to other mapping functions).
Maybe it's even better to use CallWindowProcW instead of SendMessageW.
Note that UnmapMsg32ATo32W() is also used for certain interprocess messages - there, a window function for the receiver window is (I think) not readily available. SendMessageW() would also take care of the IP message stuff... -f.r.
participants (2)
-
Frank Richter -
Michael Kaufmann