wine-devel November 2015

wine-devel@winehq.org

69 participants
272 discussions

Setting some windows relations.
by John Found 21 Nov '15

21 Nov '15

Hi All. I am developing in Linux a GUI toolkit, that has port for Windows and I test in under WINE. Surprisingly, I stuck on two problems that look different, but probably has the same origin. The first is the setting of the owner window for the modal dialogs. In Windows it is common practice to set it through SetWindowLong with GWL_HWNDPARENT and it works - the owner window stay always under the . In WINE, setting the owner this way does not work. The owner window can be raised above the modal dialog. On the other hand, setting the hWndParent in CreateWindowEx works as intended. The problem is that when I create the dialog window I don't know the owner window I will use later and it can change during program execution. The second problem is with the windows that have to change from WS_POPUP to WS_OVERLAPPED and back by the same SetWindowLong. When I create a window as WS_OVERLAPPED and then change the style to WS_POPUP, the window looks like WS_POPUP, but does not behave as such. For example in Linux it has override_redirect=0, steals the focus from the main window, etc. When the window is created initially with WS_POPUP, nothing of this happens. Again in Windows, changing the style by SetWindowLong works as intended. Is there some simple workaround of these problems? In order to fight it I must redesign the whole library in order to create the windows with the right parameters. Some of the features I want to make need to destroy the windows and recreate them instead of simply change the needed parameters. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound(a)asm32.info>

4 9

Re: [PATCH 1/2] kernel32: Use correct virtual-key code for the Delete key when using wineconsole
by Alexandre Julliard 20 Nov '15

20 Nov '15

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > VK_DEL is 0x2e. The existing code used 127 (0x7F), which is VK_F16. These are character codes, not vkeys. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: mshtml: Make msec argument of setTimeout optional.
by Marvin 20 Nov '15

20 Nov '15

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=18383 Your paranoid android. === wxppro (32 bit) === No test summary line found === w2003std (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w7pro64 (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === w864 (32 bit) === No test summary line found === w1064 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found === w7pro64 (64 bit) === No test summary line found === w864 (64 bit) === No test summary line found === w1064 (64 bit) === No test summary line found

2 1

Re: [PATCH 1/3 v2] winex11.drv: Send WM_DROPFILES if IDropTarget_Drop failed or DROPEFFECT_NONE was set
by Piotr Caban 20 Nov '15

20 Nov '15

Hi Damjan, On 11/20/15 11:43, Piotr Caban wrote: > With these patches OLE Drag&Drop still doesn't behave exactly the same > as on Windows. E.g. IDropTarget::* failures or DROPEFFECT_NONE are > handled incorrectly in some places. I'm planning to send more patches > after code freeze. Here are the patches I'm planning to send after the code freeze (generated on top of this series). Thanks, Piotr

1 0

Re: [PATCH] d3d11: OMSetBlendState blend states is optional (try 2)
by Józef Kucia 20 Nov '15

20 Nov '15

Hi, The subject is not very accurate. On Thu, Nov 19, 2015 at 10:29 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Fixed failed tests. > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/d3d11/device.c | 7 ++++++- > dlls/d3d11/tests/d3d11.c | 2 ++ > 2 files changed, 8 insertions(+), 1 deletion(-) > > diff --git a/dlls/d3d11/device.c b/dlls/d3d11/device.c > index f2bc4d6..c6e54cf 100644 > --- a/dlls/d3d11/device.c > +++ b/dlls/d3d11/device.c > @@ -603,10 +603,15 @@ static void STDMETHODCALLTYPE d3d11_immediate_context_OMSetRenderTargetsAndUnord > } > > static void STDMETHODCALLTYPE d3d11_immediate_context_OMSetBlendState(ID3D11DeviceContext *iface, > - ID3D11BlendState *blend_state, const FLOAT blend_factor[4], UINT sample_mask) > + ID3D11BlendState *blend_state, const FLOAT arg_blend_factor[4], UINT sample_mask) > { > struct d3d_device *device = device_from_immediate_ID3D11DeviceContext(iface); > const D3D11_BLEND_DESC *desc; > + const FLOAT blend_default[4] = {1.0f, 1.0f, 1.0f, 1.0f}; > + const FLOAT *blend_factor = blend_default; > + > + if(arg_blend_factor) > + blend_factor = arg_blend_factor; There is a missing space after "if". > > TRACE("iface %p, blend_state %p, blend_factor {%.8e %.8e %.8e %.8e}, sample_mask 0x%08x.\n", > iface, blend_state, blend_factor[0], blend_factor[1], blend_factor[2], blend_factor[3], sample_mask); We should print actual arguments. If blend_factor is allowed to be NULL it should be treated as a pointer. > diff --git a/dlls/d3d11/tests/d3d11.c b/dlls/d3d11/tests/d3d11.c > index 7021c6f..f42edf7 100644 > --- a/dlls/d3d11/tests/d3d11.c > +++ b/dlls/d3d11/tests/d3d11.c > @@ -2777,6 +2777,8 @@ static void test_blend(void) > > ID3D11DeviceContext_ClearRenderTargetView(context, backbuffer_rtv, red); > > + ID3D11DeviceContext_OMSetBlendState(context, src_blend, NULL, D3D11_DEFAULT_SAMPLE_MASK); > + A test showing that passing NULL to OmSetBlendState() resets the blend factor to (1.0, 1.0, 1.0 ,1.0) would be useful. Unfortunately, d3d11_immediate_context_OMGetBlendState() is not implemented yet. Also, the test_blend() is not the best place for this test as it is a visual test. The test should be probably placed in test_clear_state() but it is not ported from d3d10core tests yet. I think the best way would be to fix this issue in D3D10 as well and add a test in test_clear_state(). The test_clear_state() will be eventually ported to d3d11 tests. Thanks, Józef Kucia

1 0

Re: [PATCH] server: Trace process ID.
by Alexandre Julliard 20 Nov '15

20 Nov '15

Qian Hong <qhong(a)codeweavers.com> writes: > Signed-off-by: Qian Hong <qhong(a)codeweavers.com> > --- > server/request.h | 1 + > server/trace.c | 12 ++++++------ > 2 files changed, 7 insertions(+), 6 deletions(-) There are a lot more places that would have to be changed, but I'm not sure it's worth making all the traces larger for this. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] d3d11/test: Stop crash when CreateBlendState fails
by Józef Kucia 20 Nov '15

