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

Re: [PATCH 3/3] ddraw/tests: Port D3D1_ViewportClearTest to ddraw1.c.
by Marvin 15 Feb '15

15 Feb '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=11559 Your paranoid android. === w8 (32 bit visual) === visual.c:1617: Test failed: unexpected colortable on offscreen surface

1 0

Re: [PATCH 1/3] ddraw/tests: Port D3D1_TextureMapBlendTest to ddraw1.c.
by Marvin 15 Feb '15

15 Feb '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=11557 Your paranoid android. === w8 (32 bit visual) === visual.c:1897: Test failed: unexpected colortable on offscreen surface

1 0

Re: comctl32: SysDateTimePick32 control add Alt+down hot key like windows
by Dmitry Timoshkov 15 Feb '15

15 Feb '15

"Changhui Liu" <liuchanghui(a)linuxdeepin.com> wrote: > + 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); I wouldn't be surprised if the control just does SendMessage with an appropriate message to itself. Is it possible to add a message test? > + } > + Did you miss a 'break;' or a fall through is intentiional? In the latter case please add a proper comment. -- Dmitry.

3 2

Re: [PATCH] user32: use InvalidateRect to repaint buttons
by Nikolay Sivov 15 Feb '15

15 Feb '15

On 11.02.2015 0:48, Mark Harmstone wrote: > At present, whenever a button needs to be redrawn user32 calls its own > internal function. This causes problems if the button is subclassed, as > the superclass then won't receive the WM_PAINT message - this is why > themed buttons lose their theme when you click on them. This patch changes > it to instead call InvalidateRect, which will force a WM_PAINT message > to be sent to the topmost class. > > --- > dlls/user32/button.c | 17 ++++++++--------- > 1 file changed, 8 insertions(+), 9 deletions(-) > That sounds like a case when proper fix is to reimplement themed controls in comctl32, the way Windows does that. I remember when I copied over tests for buttons to comctl32/tests I had to fix painting sequences too. To make it work properly we'll need to make comctl32 register separate classes, when loaded within context, or even better - to build two separate modules like windows does. Those separate classes should be named as "Classname!x.x.x.x", where x.x.x.x is a comctl32 version. After this done user32 needs to be fixed at CreateWindow() level to properly forward to those classes.

1 0

Re: quartz: Add stub IAMStreamSelect to MPEG-1 Stream Splitter.
by Nikolay Sivov 15 Feb '15

15 Feb '15

On 02/14/2015 07:52 PM, Anton Baskanov wrote: > + if ( IsEqualIID(riid, &IID_IUnknown) > + || IsEqualIID(riid, &IID_IPersist) > + || IsEqualIID(riid, &IID_IMediaFilter) > + || IsEqualIID(riid, &IID_IBaseFilter) ) > + *ppv = This; > + > + if ( IsEqualIID(riid, &IID_IAMStreamSelect) ) > + *ppv = &This->IAMStreamSelect_iface; > + > + if (*ppv) > + { > + IBaseFilter_AddRef(&This->Parser.filter.IBaseFilter_iface); > + return S_OK; > + } Cleaner way is to use 'iface' when setting out pointer, and for AddRef. For AddRef() it just makes it shorter, for assignment you actually have to return interface pointer instead and not to rely on implementation struct layout. > + > + if (!IsEqualIID(riid, &IID_IPin) && !IsEqualIID(riid, &IID_IVideoWindow)) > + FIXME("No interface for %s!\n", qzdebugstr_guid(riid)); Do you really need to limit it like that?

3 2

Re: kernel32/tests: Add tests for job objects
by Marvin 14 Feb '15

14 Feb '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=11532 Your paranoid android. === w2000pro (32 bit job) === job.c:169: Test failed: QueryInformationJobObject (24) job.c:172: Test failed: Expected pid_list->NumberOfProcessIdsInList to be 2 (2) is 1 job.c:174: Test failed: Expected pid_list->ProcessIdList[1] to be 872 (pi[1].dwProcessId) is 3211296 job: unhandled exception c0000005 at 00000000 === wxppro (32 bit job) === job.c:169: Test failed: QueryInformationJobObject (24) job.c:172: Test failed: Expected pid_list->NumberOfProcessIdsInList to be 2 (2) is 1 job.c:174: Test failed: Expected pid_list->ProcessIdList[1] to be 3060 (pi[1].dwProcessId) is 65535 === w2003std (32 bit job) === job.c:169: Test failed: QueryInformationJobObject (24) job.c:172: Test failed: Expected pid_list->NumberOfProcessIdsInList to be 2 (2) is 1 job.c:174: Test failed: Expected pid_list->ProcessIdList[1] to be 900 (pi[1].dwProcessId) is 0 === wvistau64 (32 bit job) === job.c:169: Test failed: QueryInformationJobObject (24) job.c:171: Test failed: Expected pid_list->NumberOfAssignedProcesses to be 2 (2) is 7479129 job.c:172: Test failed: Expected pid_list->NumberOfProcessIdsInList to be 2 (2) is 7340228 job.c:173: Test failed: Expected pid_list->ProcessIdList[0] to be 636 (pi[0].dwProcessId) is 6029360 job.c:174: Test failed: Expected pid_list->ProcessIdList[1] to be 308 (pi[1].dwProcessId) is 0 === w2008s64 (32 bit job) === job.c:169: Test failed: QueryInformationJobObject (24) job.c:171: Test failed: Expected pid_list->NumberOfAssignedProcesses to be 2 (2) is 7572569 job.c:172: Test failed: Expected pid_list->NumberOfProcessIdsInList to be 2 (2) is 7471300 job.c:173: Test failed: Expected pid_list->ProcessIdList[0] to be 2996 (pi[0].dwProcessId) is 909153100 job.c:174: Test failed: Expected pid_list->ProcessIdList[1] to be 2128 (pi[1].dwProcessId) is 167774375

