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

Re: [PATCH 2/2] comctl32: Correct values passed in MCN_SELECT/MCN_SELCHANGE notifications.

by Nikolay Sivov

On Thu, Aug 16, 2012 at 5:20 PM, Sergey Guralnik <serhio(a)etersoft.ru> wrote: > > -- > Sergey > > > You can use simple assignment with st_null instead of that: + memset(&nmsc.stSelEnd, 0, sizeof nmsc.stSelEnd);

Aug. 16, 2012

Re: [PATCH 2/2] comctl32: Correct values passed in MCN_SELECT/MCN_SELCHANGE notifications.

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 http://testbot.winehq.org/JobDetails.pl?Key=20934 Your paranoid android. === WNT4WSSP6 (32 bit monthcal) === monthcal.c:1257: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === W2KPROSP4 (32 bit monthcal) === monthcal.c:1257: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === WXPPROSP3 (32 bit monthcal) === monthcal.c:1257: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === W2K3R2SESP2 (32 bit monthcal) === monthcal.c:1257: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === WVISTAADM (32 bit monthcal) === monthcal.c:1257: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === W2K8SE (32 bit monthcal) === monthcal.c:1257: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === W7PRO (32 bit monthcal) === monthcal.c:1257: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === W7PROX64 (32 bit monthcal) === monthcal.c:1257: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === TEST64_W7SP1 (32 bit monthcal) === monthcal.c:1257: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === W7PROX64 (64 bit monthcal) === monthcal.c:1257: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === TEST64_W7SP1 (64 bit monthcal) === monthcal.c:1257: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead

Aug. 16, 2012

Re: [PATCH 2/2] comctl32: Correct values passed in MCN_SELECT/MCN_SELCHANGE notifications.

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 http://testbot.winehq.org/JobDetails.pl?Key=20934 Your paranoid android. === WNT4WSSP6 (32 bit monthcal) === monthcal.c:1257: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === W2KPROSP4 (32 bit monthcal) === monthcal.c:1257: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === WXPPROSP3 (32 bit monthcal) === monthcal.c:1257: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === W2K3R2SESP2 (32 bit monthcal) === monthcal.c:1257: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === WVISTAADM (32 bit monthcal) === monthcal.c:1257: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === W2K8SE (32 bit monthcal) === monthcal.c:1257: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === W7PRO (32 bit monthcal) === monthcal.c:1257: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === W7PROX64 (32 bit monthcal) === monthcal.c:1257: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === TEST64_W7SP1 (32 bit monthcal) === monthcal.c:1257: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === W7PROX64 (64 bit monthcal) === monthcal.c:1257: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === TEST64_W7SP1 (64 bit monthcal) === monthcal.c:1257: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead

Aug. 16, 2012

Re: [PATCH 1/2] comctl32/tests: Add test for MCN_SELECT/MCN_SELCHANGE notifications.

by Sergey Guralnik

On 2012-08-16 16:28, Marvin wrote: > > === WNT4WSSP6 (32 bit monthcal) === > monthcal.c:1258: Test failed: monthcal hit test: the msg 0x000f was > expected, but got msg 0x1001 instead > This is unrelated to my patch. -- Sergey

Aug. 16, 2012

Re: [PATCH 1/2] comctl32/tests: Add test for MCN_SELECT/MCN_SELCHANGE notifications.

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 http://testbot.winehq.org/JobDetails.pl?Key=20933 Your paranoid android. === WNT4WSSP6 (32 bit monthcal) === monthcal.c:1258: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === W2KPROSP4 (32 bit monthcal) === monthcal.c:1258: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === WXPPROSP3 (32 bit monthcal) === monthcal.c:1258: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === W2K3R2SESP2 (32 bit monthcal) === monthcal.c:1258: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === WVISTAADM (32 bit monthcal) === monthcal.c:1258: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === W2K8SE (32 bit monthcal) === monthcal.c:1258: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === W7PRO (32 bit monthcal) === monthcal.c:1258: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === W7PROX64 (32 bit monthcal) === monthcal.c:1258: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === TEST64_W7SP1 (32 bit monthcal) === monthcal.c:1258: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === W7PROX64 (64 bit monthcal) === monthcal.c:1258: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead === TEST64_W7SP1 (64 bit monthcal) === monthcal.c:1258: Test failed: monthcal hit test: the msg 0x000f was expected, but got msg 0x1001 instead

Aug. 16, 2012

Re: winedbg: Use standard fixed pitch UI font for the crash dialog.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > > To clarify things a bit: current code uses empty font face name, and GDI > > uses "System" font in that case (regardless of requested FIXED_PITCH), which > > is absolutely not readable. ANSI_FIXED_FONT should use built-in "Courier", > > which is actually a FIXED_PITCH font and much more readable. > > For me every tab is replaced by a black square, so it doesn't look all > that good... That's a not related problem. If that's all that prevents this patch from being accepted I could have a look at the font bitmaps and fix it. -- Dmitry.

