February 2015 - Wine-Devel - list.winehq.org

Re: [PATCH 3/5] wined3d: Remove ARB_/EXT_TEXTURE_ENV_ADD.

by Henri Verbeet

On 24 February 2015 at 13:38, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > Unused. > --- But they should be used by ffp_fragment_get_caps(), since set_tex_op() uses that functionality.

Feb. 25, 2015

Re: comctl32: SysDateTimePick32 control add Alt+down hot key likewindows (try 2)

by Nikolay Sivov

On 25.02.2015 10:56, Changhui Liu wrote: > Superseded patch 109085 > http://source.winehq.org/patches/data/109085 > > Change log: > 1, Pass test on all Windows. > > 2, Add DTN_DROPDOWN and DTN_CLOSEUPnotification test. > > 3, > >>>/ + case WM_SYSKEYDOWN: > />>/ + if (wParam == VK_DOWN) > />>/ + { > />>/ + POINT pt; > />>/ + RECT rect; > />>/ + GetClientRect(hwnd, &rect); > />>/ + pt.x = rect.right - GetSystemMetrics(SM_CXVSCROLL)/2; > />>/ + pt.y = rect.top + GetSystemMetrics(SM_CYHSCROLL)/2; > />>/ + > />>/ + return DATETIME_LButtonDown (infoPtr, (SHORT)pt.x, (SHORT)pt.y); > />>/ + } > />>/ + > />> >>>If it really works this way you should just make it drop directly, >>without faking click point coordinates. > > Because most of code of the directly implement are same as DATETIME_LButtonDown, > and too many repeat code looks bad. > So faking click point coordinates can reuse code. > I'm not saying you should duplicate it, but reuse it in a clean way without hit testing - move relevant code somewhere and use it. > + if (WM_NOTIFY == message) > + { > + NMHDR* hdr = (NMHDR*)lParam; > + > + if (hdr->code == DTN_DROPDOWN) > + { > + g_hWndMonthCal = (HWND)SendMessageA(hdr->hwndFrom, DTM_GETMONTHCAL, 0, 0); > + trace("open SysMonthCal32=%p\n", g_hWndMonthCal ); > + } > + else if (hdr->code == DTN_CLOSEUP) > + { > + trace("close SysMonthCal32=%p\n", g_hWndMonthCal); > + } > + } That's not a notification test as you don't check anything. Please add a proper message sequence test, we have tons of examples for those.

Feb. 25, 2015

