[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>On Thu, 16 Nov 2000, Dmitry Timoshkov wrote:
>
>> Hello.
>>
>> Changelog:
>> Dmitry Timoshkov <[EMAIL PROTECTED]>
>> Always generate unicode CHAR messages.
>>
>Good day!
>
>This broke my mail app. I have been running with it 'til now, so I
>guess you could say it isn't very broke, but if I have to change my
>phone number I am SOL. It won't accept input in one text-entry item
>(?) of a dailog. I have before and after +message,+key,+text logs, but
>even after removing the beginning stuff and grepping out the
>GetTextExtentPoint they are still to big to mail, unless you don't mind
>gzipped and split.
>
>If I have missed a correction or some later patch that sets it right,
>please point it out. I just pick from wine-patches and hope for the
>best.
Probably this is a case where ANSI <-> Unicode message conversions don't
work correctly. I already mailed to Alexandre my preliminary patch (which
doesn't work) for suggestions. CreateWindowExA/W should always allocate new
window proc and subclass window in the case if class was registered with a
not compatible function type (A instead of W and vice versa).
IsWindowUnicode should return TRUE for windows created by CreateWindowExW
without reference to by which version of RegisterClass (A or W) base class
was registered. Currently in Wine winproc handling does something wrong.
Right now I'm investigating it further. Until it will be fixed, switching
to unicode of the internal USER classes risks break too many applications.
But perhaps it is completely unrelated problem. Could you send me both
traces: before and after my patch was applied (+relay,+key,+message)?
