April 2016 - Wine-devel - list.winehq.org

Re: [PATCH 1/2] d3drm/tests: Add tests for IDirect3DRM*::CreateObject (v2).
by Henri Verbeet 12 Apr '16

12 Apr '16

On 11 April 2016 at 20:04, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > + hr = IDirect3DRM_CreateObject(d3drm1, NULL, NULL, tests[i].iid, (void **)&unknown); > + todo_wine ok(hr == D3DRMERR_BADVALUE, "Test %u: expected hr == D3DRMERR_BADVALUE, got %#x.\n", i, hr); Note that mentioning the expected value is mostly redundant here. It's obvious as soon as you look at the test source, and test output isn't generally useful without that. > + hr = IDirect3DRM_CreateObject(d3drm1, tests[i].clsid, NULL, tests[i].iid, (void **)&unknown); > + todo_wine ok(SUCCEEDED(hr), "Test %u: expected hr == D3DRM_OK, got %#x.\n", i, hr); > + if (SUCCEEDED(hr)) > + { I'll point out that if you had done a "continue" on failure instead, you wouldn't need to change the indentation when you remove the todo_wine.

2 1

Re: [PATCH 05/11] dxgi: Partially implement dxgi_swapchain_GetContainingOutput().
by Henri Verbeet 12 Apr '16

12 Apr '16

On 12 April 2016 at 12:29, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > This implementation works properly for adapters that have got 1 output. > --- I could probably live with this, considering winex11 and wined3d don't properly report multiple outputs anyway, but at the same time I think it shouldn't be hard to implement this properly.

1 0

Re: [PATCH 2/4] d3d10core: Support NULL DepthStecilView pointer in ClearDepthStencilView
by Marvin 12 Apr '16

12 Apr '16

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=22096 Your paranoid android. === wvistau64 (32 bit device) === device: unhandled exception c0000005 at 740CCE1D === w2008s64 (32 bit device) === device: unhandled exception c0000005 at 7397CE1D === wvistau64 (64 bit device) === device: unhandled exception c0000005 at 0000000074AB253F === w2008s64 (64 bit device) === device: unhandled exception c0000005 at 0000000073DB253F

2 1

Re: [PATCH 4/4] d3d10core: Support NULL RenderTargetView pointer in ClearRenderTargetView
by Marvin 12 Apr '16

12 Apr '16

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=22098 Your paranoid android. === wvistau64 (32 bit device) === device: unhandled exception c0000005 at 73F9CBBD === w2008s64 (32 bit device) === device: unhandled exception c0000005 at 7384CBBD === wvistau64 (64 bit device) === device: unhandled exception c0000005 at 0000000074AB22BF === w2008s64 (64 bit device) === device: unhandled exception c0000005 at 00000000739B22BF

1 0

Re: [PATCH 3/4] d3d11: Support NULL RenderTargetView pointer in ClearRenderTargetView
by Józef Kucia 12 Apr '16

12 Apr '16

On Tue, Apr 12, 2016 at 9:52 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > @@ -4897,6 +4898,9 @@ static void test_update_subresource(void) > ID3D11DeviceContext_ClearRenderTargetView(context, test_context.backbuffer_rtv, red); > check_texture_color(test_context.backbuffer, 0x7f0000ff, 1); > > + ID3D11DeviceContext_ClearRenderTargetView(context, NULL, green); > + check_texture_color(test_context.backbuffer, 0x7f0000ff, 1); > + > draw_quad(&test_context); > check_texture_color(test_context.backbuffer, 0x00000000, 0); The "test_clear_render_target_view" function would be much better place for this test.

1 0

Re: user32/tests: Add some tests for dialog owner disabled state. (v3)
by Jacek Caban 12 Apr '16

12 Apr '16

Hi Dmitry, On 04/06/16 13:15, Dmitry Timoshkov wrote: > Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru> > --- > dlls/user32/tests/win.c | 98 ++++++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 96 insertions(+), 2 deletions(-) > > diff --git a/dlls/user32/tests/win.c b/dlls/user32/tests/win.c > index 957e8a1d..528669e 100644 > --- a/dlls/user32/tests/win.c > +++ b/dlls/user32/tests/win.c > @@ -4258,6 +4258,78 @@ static INT_PTR WINAPI empty_dlg_proc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM > return 0; > } > > +static INT_PTR WINAPI empty_dlg_proc3(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam) > +{ > + if (msg == WM_INITDIALOG) > + EndDialog(hwnd, 0); > + > + return 0; > +} > + > +struct dialog_param > +{ > + HWND parent, grand_parent; > + DLGTEMPLATE *dlg_data; > +}; > + > +static INT_PTR WINAPI empty_dlg_proc2(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam) > +{ > + if (msg == WM_INITDIALOG) > + { > + DWORD style = GetWindowLongA(hwnd, GWL_STYLE); > + struct dialog_param *param = (struct dialog_param *)lparam; > + BOOL parent_is_child; > + HWND disabled_hwnd; > + > + parent_is_child = (GetWindowLongA(param->parent, GWL_STYLE) & (WS_POPUP | WS_CHILD)) == WS_CHILD; > + > + ok(IsWindowEnabled(hwnd), "wrong state for %p\n", hwnd); > + if (parent_is_child) > + { > + ok(IsWindowEnabled(param->parent), "wrong state for %08x\n", style); > + disabled_hwnd = param->grand_parent; > + } > + else > + { > + ok(!IsWindowEnabled(param->parent), "wrong state for %08x\n", style); > + disabled_hwnd = param->parent; > + } > + > + if (param->grand_parent) > + { > + if (parent_is_child) > + ok(!IsWindowEnabled(param->grand_parent), "wrong state for %08x\n", style); > + else > + ok(IsWindowEnabled(param->grand_parent), "wrong state for %08x\n", style); > + } > + > + DialogBoxIndirectParamA(GetModuleHandleA(NULL), param->dlg_data, disabled_hwnd, empty_dlg_proc3, 0); > + todo_wine_if ((style & (WS_CHILD|WS_POPUP)) == WS_CHILD) > + ok(IsWindowEnabled(disabled_hwnd), "wrong state for %08x\n", style); If you ensured that disabled_hwnd is enabled here, then testing it later, after dialog is done, has very little value. Maybe you'd disable it by EnableWindow() call here? > + > + ok(IsWindowEnabled(hwnd), "wrong state for %p\n", hwnd); > + ok(IsWindowEnabled(param->parent), "wrong state for %p\n", param->parent); > + if (param->grand_parent) > + todo_wine_if ((style & (WS_CHILD|WS_POPUP)) == WS_CHILD) > + ok(IsWindowEnabled(param->grand_parent), "wrong state for %p (%08x)\n", param->grand_parent, style); > + > + DialogBoxIndirectParamA(GetModuleHandleA(NULL), param->dlg_data, hwnd, empty_dlg_proc3, 0); > + ok(IsWindowEnabled(hwnd), "wrong state for %p\n", hwnd); > + ok(IsWindowEnabled(param->parent), "wrong state for %p\n", param->parent); > + if (param->grand_parent) > + todo_wine_if ((style & (WS_CHILD|WS_POPUP)) == WS_CHILD) > + ok(IsWindowEnabled(param->grand_parent), "wrong state for %p (%08x)\n", param->grand_parent, style); Why do you put those tests inside WM_INITDIALOG? Wouldn't separated tests be cleaner? > + param->dlg_data->style |= WS_CHILD; > + DialogBoxIndirectParamA(GetModuleHandleA(NULL), param->dlg_data, hwnd, empty_dlg_proc3, 0); > + todo_wine_if (!(style & (WS_CHILD|WS_POPUP))) > + ok(IsWindowEnabled(hwnd), "wrong state for %p (%08x)\n", hwnd, style); > + > + EndDialog(hwnd, 0); Testing that EndDialog enables window would be nice (given that it's disabled as I said above). > + } > + return 0; > +} > + > static void check_dialog_style(DWORD style_in, DWORD ex_style_in, DWORD style_out, DWORD ex_style_out) > { > struct > @@ -4269,11 +4341,19 @@ static void check_dialog_style(DWORD style_in, DWORD ex_style_in, DWORD style_ou > WCHAR caption[1]; > } dlg_data; > DWORD style, ex_style; > - HWND hwnd, parent = 0; > + HWND hwnd, grand_parent = 0, parent = 0; > + struct dialog_param param; > > if (style_in & WS_CHILD) > - parent = CreateWindowExA(0, "static", NULL, WS_OVERLAPPEDWINDOW, > + { > + grand_parent = CreateWindowExA(0, "static", NULL, WS_OVERLAPPEDWINDOW, > 0, 0, 0, 0, NULL, NULL, NULL, NULL); > + ok(grand_parent != 0, "grand_parent creation failed\n"); > + } > + > + parent = CreateWindowExA(0, "static", NULL, style_in, > + 0, 0, 0, 0, grand_parent, NULL, NULL, NULL); > + ok(parent != 0, "parent creation failed, style %#x\n", style_in); Always creating window here changes existing tests. It's not a big deal, I wouldn't expect it to change much, but still, the case that's currently tested will no longer be tested. Jacek

3 6

Re: [PATCH 2/3] ole32: Fix memory leak in CompositeMonikerImpl_Construct.
by Alexandre Julliard 11 Apr '16

11 Apr '16

Alex Henrie <alexhenrie24(a)gmail.com> writes: > @@ -1848,8 +1848,10 @@ CompositeMonikerImpl_Construct(IMoniker **ppMoniker, IMoniker *pmkFirst, IMonike > IMoniker_Release(This->tabMoniker[This->tabLastIndex-1]); > > This->tabMoniker[This->tabLastIndex-1]=tempMk; > - } else > + } else{ > + HeapFree(GetProcessHeap(), 0, This); > return res; > + } You'd need to free the contents too, at least This->tabMoniker and its references. -- Alexandre Julliard julliard(a)winehq.org

1 0

wine-1.8.2-rc3 Available
by Michael Stefaniuc 11 Apr '16

11 Apr '16

Hello Alexandre, I have just pushed commit 74dbed07afbeda2e707424f1def138ec857da2b8 Author: Michael Stefaniuc <mstefani(a)winehq.org> Date: Thu Apr 7 14:25:40 2016 +0200 Release 1.8.2. as wine-1.8.2-rc3. It needs the configure change and your rubber stamp to call it 1.8.2. The only additions on top of 1.8.2-rc2 are your make_announce patch and the release commit. thanks bye michael

1 2

Re: Assorted comment, trace and ok() message spelling fixes.
by Marvin 11 Apr '16

11 Apr '16

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=22089 Your paranoid android. === w864 (32 bit d3d) === d3d.c:2326: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2510: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2657: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level === w1064 (32 bit d3d) === d3d.c:2326: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2510: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2657: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

1 0

Re: Assorted comment, trace and ok() message spelling fixes.
by Marvin 11 Apr '16

11 Apr '16

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=22088 Your paranoid android. === wvistau64 (32 bit action) === The test timed out

1 0