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;
}
}
}
Author: cfinck
Date: Mon Jan 5 07:22:27 2009
New Revision: 38583
URL: http://svn.reactos.org/svn/reactos?rev=38583&view=rev
Log:
Revert a part of r38087. OutputDebugStringA doesn't add a newline automatically.
Verified by MSVC's debug output and kinda proofed by http://www.unixwiz.net/techtips/outputdebugstring.html (nobody would write a function for adding newlines to the debug output if that would be done automatically)
Thanks to Gregor for the hints.
Modified:
trunk/reactos/dll/win32/kernel32/debug/output.c
Modified: trunk/reactos/dll/win32/kernel32/debug/output.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/debug/o…
==============================================================================
--- trunk/reactos/dll/win32/kernel32/debug/output.c [iso-8859-1] (original)
+++ trunk/reactos/dll/win32/kernel32/debug/output.c [iso-8859-1] Mon Jan 5 07:22:27 2009
@@ -376,18 +376,6 @@
/* copy the current block */
memcpy(a_cBuffer, _OutputString, nRoundLen);
- /* Have we reached the end of the string? */
- if (nRoundLen == nOutputStringLen)
- {
- /* Make sure we terminate with a line break */
- if (a_cBuffer[nRoundLen - 1] != '\n')
- {
- a_cBuffer[nRoundLen] = '\n';
- nRoundLen++;
- nOutputStringLen++;
- }
- }
-
/* null-terminate the current block */
a_cBuffer[nRoundLen] = 0;