On 06/19/2011 09:31 PM, Thomas Mullaly wrote:
+#define DEFINE_EXPECT(func) \
+static BOOL expect_ ## func = FALSE, called_ ## func = FALSE
+
+#define SET_EXPECT(func) \
+expect_ ## func = TRUE
This seems like macro-overkill. I think a struct/table here may be a
bit cleaner.
+static
On 06/19/2011 09:32 PM, Thomas Mullaly wrote:
+static inline void reset_output_buffer(mxwriter *This, LPCSTR encoding)
+{
+xmlOutputBufferClose(This-buffer);
+
+if (encoding)
+This-buffer =
xmlAllocOutputBuffer(xmlFindCharEncodingHandler(encoding));
+else if (!This-dest)
+
Hi,
There seem to be regressions in xinput2 support,
http://bugs.winehq.org/show_bug.cgi?id=27028
As this might be a X.org issue, should we packagers turn off
xinput2 support for the time being?
Ciao, Marcus
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=11841
Your paranoid
These two patches look OK to me.
On Friday 17 June 2011 14:19:56 Michael Mc Donnell wrote:
Removed a superfluous test.
Added NULL check before releasing mesh.
Changed struct declaration style.
Changed the struct declaration style again.
Added GetNumBytesPerVertex test
Added GetDeclaration
On 20 June 2011 15:08, Vitaliy Margolen wine-de...@kievinfo.com wrote:
On 06/19/2011 08:15 PM, Austin Lund wrote:
+ ret = wine_server_call( req );
+ shi-Count += reply-handles;
+ len = sizeof(SYSTEM_HANDLE_ENTRY)*shi-Count +
Hi,
There seem to be regressions in xinput2 support
I too have experienced various mouse trouble since approx. 1.3.18 on MacOS,
using XQuartz 2.5.x or 2.6.1 -- which is much more recent than any of my
Ubuntu systems (Lucid). As I've currently little time for regressions, I haven't
yet turned that
On 20 June 2011 15:12, Vitaliy Margolen wine-de...@kievinfo.com wrote:
On 06/19/2011 08:15 PM, Austin Lund wrote:
[PATCH 2/4] server: Add function to count only valid handles in a process
This makes no sense. All handles are valid inside wineserver.
When looking at bug 9484 and trying to
Because callback doesn't have any string parameters it would be an easy
thing to do.
I've made an EnumDevicesBySemantics version using A - W calls, but it
turned out to be trickier than I thought because the callback function
is passed the device interfaces and then the A callback gets W
2011/6/18 Charles Welton charles...@gmail.com:
---
dlls/d3dx9_36/tests/line.c | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
+srand(time(NULL));
+random = ((FLOAT) rand())/RAND_MAX; /* Random value between 0.0 and 1.0.
We're using this later. */
On 06/20/2011 02:55 AM, Marcus Meissner wrote:
As this might be a X.org issue, should we packagers turn off
xinput2 support for the time being?
If that will fix all dinput regressions - absolutely. Or add a registry
option to disable xinput2.
Vitaliy.
On 06/20/2011 05:28 AM, Austin Lund wrote:
Thanks for the review. Does this patch address these concerns correctly?
No quite there yet:
+SERVER_START_REQ( create_snapshot )
You not checking if this call succeeded or not.
+while (sizeof(ULONG) +
On 06/20/2011 02:55 AM, Vincas Miliūnas wrote:
Fixed function name typo, compiler warnings, code style issues in a
fragment of new code and incorrect usage of wcslen in the tests instead
of lstrlenW after previous changes. My apologies :).
+#define DEADBEEF 0xdeadbeef
Please don't do this.
On 06/20/2011 02:55 AM, Vincas Miliūnas wrote:
(see the message in the first part of the patch)
+struct raw_input
+{
+struct listentry;
+unsigned short usage_page;
+unsigned short usage;
+BOOL processed;
+BOOL retrieved;
+RAWINPUT raw;
+
+
Vitaliy Margolen wine-de...@kievinfo.com writes:
On 06/20/2011 02:55 AM, Marcus Meissner wrote:
As this might be a X.org issue, should we packagers turn off
xinput2 support for the time being?
If that will fix all dinput regressions - absolutely. Or add a
registry option to disable xinput2.
2011/6/18 André Hentschel n...@dawncrow.de:
-static HRESULT STDMETHODCALLTYPE taskbar_list_QueryInterface(ITaskbarList
*iface, REFIID riid, void **object)
+static HRESULT STDMETHODCALLTYPE taskbar_list_QueryInterface(ITaskbarList2
*iface, REFIID riid, LPVOID *ppv)
{
- TRACE(iface %p,
Am 20.06.2011 17:50, schrieb Henri Verbeet:
2011/6/18 André Hentschel n...@dawncrow.de:
-static HRESULT STDMETHODCALLTYPE taskbar_list_QueryInterface(ITaskbarList
*iface, REFIID riid, void **object)
+static HRESULT STDMETHODCALLTYPE taskbar_list_QueryInterface(ITaskbarList2
*iface, REFIID
On 06/20/2011 05:24 PM, Vitaliy Margolen wrote:
On 06/20/2011 02:55 AM, Vincas Miliūnas wrote:
(see the message in the first part of the patch)
+struct raw_input
+{
+struct listentry;
+unsigned short usage_page;
+unsigned short usage;
+BOOL processed;
+
Hello André,
On 06/20/2011 10:01 PM, André Hentschel wrote:
I should mention that i never added a interface before, neither one
that extends an existing one. I want to stub out ITaskbarList3, so i
thought i should first start with ITaskbarList2 and see what i'm doing
right or wrong.
this is a
On Mon, Jun 20, 2011 at 09:36, Alexandre Julliard julli...@winehq.org wrote:
Vitaliy Margolen wine-de...@kievinfo.com writes:
On 06/20/2011 02:55 AM, Marcus Meissner wrote:
As this might be a X.org issue, should we packagers turn off
xinput2 support for the time being?
If that will fix all
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=11852
Your paranoid
I think a regression was introduced today. I got the following trying to run
NatSpeak 11.0 with today's git.
wine-1.3.22-255-g4c0c0d3
Should I do a regression test and file a bug, or is it obvious from this?
Or is it me -- something to do with my new Oneiric Ocelot? Or the new 3.0
kernel?
On Mon, Jun 20, 2011 at 21:00, Susan Cragin susancra...@earthlink.net wrote:
I think a regression was introduced today. I got the following trying to run
NatSpeak 11.0 with today's git.
wine-1.3.22-255-g4c0c0d3
Should I do a regression test and file a bug, or is it obvious from this?
Or is
On 20 June 2011 23:52, Vitaliy Margolen wine-de...@kievinfo.com wrote:
+ SERVER_START_REQ( create_snapshot )
You not checking if this call succeeded or not.
I've tried to include all the checks in the new patch.
+ while (sizeof(ULONG) +
On 06/20/2011 02:31 PM, Austin English wrote:
On Mon, Jun 20, 2011 at 09:36, Alexandre Julliardjulli...@winehq.org wrote:
Vitaliy Margolenwine-de...@kievinfo.com writes:
On 06/20/2011 02:55 AM, Marcus Meissner wrote:
As this might be a X.org issue, should we packagers turn off
xinput2
On 06/20/2011 08:36 AM, Alexandre Julliard wrote:
Vitaliy Margolenwine-de...@kievinfo.com writes:
On 06/20/2011 02:55 AM, Marcus Meissner wrote:
As this might be a X.org issue, should we packagers turn off
xinput2 support for the time being?
If that will fix all dinput regressions -
On 06/20/2011 04:06 PM, Lucas Fialho Zawacki wrote:
@@ -1391,9 +1391,24 @@ HRESULT WINAPI
IDirectInputDevice8AImpl_SetActionMap(LPDIRECTINPUTDEVICE8A iface
LPCSTR lpszUserName,
DWORD
On 06/20/2011 09:36 PM, Austin Lund wrote:
On 20 June 2011 23:52, Vitaliy Margolenwine-de...@kievinfo.com wrote:
+SERVER_START_REQ( create_snapshot )
You not checking if this call succeeded or not.
I've tried to include all the checks in the new patch.
+
28 matches
Mail list logo
