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...
----- 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
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); }