August 2001 - Wine-Devel - list.winehq.org

Re: PATCH: olepictures black & white
by Alexandre Julliard Aug. 19, 2001

Aug. 19, 2001

Marcus Meissner <marcus(a)jet.franken.de> writes: > Somehow the loaded JPEGs are now black & white in the IPicture implementation. > > Exchanging CreateCompatibleDC(0) by CreateDCA("DISPLAY",0,0,0); makes > them colored again. > > But I am not sure whether the problem itself was a bug on my side, or > on the WINE side... Maybe a bit of both... I think the patch below should fix the GDI part; but is there any reason you don't use GetDC(0) instead of CreateCompatibleDC? It would avoid creating a new DC every time. Index: objects/dib.c =================================================================== RCS file: /opt/cvs-commit/wine/objects/dib.c,v retrieving revision 1.60 diff -u -r1.60 dib.c --- objects/dib.c 2001/08/17 00:07:42 1.60 +++ objects/dib.c 2001/08/19 19:27:42 @@ -875,7 +875,9 @@ /* Now create the bitmap */ - if (fColor) handle = CreateCompatibleBitmap( hdc, width, height ); + if (fColor) + handle = CreateBitmap( width, height, GetDeviceCaps( hdc, PLANES ), + GetDeviceCaps( hdc, BITSPIXEL ), NULL ); else handle = CreateBitmap( width, height, 1, 1, NULL ); if (!handle) return 0; -- Alexandre Julliard julliard(a)winehq.com

1 0

PATCH: oleauto header problem
by Nikolas Zimmermann Aug. 19, 2001

Aug. 19, 2001

Hi there, Reaktivate doesn't compile anymore. We need this patch. Bye Bye Niko -- Nikolas Zimmermann wildfox(a)kde.org

1 0

Re: WM_GETTEXTLENGTH change in winproc.c
by Gerard Patel Aug. 18, 2001

Aug. 18, 2001

At 02:35 PM 18/08/2001 -0700, you wrote: >For standard controls like buttons it should never be a problem since >there is both an ASCII and Unicode win proc, so in a pure ASCII app we >should never do the conversion. I think the problem is that the >dialog code does a CreateWindowW, so the button is Unicode even though >the app does everything in ASCII. I guess we'll have to maintain both >A and W win procs inside each window, not only inside the class. How about creating Ascii windows when the app calls DialogBox..A variants ? Gerard

1 0

Re: WM_GETTEXTLENGTH change in winproc.c
by Alexandre Julliard Aug. 18, 2001

Aug. 18, 2001

Gerard Patel <gerard.patel(a)nerim.net> writes: > How about creating Ascii windows when the app calls DialogBox..A variants ? That could be a workaround, but since dialog resources are Unicode it's better to avoid converting back and forth. Besides, Windows maintains two different win procs for windows of standard classes so we should do it this way too. I'll try to come up with something. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: WM_GETTEXTLENGTH change in winproc.c
by Gerard Patel Aug. 18, 2001

Aug. 18, 2001