Aug. 16, 2012

Re: comdlg32: Use proper helpers for iface calls

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 http://testbot.winehq.org/JobDetails.pl?Key=20929 Your paranoid android. === TEST64_W7SP1 (32 bit itemdlg) === itemdlg: unhandled exception c0000005 at 75AF1AC3

Aug. 16, 2012

Re: [PATCH 1/4] include/wine/test.h: Added wine_dbgstr_a[n] to test framwork.

by Qian Hong

On Thu, Aug 16, 2012 at 4:55 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > > This shouldn't be necessary, you can use a simple printf. Functions > should only be added to test.h if there's a clear need across a wide > range of tests. Thanks for review! Will provide an updated patch set soon. -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

Aug. 16, 2012

Re: winedbg: Use standard fixed pitch UI font for the crash dialog.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > >> static void set_fixed_font( HWND dlg, UINT id ) >> { >> - HFONT hfont = (HFONT)SendDlgItemMessageW( dlg, id, WM_GETFONT, 0, 0); >> - LOGFONTW font; >> + HFONT hfont; >> >> - GetObjectW(hfont, sizeof(LOGFONTW), &font); >> - font.lfPitchAndFamily = FIXED_PITCH; >> - font.lfFaceName[0] = 0; >> - hfont = CreateFontIndirectW(&font); >> + hfont = GetStockObject( ANSI_FIXED_FONT ); >> SendDlgItemMessageW( dlg, id, WM_SETFONT, (WPARAM)hfont, TRUE ); >> } > > To clarify things a bit: current code uses empty font face name, and GDI > uses "System" font in that case (regardless of requested FIXED_PITCH), which > is absolutely not readable. ANSI_FIXED_FONT should use built-in "Courier", > which is actually a FIXED_PITCH font and much more readable. For me every tab is replaced by a black square, so it doesn't look all that good... -- Alexandre Julliard julliard(a)winehq.org

Aug. 16, 2012

Re: [PATCH] kernel32: add support for CAL_ICALINTVALUE

by Michael Blumenkrantz

Perhaps not, but I'll be the first to admit that I know very little about wine internals; this seemed to return the correct result in the case that I tested it. On Thu, Aug 16, 2012 at 11:39 AM, Alexandre Julliard <julliard(a)winehq.org>wrote: > Michael Blumenkrantz <michael.blumenkrantz(a)gmail.com> writes: > > > @@ -656,8 +656,8 @@ int WINAPI GetCalendarInfoW(LCID Locale, CALID > Calendar, CALTYPE CalType, > > * for the CALTYPES not requiring GetLocaleInfoA */ > > switch (CalType & > ~(CAL_NOUSEROVERRIDE|CAL_RETURN_NUMBER|CAL_USE_CP_ACP)) { > > case CAL_ICALINTVALUE: > > - FIXME("Unimplemented caltype %d\n", CalType & 0xffff); > > - return 0; > > + return GetLocaleInfoW(Locale, > LOCALE_RETURN_NUMBER|LOCALE_ICALENDARTYPE, > > + (LPWSTR)lpValue, > sizeof(CALID)/sizeof(WCHAR)); > > I doubt that you want to hardcode LOCALE_RETURN_NUMBER here. > > -- > Alexandre Julliard > julliard(a)winehq.org >

Aug. 16, 2012

Re: [PATCH] kernel32: add support for CAL_ICALINTVALUE

by Alexandre Julliard

