[ros-kernel] Re: Status of Explorer under ReactOS - Bug #42 (I knowthe fix)

[Ge van Geldorp]

> From: Martin Fuchs
> 
> Hi,
> 
> > ok, I have the solution here.
> > Basicly, what we need is this:
> > 1.Both an Ansi window procedure and a Unicode window 
> > procedure for the standard controls (buttons, statics etc).
> > These should ideally be implemented as stubs that call a
> > shared procedure to do all the work (like how MS does it),
> > that way they are sharing all the data thats needed.
> 
> I have implemented this and will check it in in a few minutes 
> if you don't mind.

I don't think this is the right solution. It only solves the problem of
subclassing over Ansi/Unicode boundaries for a very specific case, the
standard controls. What is needed is a more general solution.

I think that when you call GetWindowLongA() on a Unicode window,
requesting GWL_WNDPROC, you shouldn't be returned the "true" windowproc,
but a handle. Then you subclass the window by calling SetWindowLongA(),
installing an Ansi window proc. In that Ansi window proc you do whatever
it is that you want to do and then call CallWindowProcA(), passing the
handle you got from GetWindowLongA(). CallWindowProcA() notices that the
argument it received is not a window proc but a handle and knows from
that that Ansi->Unicode conversion is needed before calling the real
window proc and Unicode->Ansi after return from the real window proc.

I have added a test program apps/tests/subclass which illustrates this.
You'll notice that when you run it in MS Windows, GetWindowLongW will
return a "normal" value for GWL_WNDPROC (0x00401bb9 on my machine), but
GetWindowLongA will return a "strange" value (0xffff02a7 on my machine).

I would like to suggest to implement this scheme in ReactOS and roll
back the changes to the standard controls.

Gé van Geldorp.