At 01:19 PM 18/08/2001 -0700, you wrote: > >The idea is that 6 Unicode chars can yield more than 6 ASCII chars >with DBCS text. The MSDN doc states that WM_GETTEXTLENGTH can return >more than the actual size when mixing ASCII and Unicode. > >What does the app do exactly? Maybe there are cases where the >conversion can be avoided. WM_GETTEXTLENGTH, WM_GETTEXT, then DrawText with the length returned by WM_GETTEXTLENGTH. If the app had used the length returned by WM_GETTEXT, it would have worked all right of course - maybe that's the reason why the problem does not appear more often ? In the following trace Cancel is the text of a button in a dialog box. Gerard 080682e8:Call window proc 0x5f404ae6 (hwnd=000026dc,msg=WM_DRAWITEM,wp=00000002,lp=40586474) 080682e8:Call user32.GetPropA(000026dc,5f49c94c "AfxOldWndProc423") ret=5f404b09 080682e8:Ret user32.GetPropA() retval=40ac0259 ret=5f404b09 080682e8:Call user32.CallWindowProcA(40ac0259,000026dc,0000002b,00000002,40586474) ret=5f404b4b 080682e8:Call window proc 0x406a7980 (hwnd=000026dc,msg=WM_DRAWITEM,wp=00000002,lp=40586474) 080682e8:Call window proc 0x43d715 (hwnd=000026dc,msg=WM_DRAWITEM,wp=00000002,lp=40586474) 080682e8:Call user32.GetWindowLongA(000026dc,00000008) ret=0043d727 080682e8:Ret user32.GetWindowLongA() retval=40586914 ret=0043d727 080682e8:Call user32.GetWindowTextLengthA(00002e0c) ret=0043bb82 trace:message:SPY_EnterMessage (00002e0c) "Cancel" message [000e] WM_GETTEXTLENGTH sent from self wp=00000000 lp=00000000 080682e8:Call window proc 0x43d28b (hwnd=00002e0c,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) 080682e8:Call user32.CallWindowProcA(40ac00f1,00002e0c,0000000e,00000000,00000000) ret=0043d2b8 080682e8:Call window proc 0x40679e8c (hwnd=00002e0c,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) trace:message:SPY_EnterMessage (00002e0c) DefWindowProc32: WM_GETTEXTLENGTH [000e] wp=00000000 lp=00000000 trace:message:SPY_ExitMessage (00002e0c) DefWindowProc32: WM_GETTEXTLENGTH [000e] returned 00000006 080682e8:Ret window proc 0x40679e8c (hwnd=00002e0c,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) retval=00000006 080682e8:Ret user32.CallWindowProcA() retval=0000000c ret=0043d2b8 080682e8:Ret window proc 0x43d28b (hwnd=00002e0c,msg=WM_GETTEXTLENGTH,wp=00000000,lp=00000000) retval=0000000c trace:message:SPY_ExitMessage (00002e0c) "Cancel" message [000e] WM_GETTEXTLENGTH returned 0000000c 080682e8:Ret user32.GetWindowTextLengthA() retval=0000000c ret=0043bb82 080682e8:Call ntdll.RtlEnterCriticalSection(5f4d0088) ret=5f4020bd 080682e8:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=5f4020bd 080682e8:Call ntdll.RtlLeaveCriticalSection(5f4d0088) ret=5f402103 080682e8:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=5f402103 080682e8:Call user32.GetWindowTextA(00002e0c,413904e0,0000000d) ret=0043bba9 trace:message:SPY_EnterMessage (00002e0c) "Cancel" message [000d] WM_GETTEXT sent from self wp=0000000d lp=413904e0 080682e8:Call window proc 0x43d28b (hwnd=00002e0c,msg=WM_GETTEXT,wp=0000000d,lp=413904e0) 080682e8:Call user32.CallWindowProcA(40ac00f1,00002e0c,0000000d,0000000d,413904e0) ret=0043d2b8 080682e8:Call window proc 0x40679e8c (hwnd=00002e0c,msg=WM_GETTEXT,wp=0000000d,lp=403a7328) trace:message:SPY_EnterMessage (00002e0c) DefWindowProc32: WM_GETTEXT [000d] wp=0000000d lp=403a7328 trace:message:SPY_ExitMessage (00002e0c) DefWindowProc32: WM_GETTEXT [000d] returned 00000006 080682e8:Ret window proc 0x40679e8c (hwnd=00002e0c,msg=WM_GETTEXT,wp=0000000d,lp=403a7328) retval=00000006 080682e8:Ret user32.CallWindowProcA() retval=00000006 ret=0043d2b8 080682e8:Ret window proc 0x43d28b (hwnd=00002e0c,msg=WM_GETTEXT,wp=0000000d,lp=413904e0) retval=00000006 trace:message:SPY_ExitMessage (00002e0c) "Cancel" message [000d] WM_GETTEXT returned 00000006 080682e8:Ret user32.GetWindowTextA() retval=00000006 ret=0043bba9 <snip unrelated painting instructions> 080682e8:Call gdi32.GetTextExtentPoint32A(00000088,413b00d0,00000006,40585f68) ret=0043c022 080682e8:Call x11drv.GetTextExtentPoint(4037c808,4039d238,00000006,40585f68) ret=40747c04 trace:text:X11DRV_GetTextExtentPoint L"Cancel"... 6 080682e8:Ret x11drv.GetTextExtentPoint() retval=00000001 ret=40747c04 080682e8:Ret gdi32.GetTextExtentPoint32A() retval=00000001 ret=0043c022 <snip a few text painting preparation> 080682e8:Call user32.DrawTextA(00000088,413904e0 "Cancel",0000000c,40585f28,00000100) ret=0043c13a trace:text:DrawTextExW L"Cancel", 12 , [(9,4),(51,20)]

