wine-devel August 2012

wine-devel@winehq.org

52 participants
118 discussions

Re: [PATCH 3/3] [Msacm32]: in acmFormatChoose, added support for template
by Dmitry Timoshkov 13 Aug '12

13 Aug '12

Eric Pouech <eric.pouech(a)orange.fr> wrote: > MMRESULT WINAPI acmFormatChooseW(PACMFORMATCHOOSEW pafmtc) > { > - return DialogBoxParamW(MSACM_hInstance32, MAKEINTRESOURCEW(DLG_ACMFORMATCHOOSE_ID), > - pafmtc->hwndOwner, FormatChooseDlgProc, (LPARAM)pafmtc); > + MMRESULT ret; > + > + if (pafmtc->fdwStyle & ACMFORMATCHOOSE_STYLEF_ENABLETEMPLATEHANDLE) > + ret = DialogBoxIndirectParamW(MSACM_hInstance32, (LPCDLGTEMPLATEW)pafmtc->hInstance, > + pafmtc->hwndOwner, FormatChooseDlgProc, (LPARAM)pafmtc); > + else if (pafmtc->fdwStyle & ACMFORMATCHOOSE_STYLEF_ENABLETEMPLATE) > + ret = DialogBoxParamW(pafmtc->hInstance, pafmtc->pszTemplateName, > + pafmtc->hwndOwner, FormatChooseDlgProc, (LPARAM)pafmtc); > + else > + ret = DialogBoxParamW(MSACM_hInstance32, MAKEINTRESOURCEW(DLG_ACMFORMATCHOOSE_ID), > + pafmtc->hwndOwner, FormatChooseDlgProc, (LPARAM)pafmtc); > + return ret; > } It would look much better without all those 'ret' + 'else' things. -- Dmitry.

2 3

Re: [PATCH 2/4] wined3d: Fix pixel format alpha/red masks.
by Henri Verbeet 13 Aug '12

13 Aug '12

On 13 August 2012 20:20, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + * Pixel formats with more than 4 bpp do not have correct masks, because the > + * high masks do not fit into the 32 bit values needed for ddraw. The masks > + * are only used for ddraw mostly, and to figure out if the format has an alpha > + * component (the POSTPIXELSHADER_BLENDING test also uses those masks to know > + * if there is more than 1 alpha bit and a red component), so that doesn't > + * matter. The 64 and 128 bit formats are not supported by ddraw anyway. > */ We'll probably want these as offset + mask, or perhaps offset + size.

1 0

Re: joy.cpl: Corrected misplaced elements when using high DPIs
by Alexandre Julliard 13 Aug '12

13 Aug '12

Lucas Zawacki <lfzawacki(a)gmail.com> writes: > From: Lucas Zawacki <lfzawacki(a)gmail.com> > > Fixes bug #31316 > > joy.cpl uses CreateWindow and SetWindowPos to draw some elements > and the hardcoded coordinates where wrong when the dpi was set to anything > bigger than 96px in winecfg. My approach to solve is normalize the > coordinates based on the dialog window size. You probably want to use MapDialogRect instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

_vcomp_fork stack frame puzzle
by Dan Kegel 12 Aug '12

12 Aug '12

Having fun trying to figure out what's in the black box of _vcomp_fork(), the helper function that spawns threads in Visual C's OpenMP support library. The C source code #include <stdio.h> #include <omp.h> int main(int argc, char **argv) { double d; double e; int i; printf("&d is %p, &e is %p\n", &d, &e); #pragma omp parallel for for (i=0; i<3; i++) { printf("&d is %p\n", &d); } #pragma omp parallel for for (i=0; i<3; i++) { printf("&d is %p, &e is %p\n", &d, &e); } return 0; } when compiled with cl /MD /openmp /FAs odd.c generates an .exe and a mixed assembly / source .asm listing. The compiler puts the loop into a helper function, and invokes the helper using _vcomp_fork(), which is called with a flag saying whether to parallelize, a pointer to the helper function, a count, and then a pointer to each variable referenced by the loop from the outer scope. The code in the helper function knows to get the addresses of the variables from the stack. When run with native vcomp.dll, this prints out the right addresses inside the loop. When run with my slightly less stubby builtin vcomp patch attached to http://bugs.winehq.org/show_bug.cgi?id=26688 (based on Andre's earlier patch), it prints out garbage. It seems like Andre's varargs code should be right, but something's not connecting. I even tried beer, and it still didn't work. I guess I should fire up a debugger and see what's going on, but I don't want to accidentally see too much about what native's doing. Suggestions, anyone? - Dan

2 5

Wiki is down
by Austin English 10 Aug '12

10 Aug '12

Mind taking a look? :) Have a great weekend! -- -Austin

2 1

Re: user32: Menu should not be activated by menu key while mouse buttons are down.
by Jan Boon 10 Aug '12

10 Aug '12

Okay, will write a test case later today or tomorrow. When trying to fix the issue I had, I noticed that in the function where it currently handles the logic for the menu key, it only received messages WM_MOUSEACTIVATE on pressing and WM_CAPTURECHANGED on release (in the tested application), but no mouse down or up messages, which caused the mouse down not to set the iMenuSysKey to 0 if the mouse button was pressed after holding alt (and additionally it also needs to not select the menu either when hitting alt while the mouse button is already down). (Also, when trying this manually on linux, gnome desktop wm mouse-button-modifier should be changed from Alt to something else, because it intercepts the alt-mouse combos before wine sees them it seems.) So, since the function is not receiving all the messages here, which I assume are not all forwarded to the default handler by 3ds Max, would it be better to hook into the messages or mouse status at an earlier point in the code (to handle the first case where the mouse is pressed after alt)? And is there a saner way that can be used here to check if the mouse is down (when alt is pressed after mouse down)? On Fri, Aug 10, 2012 at 8:14 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Jan Boon <jan.boon(a)kaetemi.be> wrote: > > > Fix for bug #31434. > > 1. this kind of change requires a test case, some of the changes look wrong > 2. formatting is broken due to not standard tab size > 3. patch introduces compile-time warnings, that's not accepatable > > -- > Dmitry. >

1 0

Re: [01/17] gdiplus: Add more tests for GdipMeasureString using device with custom resolution. Take 4.
by Vincent Povirk 09 Aug '12

09 Aug '12

Other than patch 15 the series looks good to me, and I've seen or thought about most of this before, but do you really have to send a series of 17 patches at once?

2 1

Re: [15/17] gdiplus: Delete GDI objects once they are not needed anymore.
by Vincent Povirk 09 Aug '12

09 Aug '12

This will break text rendering. We need the correct font to be selected on the hdc during the call to gdip_format_string.

2 3

Re: [1/4] gdiplus: Add a test for GdipDrawImage scaling.
by Vincent Povirk 08 Aug '12

08 Aug '12

This series looks good to me.

1 0

__wine_uuidof causing a wall of "warning: returning reference to temporary" on g++
by Ilya Konstantinov 08 Aug '12

08 Aug '12

Hi, I've just started porting my C++ application to Linux with Winelib. Upon first attempts to compile, I've received a wall of "warning: returning reference to temporary" on Wine's headers from g++. All of those seem to stem from guidgen.h definition of __wine_uuidof / __CRT_UUID_DECL for C++. All in all, g++ seems to be right -- we are indeed returning a reference to a IID struct that's allocated on the stack. If I remove the '&' in this definition (in guidgen.h): template<typename T> const GUID &__wine_uuidof(); the warnings stop, but then I wonder, did the original author have some good reasoning for returning a reference in the first place? Thanks.

2 4

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 August 2012