PATCH: [Bug 671] Valve Hammer Editor does not run - recursion in buddySupperClassWndProc

[Guy L. Albertelli]

----- Original Message -----
From: "Dimitrie O. Paun" <dpaun at rogers.com>
To: <wine-devel at winehq.com>; "Guy L. Albertelli" <galberte at neo.lrun.com>
Sent: Wednesday, June 05, 2002 12:48 AM
Subject: Re: PATCH: [Bug 671] Valve Hammer Editor does not run - recursion
in buddySupperClassWndProc


> On June 5, 2002 12:31 am, Guy L. Albertelli wrote:
> > Ok, the loop was due to constant setting of the buddy wndproc because
the
> > retrieve of the wndproc did not match. The match failed because the
> > application
> > program added a wndproc (its own) to the buddy window. The fix will be
> > submitted to wine-patches.
>
> Hmm, I see. But with this fix, it means that you can not change the
> wndproc of the buddy once set. This can not be right... Also, you
> broke the UDM_SETBUDDY.
>
> I this the correct fix is to add the flag as a property on the buddy,
> not on the UpDown...

You probably are correct, Dimi. What I did is model the builtin actions on
what the +relay,+message trace of the native showed. The basic problem was
that the GetWindowLong never returned the builtin wndproc address, so we
always did the SetWindowLong again. This disabled the application's own
wndproc and eventually caused the loop. Since the native control never did
the GetWindowLong and did the SetWindowLong only once, that was how I
changed the code. It sounds like you have a much better understanding of
UpDown (and probably some better test cases). Please correct my poor
attempt.

Thanks,
Guy