Re: comctl32: SysDateTimePick32 control add Alt+down hot key likewindows (try 2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=11722 Your paranoid android. === wvistau64 (32 bit datetime) === The test timed out

Feb. 25, 2015

Re: (try 6)[1/5] imm32: Move thread data from TLSEntry to an internal list

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -1512,11 +1589,15 @@ BOOL WINAPI ImmGetConversionStatus( > */ > HWND WINAPI ImmGetDefaultIMEWnd(HWND hWnd) > { > - if (IMM_GetThreadData()->hwndDefault == NULL) > - IMM_GetThreadData()->hwndDefault = CreateWindowExW( WS_EX_TOOLWINDOW, > + HWND ret; > + IMMThreadData* thread_data = IMM_GetThreadData(0); > + if (thread_data->hwndDefault == NULL) > + thread_data->hwndDefault = CreateWindowExW( WS_EX_TOOLWINDOW, > szwIME, NULL, WS_POPUP, 0, 0, 1, 1, 0, 0, 0, 0); > - TRACE("Default is %p\n",IMM_GetThreadData()->hwndDefault); > - return IMM_GetThreadData()->hwndDefault; > + ret = thread_data->hwndDefault; > + LeaveCriticalSection(&threaddata_cs); > + TRACE("Default is %p\n",ret); > + return ret; You can't create a window while holding the critical section, this will cause deadlocks. -- Alexandre Julliard julliard(a)winehq.org

Feb. 25, 2015

Re: [PATCH 3/3] scrrun: Implement HashVal for floating point keys (try2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=11712 Your paranoid android. === wvistau64 (64 bit dictionary) === dictionary.c:349: Test failed: got hash 0x000001f4 dictionary.c:374: Test failed: got hash 0x000001f4 === w2008s64 (64 bit dictionary) === dictionary.c:349: Test failed: got hash 0x000001f4 dictionary.c:374: Test failed: got hash 0x000001f4

Feb. 24, 2015

Re: [PATCH 3/3] scrrun: Implement HashVal for floating point keys

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=11703 Your paranoid android. === w2000pro (32 bit dictionary) === dictionary.c:240: Test failed: 0: text mode: got hash 0x00000415, expected 0x00000000 dictionary.c:254: Test failed: 0: db mode: got hash 0x00000415, expected 0x00000000 dictionary.c:240: Test failed: 1: text mode: got hash 0x000003e8, expected 0x00000000 dictionary.c:254: Test failed: 1: db mode: got hash 0x000003e8, expected 0x00000000 dictionary.c:240: Test failed: 2: text mode: got hash 0x0000028a, expected 0x00000000 dictionary.c:254: Test failed: 2: db mode: got hash 0x0000028a, expected 0x00000000 dictionary.c:240: Test failed: 3: text mode: got hash 0x00000061, expected 0x00000000 dictionary.c:254: Test failed: 3: db mode: got hash 0x00000061, expected 0x00000000 dictionary.c:240: Test failed: 4: text mode: got hash 0x00000061, expected 0x00000000 dictionary.c:254: Test failed: 4: db mode: got hash 0x00000061, expected 0x00000000 dictionary.c:263: Test failed: got 0x00000000 dictionary.c:271: Test failed: got 0x00000000 dictionary.c:279: Test failed: got 0x00000000 dictionary.c:281: Test failed: got hash 0x000000a1 dictionary.c:287: Test failed: got 0x00000000 dictionary.c:295: Test failed: got 0x00000000 dictionary.c:303: Test failed: got 0x00000000 dictionary.c:347: Test failed: got 0x00000000 dictionary.c:349: Test failed: got hash 0x00000000 dictionary.c:372: Test failed: got 0x00000000 dictionary.c:374: Test failed: got hash 0x00000000 === w2003std (32 bit dictionary) === dictionary.c:263: Test failed: got 0x00000000 dictionary.c:271: Test failed: got 0x00000000 dictionary.c:279: Test failed: got 0x00000000 dictionary.c:281: Test failed: got hash 0x000000a1 dictionary.c:287: Test failed: got 0x00000000 dictionary.c:295: Test failed: got 0x00000000 dictionary.c:303: Test failed: got 0x00000000 dictionary.c:347: Test failed: got 0x00000000 dictionary.c:372: Test failed: got 0x00000000 === wvistau64 (64 bit dictionary) === dictionary.c:347: Test failed: got 0x00000000 dictionary.c:349: Test failed: got hash 0x000001f4 dictionary.c:372: Test failed: got 0x00000000 dictionary.c:374: Test failed: got hash 0x000001f4 === w2008s64 (64 bit dictionary) === dictionary.c:347: Test failed: got 0x00000000 dictionary.c:349: Test failed: got hash 0x000001f4 dictionary.c:372: Test failed: got 0x00000000 dictionary.c:374: Test failed: got hash 0x000001f4

Feb. 24, 2015

Re: [PATCH 2/3] scrrun: Implement HashVal property for integer keys

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=11702 Your paranoid android. === w2000pro (32 bit dictionary) === dictionary.c:211: Test failed: 0: text mode: got hash 0x00000415, expected 0x00000000 dictionary.c:225: Test failed: 0: db mode: got hash 0x00000415, expected 0x00000000 dictionary.c:211: Test failed: 1: text mode: got hash 0x000003e8, expected 0x00000000 dictionary.c:225: Test failed: 1: db mode: got hash 0x000003e8, expected 0x00000000 dictionary.c:211: Test failed: 2: text mode: got hash 0x0000028a, expected 0x00000000 dictionary.c:225: Test failed: 2: db mode: got hash 0x0000028a, expected 0x00000000 dictionary.c:211: Test failed: 3: text mode: got hash 0x00000061, expected 0x00000000 dictionary.c:225: Test failed: 3: db mode: got hash 0x00000061, expected 0x00000000 dictionary.c:211: Test failed: 4: text mode: got hash 0x00000061, expected 0x00000000 dictionary.c:225: Test failed: 4: db mode: got hash 0x00000061, expected 0x00000000 dictionary.c:234: Test failed: got 0x00000000 dictionary.c:242: Test failed: got 0x00000000 dictionary.c:250: Test failed: got 0x00000000 dictionary.c:252: Test failed: got hash 0x000000a1 dictionary.c:258: Test failed: got 0x00000000 dictionary.c:266: Test failed: got 0x00000000 dictionary.c:274: Test failed: got 0x00000000 === w2003std (32 bit dictionary) === dictionary.c:234: Test failed: got 0x00000000 dictionary.c:242: Test failed: got 0x00000000 dictionary.c:250: Test failed: got 0x00000000 dictionary.c:252: Test failed: got hash 0x000000a1 dictionary.c:258: Test failed: got 0x00000000 dictionary.c:266: Test failed: got 0x00000000 dictionary.c:274: Test failed: got 0x00000000

Feb. 24, 2015

Re: [PATCH 1/3] scrrun: Implement HashVal property for VT_BSTR case

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=11701 Your paranoid android. === w2000pro (32 bit dictionary) === dictionary.c:201: Test failed: 0: text mode: got hash 0x00000415, expected 0x00000000 dictionary.c:215: Test failed: 0: db mode: got hash 0x00000415, expected 0x00000000 dictionary.c:201: Test failed: 1: text mode: got hash 0x000003e8, expected 0x00000000 dictionary.c:215: Test failed: 1: db mode: got hash 0x000003e8, expected 0x00000000 dictionary.c:201: Test failed: 2: text mode: got hash 0x0000028a, expected 0x00000000 dictionary.c:215: Test failed: 2: db mode: got hash 0x0000028a, expected 0x00000000 dictionary.c:201: Test failed: 3: text mode: got hash 0x00000061, expected 0x00000000 dictionary.c:215: Test failed: 3: db mode: got hash 0x00000061, expected 0x00000000 dictionary.c:201: Test failed: 4: text mode: got hash 0x00000061, expected 0x00000000 dictionary.c:215: Test failed: 4: db mode: got hash 0x00000061, expected 0x00000000

Feb. 24, 2015

Re: [2/3] winmm: Add .wav extension when searching for PlaySound.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=11694 Your paranoid android. === w2000pro (32 bit wave) === wave.c:1679: Test failed: PlaySound succeeded, got 1 === wxppro (32 bit wave) === wave.c:1679: Test failed: PlaySound succeeded, got 1 === w2003std (32 bit wave) === wave.c:1679: Test failed: PlaySound succeeded, got 1 === wvistau64 (32 bit wave) === wave.c:1662: Test failed: PlaySound failed, got 0 wave.c:1666: Test failed: PlaySound failed, got 0 wave.c:1674: Test failed: PlaySound failed, got 0 === w2008s64 (32 bit wave) === wave.c:1662: Test failed: PlaySound failed, got 0 wave.c:1666: Test failed: PlaySound failed, got 0 wave.c:1674: Test failed: PlaySound failed, got 0 === wvistau64 (64 bit wave) === wave.c:1662: Test failed: PlaySound failed, got 0 wave.c:1666: Test failed: PlaySound failed, got 0 wave.c:1674: Test failed: PlaySound failed, got 0 === w2008s64 (64 bit wave) === wave.c:1662: Test failed: PlaySound failed, got 0 wave.c:1666: Test failed: PlaySound failed, got 0 wave.c:1674: Test failed: PlaySound failed, got 0

Feb. 24, 2015

Re: [3/5] comctl32: Implement TaskDialogIndirect as a custom dialog box (try 2)

by Alexandre Julliard

Joachim Priesner <joachim.priesner(a)web.de> writes: > Am Dienstag, 24. Februar 2015 schrieb Alexandre Julliard: >> Joachim Priesner <joachim.priesner(a)web.de> writes: >> >> > Am Dienstag, 24. Februar 2015 schrieb Alexandre Julliard: >> >> There shouldn't be any need to distinguish. If you get 0 then there's no >> >> defined string and you use the fallback. >> > >> > Windows makes that distinction though: >> > - String of length zero: TaskDialogIndirect succeeds, but no text is displayed for that parameter >> > - Invalid resource: TaskDialogIndirect fails with ERROR_RESOURCE_NAME_NOT_FOUND >> >> This is broken behavior, I don't see much point in reproducing this >> (unless of course you can find an app that depends on it). > > I'd argue that a) the goal of "bug-for-bug" compatibility is really > easy to achieve in this case and b) it saves debugging time in the > long run should there be an application that does rely on it (even if > only accidentally). OTOH if an app depends on some missing string (say a resource in a builtin dll), seeing empty text will be a lot easier to figure out than if you don't get the dialog at all. -- Alexandre Julliard julliard(a)winehq.org

Feb. 24, 2015