On Mi, 2007-01-24 at 13:31 +1100, Jeff Latimer wrote:
Thanks for your update.
Just a small typo (Device => Driver):
DDK is the Windows Driver Development Kit
--
By by ... Detlef
On Thu, 2007-11-01 at 17:19 +0100, Wojciech Arabczyk wrote:
> Hello
>
> > trace:wininet:HTTP_GetResponseHeaders raw headers: L"HTTP/1.1 302
> > Found\r\nDate: Thu, 11 Jan 2007 15:47:17 GMT\r\nServer: Apache/2.0.54
> > (Debian GNU/Linux)\r\nLocation:
> > http://optusnet.dl.sourceforge.net/sourcefor
Hi,
I'm still working on the freeware "Navigation"
(http://francois.fouchet.free.fr/) which will soon be added to AppDB.
I produced a working version of WidenPath (a priliminary patch will come
soon).
Another problem appeared in an other place (which was masked because of
WidenPath at the
Am Dienstag 23 Januar 2007 14:08 schrieb Alessandro Pignotti:
> Hi everyone,
> i'm taking a look at wine's directplay implementation. From the the wiki
> i've seen that there are efforts to understand the directplay protocol. But
> it seems to be be quite a difficult task. Would not be a better ide
"Clinton Stimpson" <[EMAIL PROTECTED]> wrote:
-if (lParam) paint_button( hWnd, btn_type, ODA_DRAWENTIRE );
+if (LOWORD(lParam)) InvalidateRect(hWnd, NULL, TRUE);
Your test doesn't show that the usage of LOWORD(lParam) is justified.
--
Dmitry.
In message <[EMAIL PROTECTED]>, Christoph Frick writes:
>On Mon, Jan 22, 2007 at 02:07:34PM -0600, Peter Seebach wrote:
>> I have implemented and tested a patch which is almost certainly unsuitable
>> for production, but which is very convenient to me; it is this patch I
>> enclose. This patch rep
On 1/23/07, Alessandro Pignotti <[EMAIL PROTECTED]> wrote:
Hi everyone,
i'm taking a look at wine's directplay implementation. From the the wiki i've
seen that there are efforts to understand the directplay protocol. But it
seems to be be quite a difficult task. Would not be a better idea to
impl
Hi everyone,
i'm taking a look at wine's directplay implementation. From the the wiki i've
seen that there are efforts to understand the directplay protocol. But it
seems to be be quite a difficult task. Would not be a better idea to
implement a wine directplay service provider with our own prot
Anything wrong with them again?
http://www.winehq.org/pipermail/wine-patches/2007-January/035044.html
http://www.winehq.org/pipermail/wine-patches/2007-January/035043.html
Thanks,
Kirill
Alexandre Julliard <[EMAIL PROTECTED]> writes:
> Module: wine
> Branch: master
> Commit: aa9dcb42019e0ebc0913d1a56b150684212099ea
> URL:
> http://source.winehq.org/git/wine.git/?a=commit;h=aa9dcb42019e0ebc0913d1a56b150684212099ea
>
> Author: Alexandre Julliard <[EMAIL PROTECTED]>
> Date: Mon
Clinton Stimpson <[EMAIL PROTECTED]> writes:
> Anything wrong with this patch? It hasn't been accepted.
I suspect you need an UpdateWindow() too. To confirm this (or not) you
should avoid the PeekMessage loop in your test.
--
Alexandre Julliard
[EMAIL PROTECTED]
On Mon, Jan 22, 2007 at 02:07:34PM -0600, Peter Seebach wrote:
> I have implemented and tested a patch which is almost certainly unsuitable
> for production, but which is very convenient to me; it is this patch I
> enclose. This patch replaces F13-F24 with "control-alt-F1" through
> "control-alt-
On Tue, Jan 23, 2007 at 08:58:24AM +0100, Tomas Carnecky wrote:
> I'm sure I could hack you a small app that takes input events from
> /dev/input/eventX and uses XTest to fake X key events. That way you
> could 'map' F13 to Control-F1. I've written a few 'drivers' for input
> devices (MS Strategic
13 matches
Mail list logo
