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

[Dimitrie O. Paun]

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

-- 
Dimi.

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

[Guy L. Albertelli]

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

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

[Dimitrie O. Paun]

On June 5, 2002 08:45 pm, Guy L. Albertelli wrote:
> 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).

Hi Guy,

Sorry for my very late reply, but I was away on vacation for over a 
month now. I've included my version of the fix. Can you please give 
it a small test run, as I have no test cases for the situation you 
discovered.

TIA,
Dimi.

Index: dlls/comctl32/updown.c
===================================================================
RCS file: /var/cvs/wine/dlls/comctl32/updown.c,v
retrieving revision 1.41
diff -u -r1.41 updown.c
--- dlls/comctl32/updown.c	31 May 2002 23:25:44 -0000	1.41
+++ dlls/comctl32/updown.c	16 Jul 2002 12:13:16 -0000
@@ -447,7 +447,7 @@
     DWORD dwStyle = GetWindowLongW (infoPtr->Self, GWL_STYLE);
     RECT  budRect;  /* new coord for the buddy */
     int   x, width;  /* new x position and width for the up-down */
-    WNDPROC baseWndProc, currWndProc;
+    WNDPROC baseWndProc;
     CHAR buddyClass[40];
 
     /* Is it a valid bud? */
@@ -477,8 +477,7 @@
         /* Note that I don't clear the BUDDY_SUPERCLASS_WNDPROC property
            when we reset the upDown ctrl buddy to another buddy because it is not
            good to break the window proc chain. */
-	currWndProc = (WNDPROC) GetWindowLongW(bud, GWL_WNDPROC);
-	if (currWndProc != UPDOWN_Buddy_SubclassProc) {
+	if (!GetPropA(bud, BUDDY_SUPERCLASS_WNDPROC)) {
 	    baseWndProc = (WNDPROC)SetWindowLongW(bud, GWL_WNDPROC, (LPARAM)UPDOWN_Buddy_SubclassProc);
  	    SetPropA(bud, BUDDY_SUPERCLASS_WNDPROC, (HANDLE)baseWndProc);
 	}
@@ -939,7 +938,7 @@
 	    return temp;
 
 	default:
-	    if (message >= WM_USER)
+	    if ((message >= WM_USER) && (message < WM_APP))
 	     	ERR("unknown msg %04x wp=%04x lp=%08lx\n", message, wParam, lParam);
 	    return DefWindowProcW (hwnd, message, wParam, lParam);
     }