Author: jimtabor
Date: Mon Jan 5 17:35:10 2009
New Revision: 38590
URL:
http://svn.reactos.org/svn/reactos?rev=38590&view=rev
Log:
- Patch by Michael Martin: Fix for Get/Set CallProc.
- Michael points out the fact that our system hard codes to unicode and does not mix ANSI
and Unicode as it should. This creates problems when applications use ansi only. ReactOS
lacks the mechanics of switching back to ANSI. The beginning of the project it seemed to
become an unwritten rule. We learn from our misstakes and move on. When working on a
drafting project, do not draw more than you can erase in a day.
Modified:
trunk/reactos/subsystems/win32/win32k/ntuser/window.c
Modified: trunk/reactos/subsystems/win32/win32k/ntuser/window.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt…
==============================================================================
--- trunk/reactos/subsystems/win32/win32k/ntuser/window.c [iso-8859-1] (original)
+++ trunk/reactos/subsystems/win32/win32k/ntuser/window.c [iso-8859-1] Mon Jan 5 17:35:10
2009
@@ -570,6 +570,8 @@
{
return GetCallProcHandle(Wnd->CallProc);
}
+ /* BUGBOY Comments: Maybe theres something Im not undestanding here, but why
would a CallProc be created
+ on a function that I thought is only suppose to return the current Windows
Proc? */
else
{
PCALLPROC NewCallProc, CallProc;
@@ -1693,6 +1695,14 @@
Wnd->UserData = 0;
Wnd->IsSystem = Wnd->Class->System;
+
+ /* BugBoy Comments: Comment below say that System classes are always created as
UNICODE.
+ In windows, creating a window with the ANSI version of CreateWindow sets the
window
+ to ansi as verified by testing with IsUnicodeWindow API.
+
+ No where can I see in code or through testing does the window change back to ANSI
+ after being created as UNICODE in ROS. I didnt do more testing to see what problems
this would cause.*/
+ // See NtUserDefSetText! We convert to Unicode all the time and never use Mix. (jt)
if (Wnd->Class->System)
{
/* NOTE: Always create a unicode window for system classes! */
@@ -2178,6 +2188,28 @@
co_IntSendMessage(ParentWindow->hSelf, WM_MDIREFRESHMENU, 0, 0);
/* ShowWindow won't activate child windows */
co_WinPosSetWindowPos(Window, HWND_TOP, 0, 0, 0, 0, SWP_SHOWWINDOW | SWP_NOMOVE |
SWP_NOSIZE);
+ }
+ }
+
+ /* BugBoy Comments: if the window being created is a edit control, ATOM 0xC007,
+ then my testing shows that windows (2k and XP) creates a CallProc for it
immediately
+ Dont understand why it does this. */
+ if (ClassAtom == 0XC007)
+ {
+ PCALLPROC CallProc;
+ //CallProc = CreateCallProc(NULL, Wnd->WndProc, bUnicodeWindow,
Wnd->ti->kpi);
+ CallProc = CreateCallProc(NULL, Wnd->WndProc, Wnd->Unicode ,
Wnd->ti->kpi);
+
+ if (!CallProc)
+ {
+ SetLastWin32Error(ERROR_NOT_ENOUGH_MEMORY);
+ DPRINT1("Warning: Unable to create CallProc for edit control. Control may
not operate correctly! hwnd %x\n",hWnd);
+ }
+ else
+ {
+ UserAddCallProcToClass(Wnd->Class, CallProc);
+ Wnd->CallProc = CallProc;
+ Wnd->IsSystem = FALSE;
}
}
@@ -3414,7 +3446,7 @@
DPRINT("NtUserGetWindowLong(%x,%d,%d)\n", hWnd, (INT)Index, Ansi);
- if (!(Window = UserGetWindowObject(hWnd)))
+ if (!(Window = UserGetWindowObject(hWnd)) || !Window->Wnd)
{
return 0;
}
@@ -3574,10 +3606,22 @@
UserAddCallProcToClass(Wnd->Class,
CallProc);
}
+ /* BugBoy Comments: Added this if else, see below comments */
+ if (!Wnd->CallProc)
+ {
+ Ret = Wnd->WndProc;
+ }
+ else
+ {
+ Ret = GetCallProcHandle(Wnd->CallProc);
+ }
Wnd->CallProc = CallProc;
- Ret = GetCallProcHandle(Wnd->CallProc);
+ /* BugBoy Comments: Above sets the current CallProc for the
+ window and below we set the Ret value to it.
+ SetWindowLong for WNDPROC should return the previous proc
+ Ret = GetCallProcHandle(Wnd->CallProc); */
}
}
@@ -4632,6 +4676,7 @@
{
SetLastWin32Error(ERROR_NOT_ENOUGH_MEMORY);
Ret = FALSE;
+ goto Exit;
}
}
}