Nikolay Sivov wrote:
Currently tests are dependent which makes it impossible to change only one,
could be possible actually, but not always. Anyway separate tests are better.
Changelog:
- Make test not depend from each other, replace some magics with macros
Hi Nikolay,
Looks like this
Paul Vriens wrote:
Nikolay Sivov wrote:
Currently tests are dependent which makes it impossible to change
only one,
could be possible actually, but not always. Anyway separate tests are
better.
Changelog:
- Make test not depend from each other, replace some magics with
macros
Hi
Nikolay Sivov wrote:
Paul Vriens wrote:
Nikolay Sivov wrote:
Currently tests are dependent which makes it impossible to change
only one,
could be possible actually, but not always. Anyway separate tests are
better.
Changelog:
- Make test not depend from each other, replace some magics
Alistair Leslie-Hughes wrote:
Hi,
This fixes bug http://bugs.winehq.org/show_bug.cgi?id=18531
Changelog:
shdocvw: Implement OleInPlaceObject InPlaceDeactivate
It's not an implementation, but a bit better stub. Please leave the
FIXME message.
Jacek
Alistair Leslie-Hughes wrote:
Hi,
Changelog:
msxml3: Add IDispatchEx support to IXMLDOMElement
@@ -46,6 +47,9 @@ typedef struct _domelem
LONG ref;
IUnknown *node_unk;
IXMLDOMNode *node;
+
+/* IDispatchEx */
+DispatchEx dispex;
} domelem;
It would be probably
Alistair Leslie-Hughes wrote:
Hi,
This is just to silence a noisy fixme.
Changelog:
msxml3: IXMLDOMElement doesnt support IObjectIdentity
It's an interface used by jscript engine, so it would be better to
silence it for all object that implements IDispatch. I'd suggest to move
it to
Nikolay Sivov bungleh...@gmail.com writes:
Paul Vriens wrote:
Not sure for the reason. But one thing I don't like is that this
comctl32/msg.c (with no actual tests itself) is also shown on
test.winehq.org.
Could we get rid of .c file here and move messaging test helpers to
header only? It's
Nikolay Sivov bungleh...@gmail.com writes:
diff --git a/dlls/comctl32/listview.c b/dlls/comctl32/listview.c
index a65d832..9bca376 100644
--- a/dlls/comctl32/listview.c
+++ b/dlls/comctl32/listview.c
@@ -9740,6 +9740,8 @@ static LRESULT LISTVIEW_Paint(LISTVIEW_INFO *infoPtr,
HDC hdc)
{
Alexandre Julliard wrote:
Nikolay Sivov bungleh...@gmail.com writes:
diff --git a/dlls/comctl32/listview.c b/dlls/comctl32/listview.c
index a65d832..9bca376 100644
--- a/dlls/comctl32/listview.c
+++ b/dlls/comctl32/listview.c
@@ -9740,6 +9740,8 @@ static LRESULT LISTVIEW_Paint(LISTVIEW_INFO
Juan Lang juan.l...@gmail.com writes:
+typedef struct _IAS_QUERY
+{
+UCHAR irdaDeviceID[4];
+#ifdef USE_WS_PREFIX
+char irdaClassName[WS_IAS_MAX_CLASSNAME];
+char irdaAttribName[WS_IAS_MAX_ATTRIBNAME];
+#else
+char irdaClassName[IAS_MAX_CLASSNAME];
+char
It seems to be 'OK' for X11 to return that because everyone in the X11
universe seems to just accept that as how X works. Not fixing it wine
would mean require all wine users to use something like xmodmap to
modify their own xservers to get the correct behavior.
That doesn't seem like an
Aric Stewart a...@codeweavers.com wrote:
It seems to be 'OK' for X11 to return that because everyone in the X11
universe seems to just accept that as how X works.
Could you please provide an example of this? How other projetcs cope with
that?
Having an appropriate X11 keyboard layout
Am Wednesday 12 August 2009 03:05:43 schrieb Stefan Dösinger:
Am Tuesday 11 August 2009 23:43:33 schrieb Johan Gill:
There is IWineD3DDeviceImpl_SetupFullscreenWindow, but that one is not
exported so it can't be called from ddraw as it is.
Calling it from within
I don't know, is it?
I can never remember how to use the GUID functions.
On Wed, Aug 12, 2009 at 3:36 AM, Henri Verbeethverb...@gmail.com wrote:
2009/8/12 Vincent Povirk vinc...@codeweavers.com:
+ if (memcmp(formats[i].guid, pPixelFormat, sizeof(GUID)) == 0)
This works of course, but
These don't seem to match the PSDK headers or MSDN (which don't match
each other either...) Which are the correct ones?
Oof. Your guess is as good as mine. I looked at MSDN and at MinGW's
headers for inspiration, but MSDN says multiple incompatible versions
of af_irda.h were released. I'll
In http://www.winehq.org/pipermail/wine-devel/2009-August/077858.html
Hin-Tak wrote
...
The last part (missing charset) seems to be some harmless thing winetrick does
- instead of gtk it calls good old xlib message to pop up a message; I haven't
looked at why.
the code is
warn() {
echo $@
Dmitry Timoshkov wrote:
Aric Stewart a...@codeweavers.com wrote:
It seems to be 'OK' for X11 to return that because everyone in the X11
universe seems to just accept that as how X works.
Could you please provide an example of this? How other projetcs cope with
that?
Having an appropriate
2009/8/12 xiaq xiaqq...@gmail.com:
The patch has been reviewed by the original translator, Hongbo Ni. I
have also included my name in the file.
You need to include your full name in patches sent to Wine.
Andrew Eikum wrote:
---
dlls/gdiplus/tests/graphics.c | 244
+
1 files changed, 244 insertions(+), 0 deletions(-)
I suggest to split this:
---
+ok(rectf.X == exp.X
+rectf.Y == exp.Y
+rectf.Width == exp.Width
+
2009/8/12 Andrew Eikum aei...@codeweavers.com:
+GpStatus stat = Ok;
The initialization is redundant, since you always initialize stat
before using it.
+if((stat = GdipCreateRegionRect(wnd_rectf, wnd_rgn) != Ok))
+return stat;
I don't think that does what you want it to do.
Henri Verbeet wrote:
2009/8/12 Andrew Eikum aei...@codeweavers.com:
+GpStatus stat = Ok;
The initialization is redundant, since you always initialize stat
before using it.
+if((stat = GdipCreateRegionRect(wnd_rectf, wnd_rgn) != Ok))
+return stat;
I don't think that does what
+/* get window bounds */
+if(!GetClientRect(graphics-hwnd, wnd_rect))
+return GenericError;
What if the Graphics object doesn't have a window?
--
Vincent Povirk
Yippee!!
A big step forward for usability.
I'll mark the bug fixed tonight.
2009/8/10 Stefan Dösinger stefandoesin...@gmx.at:
Hi,
A few comments - mostly things I haven't spotted earlier.
Hi,
I fixed the code, almost completely following your reviews (thank you,
of course).
I'm reporting the differences with your suggestions:
--- /dev/null
+++
Hello all,
I am working on updating our winemp3.acm implementation to a modern
libmpg123. We where at about 0.59r and I have 1.8.1 working very well.
I have a few questions. Right now I have the smallest subset of files
from libmpg123 that are needed to compile and work in the wine
Hi Aric,
What I am wondering about is that there is still a lot of code in these
files we have no interest in. The file reader and http reader and other
things that we do not use (it is accessed just by the direct stream methods)
and those things dependencies.
Should I leave all this code
On Wednesday 12 August 2009 1:10:15 pm Aric Stewart wrote:
I have a few questions. Right now I have the smallest subset of files
from libmpg123 that are needed to compile and work in the wine framework
(mostly) unmodified. I have replaced all the malloc/free calls with
HeapAlloc/HeapFree
On Wed, Aug 12, 2009 at 4:34 PM, Chris Robinsonchris.k...@gmail.com wrote:
Personally, I'd think linking libmpg123 would be a better option, instead of
duplicating it. It would allow Wine to be updated when the lib updates,
instead of trying to keep up with changes, and avoid duplicating
Right. Is there an particular reason we can't dlopen the native library?
I don't think dlopen is preferable, quite the opposite in fact.
dlopen leads to a situation in which Wine has features that work on
the build system, but not at runtime on another system that doesn't
have the library
On Wed, Aug 12, 2009 at 4:09 PM, Juan Langjuan.l...@gmail.com wrote:
Right. Is there an particular reason we can't dlopen the native library?
I don't think dlopen is preferable, quite the opposite in fact.
dlopen leads to a situation in which Wine has features that work on
the build system,
Owen Rudge wrote:
---
dlls/comctl32/imagelist.c | 318
-
1 files changed, 317 insertions(+), 1 deletions(-)
Hi.
+/*
+ * IImageList implementation
+ */
+
+typedef struct {
+
If the code can be copied into wine itself, it seems to reason that we
could statically link that same code ;-).
http://www.mpg123.org/ - it's LGPL 2.1.
Oh yes, I assumed so. I was talking about statically linking vs.
dlopen in general, and why avoiding dlopen where practical is a good
Well the main advantage I can see is that we are able to have mp3
support without adding a new library dependency. This will be
especially useful for platforms other than Linux where libmpg123 is not
present. Such as the Mac.
There is no technical or licensing reason we would have to link to
You can't do that. HIMAGELIST should be the same thing as IImageList.
Hmm. Looking at the HIMAGELIST/IImageList internals in a debugger on
Windows, the layout appears to be entirely different to the HIMAGELIST
layout defined in dlls/comctl32/imagelist.h (as you'd expect -the
vtable, etc,
This layout is not officially published anywhere, however (nor is the
new one), so I presume it will be acceptable to modify it to fit the
vtable and reference count, etc, in? It might conceivably cause problems
for any pre-comctl32-v6 app that tries to poke around the internals (not
that they
Hi
You are using the hardcoded method to get the vidmem now (in function
IWineD3DImpl_FillGLCaps), first you call glGetString(GL_RENDERER) to get
the GPU renderer string, and then you use this string to set the vidmem
in your code. Unfortunately you don't get all of the ATI GPU's string
now, for
Hi
I am sorry I forgot to introduce myself.
I am a software engineer at AMD, working on OpenGL graphics driver, I am
working with wine issues now. Some uses complained that there are too
many issues to play games with wine with AMD graphics card, so we want
to improve the quality.
That's all,
--- On Wed, 12/8/09, Dan Kegel d...@kegel.com wrote:
In http://www.winehq.org/pipermail/wine-devel/2009-August/077858.html
Hin-Tak wrote
...
The last part (missing charset) seems to be some
harmless thing winetrick does - instead of gtk it calls good
old xlib message to pop up a message; I
38 matches
Mail list logo
