----- Original Message ----- From: "Dimitrie O. Paun" dpaun@rogers.com To: wine-devel@winehq.com; "Guy L. Albertelli" galberte@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