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