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

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

Aug. 13, 2012

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 Aug. 13, 2012

Aug. 13, 2012

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 Aug. 13, 2012

Aug. 13, 2012

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 Aug. 12, 2012

Aug. 12, 2012

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 Aug. 10, 2012

Aug. 10, 2012

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 Aug. 10, 2012

Aug. 10, 2012

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 Aug. 9, 2012

Aug. 9, 2012

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 Aug. 9, 2012

Aug. 9, 2012

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 Aug. 8, 2012

Aug. 8, 2012

This series looks good to me.

1 0

__wine_uuidof causing a wall of "warning: returning reference to temporary" on g++
by Ilya Konstantinov Aug. 8, 2012

Aug. 8, 2012

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