20 Nov '15

Hi, The subject prefix is wrong. It should be "d3d11/tests:". On Fri, Nov 20, 2015 at 7:51 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/d3d11/tests/d3d11.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/dlls/d3d11/tests/d3d11.c b/dlls/d3d11/tests/d3d11.c > index f42edf7..95ba8c0 100644 > --- a/dlls/d3d11/tests/d3d11.c > +++ b/dlls/d3d11/tests/d3d11.c > @@ -2139,6 +2139,11 @@ static void test_create_blend_state(void) > > hr = ID3D11Device_CreateBlendState(device, current_desc, &blend_state1); > ok(SUCCEEDED(hr), "Failed to create blend state, hr %#x.\n", hr); > + if (FAILED(hr)) > + { > + win_skip("Failed to create CreateBlendState, skipping test %u.\n", i); > + continue; > + } At this point the test already failed so there is no point to continue. What we should do is determine if CreateBlendState() should succeed or fail based on the device feature level. win_skip() is not correct as we won't be able to support independent blending on lower feature levels in Wine. Thanks, Józef Kucia

1 0

Re: [3/3] user32: Change value for WM_MDICALCCHILDSCROLL to 0x003f.
by Alexandre Julliard 20 Nov '15

20 Nov '15

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > This appears to be what Windows uses. Is there an app where this makes a difference, or is it just because of the test? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: advapi32: Add a manifest to prevent registry virtualization.
by Alexandre Julliard 20 Nov '15

20 Nov '15

Vincent Povirk <madewokherd(a)gmail.com> writes: > While we could modify our test to detect this seemingly impossible > situation, I think it's better to just prevent registry > virtualization. (Then again, if we ever want to write tests for > registry virtualization, they should probably go in advapi32, so maybe > editing the test is better.) We will want to add tests for virtualization, so yes, I think that fixing the test would be preferable. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [3/3] user32: Change value for WM_MDICALCCHILDSCROLL to 0x003f.
by Marvin 20 Nov '15

20 Nov '15

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=18381 Your paranoid android. === w8 (32 bit win) === win.c:3601: Test failed: hwnd 00020114 message 0118 === w1064 (32 bit win) === win.c:6842: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6864: Test failed: 0x80/0x1010000: window rect 0,0-1024,768 win.c:6842: Test failed: 0x80/0x81c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6842: Test failed: 0/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6842: Test failed: 0x40000/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6842: Test failed: 0x80/0x41c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6842: Test failed: 0x80/0x1c50000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6864: Test failed: 0x80/0x1050000: window rect 0,0-1024,768 win.c:6842: Test failed: 0x80/0x1c10000: window rect 0,0-1024,768 must be in 0,0-1024,728 win.c:6864: Test failed: 0x80/0x1410000: window rect 0,0-1024,768 === w864 (64 bit win) === win.c:3601: Test failed: hwnd 000000000002019A message 0118

1 0

← Newer
1
...
7
8
9
10
11
12
13
...
28
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel November 2015