user32: Problem using SetClassLongW to subclass built-in control (Edit)
mikolaj at zalewski.pl
Thu Jul 10 07:33:46 CDT 2008
As it was written, you need to write some more tests for such changes.
It required a few iterations before we got
SetWindowLongPtr(GWLP_WNDPROC, ...) right, so this might be also not
easy. The tests for SetWindowLongPtr are in dlls/user32/tests/class.c.
Some things I can think of that requires checking:
1. Is the edit class still special after changing the winproc - does the
unicodeness of controls created after the SetClassLongPtr call depend on
whether CreateWindowA or CreateWindowW was used
2. Does the same winproc really receive both Unicode and ANSI messages.
That's the strangest thing in your patch. Does calling SetWindowTextW
and SetWindowTextA call the same function, but once with a Unicode
string in lparam and the other time with an ANSI string.
3. Does GetClassLongPtr[AW] return an address or a winproc handle (there
is a IS_WINPROC_HANDLE macro in dlls/users32/tests/class.c). The same
for GetWindowLongPtr[AW]. If point 1 is true then it would be good to
check it for controls created with both CreateWindowA and W
4. Does this apply only to the edit class or to all built-in classes.
The edit class is special from the point of view of GetWindowLongPtr so
it may be also special here.
I think, knowing the answers to these questions would make it easier
to create a good patch. This patch seems very strange as it seems
unlikely that the same function would be used for both the A and W calls.
More information about the wine-devel