[Bug 7712] WeatherScope window title bars (including dialogs) only display 1 character

[Wine Bugs]

http://bugs.winehq.org/show_bug.cgi?id=7712

------- Additional Comments From [e-mail]  2007-16-03 14:14 -------
Hello,
> Well I don't think the program itself calls DefWindowProcA, but it gets called
> as part of the CreateWindow sequence.

Yes its correct the program registers unicode classes but creates ANSI windows
(CreateWindowExA) and sets ANSI window procs ((SetWindowLong -> A)
Code later uses "W" versions of api on "A" windows which triggers custom/default
"A" window proc.
This is no problem at all but imposes implicit A<->W conversions.

Take the window title for instance.
The apps calls "SetWindowTextW" version, supplying WCHAR string.

On windows SetWindowTextW() is implemented by SendMessageW (technically
SendMessageWorker) which result in WM_SETTEXT message routed to window proc.
Windows *knows* the target window proc is "ANSI" and converts specific messages
to corresponding ANSI/WCHAR before delivering message.
After conversion, WM_SETTEXT is called with ansi string and gets processed by
default "A" window proc.

The wine side taken from trace:

--- snip ---
0009:Call user32.SetWindowTextW(00060028,006fa440 L"Error") ret=0045a2e9
trace:msg:WINPROC_CallProcWtoA (hwnd=0x60028,msg=WM_SETTEXT,wp=00000000,lp=006fa440)
0009:Call window proc 0x476960 (hwnd=0x60028,msg=WM_SETTEXT,wp=00000000,lp=0034f2b0)
0009:Call user32.GetPropA(00060028,005f87b8 "FxMessageHandler") ret=0047697d
0009:Ret  user32.GetPropA() retval=0034fb68 ret=0047697d
0009:Call user32.CallWindowProcA(ffff0021,00060028,0000000c,00000000,0034f2b0)
ret=00476919
trace:msg:WINPROC_CallProcAtoW (hwnd=0x60028,msg=WM_SETTEXT,wp=00000000,lp=0034f2b0)
0009:Call window proc 0x603de034
(hwnd=0x60028,msg=WM_SETTEXT,wp=00000000,lp=0034e830)
0009:Call user32.DefWindowProcA(00060028,0000000c,00000000,0034e830) ret=6047732a
0009:Call winex11.drv.SetWindowText(00060028,001d4430 L"E") ret=6040d3d8
0009:Ret  winex11.drv.SetWindowText() retval=00000001 ret=6040d3d8
0009:Ret  user32.DefWindowProcA() retval=00000001 ret=6047732a
0009:Ret  window proc 0x603de034
(hwnd=0x60028,msg=WM_SETTEXT,wp=00000000,lp=0034e830) retval=00000001
0009:Ret  user32.CallWindowProcA() retval=00000001 ret=00476919
0009:Ret  window proc 0x476960
(hwnd=0x60028,msg=WM_SETTEXT,wp=00000000,lp=0034f2b0) retval=00000001
0009:Ret  user32.SetWindowTextW() retval=00000001 ret=0045a2e9
--- snip ---

The "W" call is translated to ANSI before calling next in chain.
"GetPropA" is called by app's own registered proc which in turn fetches internal
"FxMessageHandler" window proc (ANSI!)
The app's message handler relays to default window proc (hence the call to
CallWindowProcA)
Which in turn calls CallProcAtoW() (unicode conversion again!)
DefWindowProcA() is fed with unicode whichs results in incorrect behaviour.

You see double conversions for each msg which has string based parameters all
along the trace:

trace:msg:WINPROC_CallProcWtoA(hwnd=0x60028,msg=WM_SETTEXT,wp=00000000,lp=006fa440)
...
trace:msg:WINPROC_CallProcAtoW(hwnd=0x60028,msg=WM_SETTEXT,wp=00000000,lp=0034f2b0)

Anyway that apps seems horribly bugged mixing unicode and ansi stuff at several
places.
I guess they linked in some unicode 3rd party stuff but their main code is ansi
or vice versa.
> FYI, make sure to run Weatherscope with the full path or it _will_ crash.

This crash is due to their crappy commandline parser.
Just simulate GetCommandLineArgsA() with "" or "\" stuff missing. *boom*

Another one is the installer itself.
Why cant they just use standard installshield stuff like <ProgramFilesFolder>.
It insists installing to "c:\Program Files" on my german install (should do it
to "c:\Programme")

Regards