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

[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.

> 2.A new version of NtUserRegisterClassExWOW (and therefore IntCreateClass) 
> such that it takes both ansi and unicode window procedures and sets the 
> fields of the internal class structure as appropriate.
> 3.changes to how controls are registered to pass both window procedures.
> 4.changes to CreateWindowEx so that if one is creating a "standard" window 
> class (i.e. those defined in user32.dll and having both an ansi and a 
> unicode window procedure defined in the user32.dll symbol table), it will 
> ignore the class Unicode field and instead set the window unicode field to 
> either Ansi or Unicode based on which version of CreateWindowEx was called. 
> This test should ONLY be done for standard controls, all other calls to 
> CreateWindowEx should rely on the class unicode field.
> Not sure how things like common controls work but based on my analysis of 
> user32, doing this for the controls that are inside user32.dll will make 
> things work like they do on windows (even with respect to subclassing, 
> sending messages and so on).

Have you already implemented this?
I extended struct builtin_class_descr by "WNDPROC procA;"
By the way - the original version of the Wine code already contained this member.

Martin