1 0

Re: shell32: Implement IApplicationAssociationRegistration QueryCurrentDefault (try 7 - resend)
by Nikolay Sivov 14 Feb '15

14 Feb '15

On 13.02.2015 10:53, Alistair Leslie-Hughes wrote: I would rearrange this a bit if I was doing it to make a patch shorter, and keep conditions nesting level lower, something like: - get root key either from HKCR or HKCU; - get a path to a value; - have a single RegGetValueW() for all cases, once you know path. But that's more of a suggestion, not a blocker. > + lstrcatW(path, slash); > + lstrcatW(path, query); > + lstrcatW(path, slash); > + lstrcatW(path, choice); You could get rid of two calls if you move backslashes to 'choice' and '*assoc' strings.

1 0

Re: comctl32: SysDateTimePick32 control add Alt+down hot key like windows
by Nikolay Sivov 14 Feb '15

14 Feb '15

> + 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. > +static void test_dtm_hotkey(void) > +{ > + HWND hWnd; > + HWND hWndMonthCal; > + > + hWnd = create_datetime_control(0); > + ok(hWnd != NULL, "Expected window to be valid\n"); > + ShowWindow(hWnd, SW_NORMAL); > + > + hWndMonthCal = SendMessageA(hWnd, DTM_GETMONTHCAL, 0, 0); > + ok(hWndMonthCal != NULL, "Expected MonthCal to be valid\n"); > + ok(!IsWindowVisible(hWndMonthCal), "Expected MonthCal to be invisible\n"); > + > + SendMessageA(hWnd, WM_SYSKEYDOWN, VK_DOWN, 0); > + ok(IsWindowVisible(hWndMonthCal), "Expected MonthCal to be visible\n"); > + > + DestroyWindow(hWnd); > +} Please add notification tests too.

1 0

Official Wine coding style rules/guidelines ?
by Indrek Altpere 13 Feb '15

13 Feb '15

Hello Would it be possible to get more of the guidelines written down on the http://wiki.winehq.org/Developers-Hints or http://wiki.winehq.org/SubmittingPatches pages, to get them set in stone, so-to-speak? And also somehow show which components have different guidelines and what are they? Right now, all the information seems to get reiterated to each new developer, causing a lots of overhead to the reviewers. After being subscribed to this mailing list for a few months, I have noticed a pattern with new developers trying to submit patches: 1) first patches tend to receive lots of style related feedback 2) due to the big list of changes requested, the developers tend to miss a few with their resend and have to re-resend the patches again or due to the initial patches being too "out-of-style" the reviewers missed a few places in the first round and point them out in later round, causing the re-resend 3) sometimes the cycle goes on for quite a while And to confuse things more: 1) sometimes different reviewers have different/conflicting opinions about style rules 2) some rules are component specific, mostly set by the maintainer 3) http://wiki.winehq.org/SubmittingPatches has only general rules 3.1) "Follow the style of surrounding code as much as possible, except when it is completely impractical to do so" - there have been many cases where patches get rejected because although it was done in the style of surrounding code, the component (or wine overall) has adopted new style rules, which are not evident in the surrounding code at all. 3.2) as a minor issue, the reference to Developer-Hints in the guidelines is not linked to http://wiki.winehq.org/Developers-Hints Lots of work has already been done with the Developer-Hints page, but many issues still come up in the mailinglist that have not been mentioned there. UINT vs unsigned int, int* foo vs int *foo, -1 vs ~0U, function parameter naming (Hungarian notation ? Ok for API function definitions based on MSDN doc or not?). Officially LONG use is suggested because long differs between 64bit linux and 64bit windows. Should the developers also BOOL FLOAT etc uppercase "safe" defines everywhere or not? true/false vs TRUE/FALSE? It also seems that (at least in D3D related code) LP* usages are not allowed, LPWSTR => const WCHAR * should be used for parameters. But for example in kernel32/volume.c the LPWSTR is used in 10 places as function parameter, const WCHAR * is used in only one place as function parameter. Is the LP* rule overall rule, is it D3D specific? If overall, then why is it so widely used in all the kernel files? If D3D specific, how does the developer know it beforehand? Suggestions, comments etc ? Regards, Indrek Altpere

2 1

Re: d3dx9_36: add D3DXDisassembleShader stub (try 3)
by Matteo Bruni 13 Feb '15

13 Feb '15

2015-02-11 0:30 GMT+01:00 Austin English <austinenglish(a)gmail.com>: > > > -- > -Austin The E_OUTOFMEMORY return instead of the more typical E_NOTIMPL is slightly surprising, although I guess E_OUTOFMEMORY is possibly more likely to be handled by applications since it's listed in MSDN in the "return value" section. Anyway, this patch is okay for me.

1 0