1 0

Re: WM_GETTEXTLENGTH change in winproc.c
by Alexandre Julliard Aug. 18, 2001

Aug. 18, 2001

Gerard Patel <gerard.patel(a)nerim.net> writes: > WM_GETTEXTLENGTH, WM_GETTEXT, then DrawText with the > length returned by WM_GETTEXTLENGTH. > If the app had used the length returned by WM_GETTEXT, it would > have worked all right of course - maybe that's the reason why > the problem does not appear more often ? For standard controls like buttons it should never be a problem since there is both an ASCII and Unicode win proc, so in a pure ASCII app we should never do the conversion. I think the problem is that the dialog code does a CreateWindowW, so the button is Unicode even though the app does everything in ASCII. I guess we'll have to maintain both A and W win procs inside each window, not only inside the class. -- Alexandre Julliard julliard(a)winehq.com

1 0

WM_GETTEXTLENGTH change in winproc.c
by Gerard Patel Aug. 18, 2001

Aug. 18, 2001

I don't understand it : case WM_GETTEXTLENGTH: 719 case CB_GETLBTEXTLEN: 720 case LB_GETTEXTLEN: 721 /* there may be one DBCS char for each Unicode char */ 722 return result * 2; This has a bad effect on one of my test apps - returns a length of 12 for a text of 6 characters, displays funny symbols after the text. The Unicode window proc returns 6, why the unicode/ascii conversion should make it 12 ? The Api returns number of chars, not bytes. Gerard

1 0

Re: WM_GETTEXTLENGTH change in winproc.c
by Alexandre Julliard Aug. 18, 2001

Aug. 18, 2001

Gerard Patel <gerard.patel(a)nerim.net> writes: > I don't understand it : > > case WM_GETTEXTLENGTH: > 719 case CB_GETLBTEXTLEN: > 720 case LB_GETTEXTLEN: > 721 /* there may be one DBCS char for each Unicode char */ > 722 return result * 2; > > This has a bad effect on one of my test apps - returns a length of 12 > for a text of 6 characters, displays funny symbols after the text. > > The Unicode window proc returns 6, why the unicode/ascii conversion > should make it 12 ? The Api returns number of chars, not bytes. The idea is that 6 Unicode chars can yield more than 6 ASCII chars with DBCS text. The MSDN doc states that WM_GETTEXTLENGTH can return more than the actual size when mixing ASCII and Unicode. What does the app do exactly? Maybe there are cases where the conversion can be avoided. -- Alexandre Julliard julliard(a)winehq.com

1 0

not-yet-connected sockets?
by Daniel Walker Aug. 18, 2001

Aug. 18, 2001

The problem is that poll returns POLLHUP when a socket isn't connected, then wine ignores the socket and it's events .. I realize this has been known for a some time(since linux 2.4), but why hasn't it been fix? Doesn't this effect a lot of non-blocking socket applications? Daniel Walker

3 13

Re: Toolbar background error
by Gerard Patel Aug. 18, 2001

Aug. 18, 2001

At 06:54 PM 17/08/2001 -0700, you wrote: <snip> >But their solution is still not correct IMO. How about something like >this? All clear for me on this one, tested without problem for all of my test apps - at least the one surviving the Gdi lock slaughter :-) Gerard

1 0