Michael Blumenkrantz <michael.blumenkrantz(a)gmail.com> writes: > @@ -656,8 +656,8 @@ int WINAPI GetCalendarInfoW(LCID Locale, CALID Calendar, CALTYPE CalType, > * for the CALTYPES not requiring GetLocaleInfoA */ > switch (CalType & ~(CAL_NOUSEROVERRIDE|CAL_RETURN_NUMBER|CAL_USE_CP_ACP)) { > case CAL_ICALINTVALUE: > - FIXME("Unimplemented caltype %d\n", CalType & 0xffff); > - return 0; > + return GetLocaleInfoW(Locale, LOCALE_RETURN_NUMBER|LOCALE_ICALENDARTYPE, > + (LPWSTR)lpValue, sizeof(CALID)/sizeof(WCHAR)); I doubt that you want to hardcode LOCALE_RETURN_NUMBER here. -- Alexandre Julliard julliard(a)winehq.org

Aug. 16, 2012

Re: winedbg: Use standard fixed pitch UI font for the crash dialog.

by Dmitry Timoshkov

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > static void set_fixed_font( HWND dlg, UINT id ) > { > - HFONT hfont = (HFONT)SendDlgItemMessageW( dlg, id, WM_GETFONT, 0, 0); > - LOGFONTW font; > + HFONT hfont; > > - GetObjectW(hfont, sizeof(LOGFONTW), &font); > - font.lfPitchAndFamily = FIXED_PITCH; > - font.lfFaceName[0] = 0; > - hfont = CreateFontIndirectW(&font); > + hfont = GetStockObject( ANSI_FIXED_FONT ); > SendDlgItemMessageW( dlg, id, WM_SETFONT, (WPARAM)hfont, TRUE ); > } To clarify things a bit: current code uses empty font face name, and GDI uses "System" font in that case (regardless of requested FIXED_PITCH), which is absolutely not readable. ANSI_FIXED_FONT should use built-in "Courier", which is actually a FIXED_PITCH font and much more readable. -- Dmitry.

Aug. 15, 2012

Re: windowscodecs: Implement Palette_InitializeFromBitmap.

by Vincent Povirk

>> This does not agree with MSDN's description of the function. >> >> According to MSDN, InitializeFromBitmap should compute a palette based >> on the contents of the (presumably) non-paletted bitmap data. > > For a bitmap with palette my implementation should be good enough. For a bitmap with a palette you can easily end up with too many colors, and no transparent color when one is requested. It doesn't get us any closer to a real implementation, and if we had one it would always be preferable this one. That case of a bitmap with a palette is exactly when the method is least likely to be used, so mostly you're just leaving the problem and making it harder to identify the cause.

Aug. 14, 2012

Re: windowscodecs: Implement Palette_InitializeFromBitmap.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > This does not agree with MSDN's description of the function. > > According to MSDN, InitializeFromBitmap should compute a palette based > on the contents of the (presumably) non-paletted bitmap data. For a bitmap with palette my implementation should be good enough. -- Dmitry.

Aug. 14, 2012

Re: Use WM_PAINT to redraw button instead of directly calling unthemed paint routine

by Roderick Colenbrander

On Tue, Aug 14, 2012 at 6:28 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Ruslan Kabatsayev <b7.10110111(a)gmail.com> wrote: > >> This patch makes buttons render correctly themed in various cases when >> e.g. they are pressed and released, made active etc. Without this >> patch they look win95-like in such cases even if desktop integration >> is used. > > Let me guess, you didn't run 'make test' with these changes? > > -- > Dmitry. > > Hi Ruslan, The way theming is currently implemented in Wine is incorrect. Let me explain and for more details go through wine-devel archives. Currently we subclass relevant controls within comctl32 in order to theming. This allowed us to share the core implementation (which is in user32) between theming and non-theming. As you noticed there are drawing issues. Patches like the one you submitted 'fix' drawing issues, but they will applications because they generate events which don't happen on win32 for themed and non-themed buttons. There is no way to make these tests pass in the current architecture. What we have to do is it do what Microsoft did for theming. For comctl32 v6 they duplicated every control in comctl32 (before they were in user32). Each of the new implementations can do theming itself. This is quite a bit of work. The main thing which we have to think of is how to deal with our unit tests. We have thousands of tests for controls which are currently in user32 and which may have to be duplicated unless there is another solution. Bottom line is that it's best to forget about the current theming code in Wine. We have to figure out how to move forward with theming. Roderick

Aug. 14, 2012

Re: windowscodecs: Implement Palette_InitializeFromBitmap.

by Vincent Povirk

This does not agree with MSDN's description of the function. According to MSDN, InitializeFromBitmap should compute a palette based on the contents of the (presumably) non-paletted bitmap data.

Aug. 14, 2012

Re: Use WM_PAINT to redraw button instead of directly calling unthemed paint routine

by Dmitry Timoshkov

Ruslan Kabatsayev <b7.10110111(a)gmail.com> wrote: > This patch makes buttons render correctly themed in various cases when > e.g. they are pressed and released, made active etc. Without this > patch they look win95-like in such cases even if desktop integration > is used. Let me guess, you didn't run 'make test' with these changes? -- Dmitry.

Aug. 14, 2012

Re: [4/5] windowscodecs: Add test for IWICMetadataReaderInfo.

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 http://testbot.winehq.org/JobDetails.pl?Key=20875 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Aug. 14, 2012

Re: [4/5] windowscodecs: Add test for IWICMetadataReaderInfo.

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 http://testbot.winehq.org/JobDetails.pl?Key=20871 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Aug. 14, 2012

Re: [05/17] gdiplus: GdipMeasureString should apply its internal scaling factors to layout rectangle.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > This fails here on 64-bit: > > ../../../../wine/tools/runtest -q -P wine -M gdiplus.dll -T ../../.. -p gdiplus_test.exe.so ../../../../wine/dlls/gdiplus/tests/graphics.c && touch graphics.ok > graphics.c:3609: Test failed: Expected 100.000000, got 98.999786 > graphics.c:3609: Test failed: Expected 100.000000, got 98.999786 > graphics.c:3609: Test failed: Expected 100.000000, got 98.999786 > graphics.c:3609: Test failed: Expected 100.000000, got 98.999786 Changing the precision should help I'd guess. I'll resend if manually adjusting the patch is not acceptable. -- Dmitry.

Aug. 14, 2012

Re: [05/17] gdiplus: GdipMeasureString should apply its internal scaling factors to layout rectangle.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > --- > dlls/gdiplus/graphics.c | 10 ++++++++-- > dlls/gdiplus/tests/graphics.c | 29 ----------------------------- > 2 files changed, 8 insertions(+), 31 deletions(-) This fails here on 64-bit: ../../../../wine/tools/runtest -q -P wine -M gdiplus.dll -T ../../.. -p gdiplus_test.exe.so ../../../../wine/dlls/gdiplus/tests/graphics.c && touch graphics.ok graphics.c:3609: Test failed: Expected 100.000000, got 98.999786 graphics.c:3609: Test failed: Expected 100.000000, got 98.999786 graphics.c:3609: Test failed: Expected 100.000000, got 98.999786 graphics.c:3609: Test failed: Expected 100.000000, got 98.999786 make: *** [graphics.ok] Error 4 -- Alexandre Julliard julliard(a)winehq.org

Aug. 14, 2012

Re: [PATCH 4/4] ole32: Added ISynchronizeHandle tests

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 http://testbot.winehq.org/JobDetails.pl?Key=20841 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Aug. 14, 2012

Re: user32: search more aggressively for a window under a tooltip

by Alexandre Julliard

Daniel Jelinski <djelinski1(a)gmail.com> writes: > 2012/7/23 Alexandre Julliard <julliard(a)winehq.org>: >> Daniel Jelinski <djelinski1(a)gmail.com> writes: >> >>> 2012/7/23, Alexandre Julliard <julliard(a)winehq.org>: >>>> You can't assume that the other Wine window is directly underneath the >>>> transparent one, there may be some other X windows in between that >>>> should receive the click instead. >>> >>> I just determined that in such cases Windows (at least 2008) silently >>> eats the event - no windows get any click events. I can send the >>> application (VS, C++) I used for testing. >>> >>> Should I update the patch to reflect that? >> >> Sure, and please add a test case too. >> > > I just noticed that my patch for HTTRANSPARENT was rejected again. > Were the tests not convincing enough? It's still wrong if the windows belong to the same thread. -- Alexandre Julliard julliard(a)winehq.org

Aug. 14, 2012

Re: Have there been any problems with Wine on GCC 4.7?

by Scott Ritchie

On 8/13/12 12:55 PM, Eric Pouech wrote: > >> diff --git a/configure.ac b/configure.ac >> index 4bd43d1..c80fd8a 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -1746,6 +1746,8 @@ then >> WINE_TRY_CFLAGS([-Wtype-limits]) >> WINE_TRY_CFLAGS([-Wunused-but-set-parameter]) >> WINE_TRY_CFLAGS([-Wwrite-strings]) >> + WINE_TRY_CFLAGS([-gdwarf-2]) >> + WINE_TRY_CFLAGS([-gstrict-dwarf]) >> >> dnl gcc-4.6+ omits frame pointers by default, breaking some copy >> protections >> case $host_cpu in >> >> would be simpler, unless I'm missing something. >> > would work too (even if this would be preferable) > > + WINE_TRY_CFLAGS([-gdwarf-2 -gstrict-dwarf]) > Or I could not patch Wine itself and instead patch it's build instructions in the package rules file. But if Wine indeed doesn't work with GCC's new default settings then it should probably be a Wine page (for every distro)

Aug. 13, 2012

Re: user32: search more aggressively for a window under a tooltip

by Daniel Jelinski

2012/7/23 Alexandre Julliard <julliard(a)winehq.org>: > Daniel Jelinski <djelinski1(a)gmail.com> writes: > >> 2012/7/23, Alexandre Julliard <julliard(a)winehq.org>: >>> You can't assume that the other Wine window is directly underneath the >>> transparent one, there may be some other X windows in between that >>> should receive the click instead. >> >> I just determined that in such cases Windows (at least 2008) silently >> eats the event - no windows get any click events. I can send the >> application (VS, C++) I used for testing. >> >> Should I update the patch to reflect that? > > Sure, and please add a test case too. > I just noticed that my patch for HTTRANSPARENT was rejected again. Were the tests not convincing enough? Regards, Daniel

Aug. 13, 2012