Bug 3467 needs this change.
But I can write a small test. Would writing a test attaching an offscreen
surface to another offscreen surface be enough to convince you of the
correctness of the change?
Indeed, only Z-buffer surfaces can be attached in version 7 of the metho.
Thanks in advance
A+
I have published version 0.0.4 of Wine Mono on Sourceforge. I fully
intend to make this release a part of Wine.
The source tarball is at
http://sourceforge.net/projects/wine/files/Wine%20Mono/0.0.4/wine-mono-0.0.4.tar.gz/download
The binary is at
http://sourceforge.net/projects/wine/files/Wine%20
2012/5/14 Stefan Dösinger :
> Am Sonntag, 13. Mai 2012, 20:39:27 schrieb David Adam:
>> + hr = ddraw_surface3_AddAttachedSurface(&This-
>>IDirectDrawSurface3_iface,
>> + attachment_impl ? &attachment_impl->IDirectDrawSurface3_iface :
> NULL);
> It isn't immediately clear to me why Sur
2012/5/14 Giovanni Ongaro :
> I have written a modification of the xinput1_3 dll that simulates xbox
> joystick with a logitech rumblepad 2 joystick,also provided is a way to
> disable dinput joysticks through an environment variable, it seems to
> work well,may it be of interest to the wine projec
Looks good to me.
I have written a modification of the xinput1_3 dll that simulates xbox
joystick with a logitech rumblepad 2 joystick,also provided is a way to
disable dinput joysticks through an environment variable, it seems to
work well,may it be of interest to the wine project?
On 5/14/2012 19:34, André Hentschel wrote:
Otherwise GTA San Andreas runs into it and crashes. This stub let's it work
again.
a workaround is to disable wmvcore in winecfg...
---
dlls/wmvcore/wmvcore.spec |2 +-
dlls/wmvcore/wmvcore_main.c |8
2 files changed, 9 insertions
On 5/13/12 10:00 AM, wine-devel-requ...@winehq.org wrote:
How many of you use an Integrated Development Environment (IDE) when
working on Wine?
If you do, which one do you use and how, how useful is it and how hard
was it to set up?
I use Qt Creator for Linux for our winelib application. Our
Vincent Povirk wrote:
> OK, but if the rect passed to GdipDrawString has a non-zero width, and
> depending on the string formatting options, GdipDrawString may wrap
> the text. GdipMeasureString will not wrap the text if you call it with
> a width of 0.
That's a good point, thanks.
--
Dmitry.
Am Montag, 14. Mai 2012, 17:24:01 schrieb Matteo Bruni:
> -CopyMemory(pos, messages, strlen(messages) + 1);
> +memcpy(pos, messages, strlen(messages) + 1);
> ...
> -if (shader == NULL)
> +if (!shader)
This looks unrelated. The changes are OK, but should be in another
Am Sonntag, 13. Mai 2012, 20:39:27 schrieb David Adam:
> +hr = ddraw_surface3_AddAttachedSurface(&This-
>IDirectDrawSurface3_iface,
> +attachment_impl ? &attachment_impl->IDirectDrawSurface3_iface :
NULL);
It isn't immediately clear to me why Surface3 is correct instead of Surface7
OK, but if the rect passed to GdipDrawString has a non-zero width, and
depending on the string formatting options, GdipDrawString may wrap
the text. GdipMeasureString will not wrap the text if you call it with
a width of 0.
On Mon, May 14, 2012 at 9:37 AM, Dmitry Timoshkov wrote:
> Vincent Povirk
Vincent Povirk wrote:
> If the string wraps, and you don't give the width to
> GdipMeasureString, won't it return a too small height?
GdipMeasureString considers an empty rect as a rect without clipping.
--
Dmitry.
If the string wraps, and you don't give the width to
GdipMeasureString, won't it return a too small height?
On Mon, May 14, 2012 at 9:11 AM, Dmitry Timoshkov wrote:
> GdipMeasureString() clips the string extents to passed rectangle width and
> height, but that leads to wrong offsety calculation i
Owen Rudge writes:
> On 14/05/2012 11:43, Alexandre Julliard wrote:
>> Using the number of Unicode chars multiplied by 2 is a reasonable upper
>> bound on the A string size, and it's used in a number of places. This
>> can't really be considered a Windows bug.
>
> OK; it's perhaps not a bug in th
Vincent Povirk wrote:
> >> > + GdipMeasureString(graphics, string, length, font, &bounds,
> >> > format, &bounds, 0, 0);
> >>
> >> You probably shouldn't use the same GpRect* for both parameters there.
> >
> > I don't see any problem with that.
>
> GdipMeasureString modifies the out
>> > + GdipMeasureString(graphics, string, length, font, &bounds,
>> > format, &bounds, 0, 0);
>>
>> You probably shouldn't use the same GpRect* for both parameters there.
>
> I don't see any problem with that.
GdipMeasureString modifies the out parameter and reads the in
parameter as
Vincent Povirk wrote:
> > - GdipMeasureString(graphics, string, length, font, rect,
> > format, &bounds, 0, 0);
> > + GdipMeasureString(graphics, string, length, font, &bounds,
> > format, &bounds, 0, 0);
>
> You probably shouldn't use the same GpRect* for both parameters
> - GdipMeasureString(graphics, string, length, font, rect, format,
> &bounds, 0, 0);
> + GdipMeasureString(graphics, string, length, font, &bounds,
> format, &bounds, 0, 0);
You probably shouldn't use the same GpRect* for both parameters there.
On 14/05/2012 11:43, Alexandre Julliard wrote:
Using the number of Unicode chars multiplied by 2 is a reasonable upper
bound on the A string size, and it's used in a number of places. This
can't really be considered a Windows bug.
OK; it's perhaps not a bug in that case. I believe my patch is s
Owen Rudge writes:
> There appears to be a bug in the GetUserObjectInformationA function on
> Windows that results in an incorrect buffer length being returned when
> the buffer size provided by the caller is insufficient. The 'A'
> function returns the Unicode length instead of the ANSI length.
On 05/14/2012 11:47 AM, Eric Pouech wrote:
>>> while (*ptr)
>>> if (isspaceW(*ptr)) ptr++; else break;
>> I do not mind terse code but that kinda overdoes it. I would put the
>> "else" on a separate line.
>>
> trafic on wine-devel is rather low those days
> wh
>> while (*ptr)
>> if (isspaceW(*ptr)) ptr++; else break;
> I do not mind terse code but that kinda overdoes it. I would put the
> "else" on a separate line.
>
trafic on wine-devel is rather low those days
what about opening a code-style flame-war ?
A+
--
Er
Hello Austin,
On 05/14/2012 08:01 AM, Austin English wrote:
> diff --git a/dlls/msxml3/domdoc.c b/dlls/msxml3/domdoc.c
> index 6805c75..14fd01b 100644
> --- a/dlls/msxml3/domdoc.c
> +++ b/dlls/msxml3/domdoc.c
> @@ -2277,8 +2277,10 @@ static HRESULT WINAPI domdoc_loadXML(
>
> /* skip
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=18349
Your paranoid android
Hi Austin,
On 05/14/12 08:19, Austin English wrote:
> clang -c -I. -I. -I../../../include -I../../../include
> -DWINE_STRICT_PROTOTYPES -DWINE_NO_NAMELESS_EXTENSION -D_REENTRANT
> -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement
> -Wempty-body -Wignored-qualifiers -Wstrict-pro
26 matches
Mail list logo
