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

Re: [PATCH 1/3] gdi32/tests: Make GetStockObject tests pass on East-Asian machines. (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 http://testbot.winehq.org/JobDetails.pl?Key=19269 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

June 19, 2012

Re: windowscodecs: Create a IWICMetadataReader for a TIFF frame. Take 3.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > I'm still a little worried about seeking the stream behind libtiff's > back, but otherwise it looks good. I think we can always change that if it breaks things, but I didn't see any side effects so far. -- Dmitry.

June 19, 2012

Re: windowscodecs: Create a IWICMetadataReader for a TIFF frame. Take 3.

by Vincent Povirk

I'm still a little worried about seeking the stream behind libtiff's back, but otherwise it looks good.

June 19, 2012

Re: Disabling joysticks with registry keys and joy.cpl

by Lucas Zawacki

On Mon, Jun 18, 2012 at 11:04 PM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > If you worry about devices moving around and getting different IDs - then > use part of GUID to identify driver and add device name to identify the > joystick. Yes, that seems like the way to go. I'll use the GUIDs to show the device names and disable the correct drivers using joy.cpl. I agree that disabling both the joysticks is not useful so I'll just stick with "Disable controllername"="drivername" with "linux" and "linuxinput" as options.

June 19, 2012

Re: Disabling joysticks with registry keys and joy.cpl

by Vitaliy Margolen

On 06/18/2012 12:07 PM, Lucas Zawacki wrote: > The bottom line is: can I add platform dependent code in joy.cpl for > this purpose? If that's not an option, do you have some other way to > do through joy.cpl or should it be registry only? If you use generated device GUIDs that won't be as "platform dependent" but at the same time will uniquely identify which joystick you want to disable. If you worry about devices moving around and getting different IDs - then use part of GUID to identify driver and add device name to identify the joystick. The most common use case is to have only one joystick via best working driver. Instead of 2 joysticks representing the same exact device. This means "all" would almost never be used. Another feature could be defining the order of enumeration without disabling any joysticks. In a sense creating a default device. This is an extra bonus and can be accomplished by disabling unwanted devices. So it's more of "nice to have" category. Vitaliy.

June 19, 2012

Re: [PATCH 1/4] hhctrl.ocx: Add HTML to Unicode decoding capability.

by Erich E. Hoover

On Mon, Jun 18, 2012 at 3:26 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > Am 18.06.2012 15:52, schrieb Erich E. Hoover: > ... > > Changelog: > > hhctrl.ocx: Add HTML to Unicode decoding capability. > > You're adding dead code here, you should maybe merge Patch 1 & 2 Since part 2 and 3 are both dependent upon this code I chose to do it this way in order to aid in any potential debugging and regression testing (allowing for the easy independent removal of either the ToC changes or the Index changes). So, would you prefer that I leave it; just merge part 1 and 2; or merge part 1, 2, and 3. Erich

June 19, 2012

Re: d3dx9_36: Reckonize A8B8G8R8 format

by Stefan Dösinger

Am Montag, 18. Juni 2012, 23:59:52 schrieb Stefan Dösinger: > Hi, > > Please add the format to the dds tests in dlls/d3dx9_36/tests/surface.c > > > { 32, 0x0000ffff, 0xffff0000, 0x00000000, 0x00000000, > > D3DFMT_G16R16 > > }, > > > + { 32, 0xff, 0xff00, 0xff0000, 0xff000000, D3DFMT_A8B8G8R8 }, > > The other 32 bit formats in this table have their bitmasks padded to 32 bit > with leading zeroes. Hi, I just realized that this patch was from friday and is committed already - that's ok, but the two changes still make sense I think. Stefan

June 18, 2012

Re: d3dx9_36: Reckonize A8B8G8R8 format

by Stefan Dösinger

Hi, Please add the format to the dds tests in dlls/d3dx9_36/tests/surface.c > { 32, 0x0000ffff, 0xffff0000, 0x00000000, 0x00000000, D3DFMT_G16R16 }, > + { 32, 0xff, 0xff00, 0xff0000, 0xff000000, D3DFMT_A8B8G8R8 }, The other 32 bit formats in this table have their bitmasks padded to 32 bit with leading zeroes. Stefan Am Freitag, 15. Juni 2012, 18:18:46 schrieb Nozomi Kodama: This patch solves the color problem appearing in bug 30786. Nozomi

June 18, 2012

Re: [PATCH 1/4] hhctrl.ocx: Add HTML to Unicode decoding capability.

by André Hentschel

Am 18.06.2012 15:52, schrieb Erich E. Hoover: > Real Name: > Erich Hoover > > Description: > This patch adds the ability in HTML Help to convert HTML encoded > characters (e.g. ê) into the Unicode character equivalent. This > feature is needed by the table of contents and the index for > displaying international characters in some CHM files. With this > version of the patch the code for finding the appropriate symbol has > been split out into a separate function (requested by Michael > Stefaniuc) and the string comparison has been modified to use the > larger of the two lengths (the length of the symbol to check and the > length of the symbol given in the help file). > > Changelog: > hhctrl.ocx: Add HTML to Unicode decoding capability. You're adding dead code here, you should maybe merge Patch 1 & 2 -- Best Regards, André Hentschel

June 18, 2012

Re: comctl32: hotkey control needs to invalidate itself when painting for some apps

by Dan Kegel

On Mon, Jun 18, 2012 at 11:41 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: >> + /* In some apps, the hotkey doesn't draw unless we invalidate it here */ >> + InvalidateRect(infoPtr->hwndSelf, NULL, FALSE); > > It doesn't make sense to invalidate before painting in the paint > handler. Looking at the +win log for the app in question, I see something interesting: 0009:Call window proc 0x5f401b81 (hwnd=0x10170,msg=WM_PAINT,wp=00000000,lp=00000000) trace:win:BeginPaint hdc = 0x1bc box = ((0,0)-(161,16)), fErase = 0 0009:Call window proc 0x7e2fd880 (hwnd=0x10170,msg=WM_PAINT,wp=00000000,lp=00000000) trace:win:BeginPaint hdc = 0x368 box = ((0,0)-(0,0)), fErase = 0 So the hotkey control is getting an empty update area because some other window procedure already called BeginPaint for this event. I spoke with the developer, and he agreed this is an app bug. His source subclasses the hotkey control, and in the subclass, he had MyHotkeySubclass::OnPaint() { CPaintDC foo; if (...) { handle draw here; } else { call superclass windowproc; } } The fix for the app bug is probably to move the CPaintDC inside the if. But why did this code work with native comctl32? Could this particular thinko be common enough that Microsoft implemented a workaround for it? It seems so, because when I use native comctl32, I see a similar InvalidateRect call. So, that's why I think this change belongs in wine. That said, the app developer will probably fix his (very old) bug now that I've pointed it out. - Dan

June 18, 2012