user32: Problem using SetClassLongW to subclass built-in control (Edit)

Mikołaj Zalewski mikolaj at
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 mailing list