On Fri, Jan 29, 2010 at 11:10 AM, Stefan Leichter Stefan. wrote:
Am Friday 29 January 2010 15:01:55 schrieb Geoffrey Hausheer:
Is there anything I can do to move this patch forward? I've fixed all
the
issues that have been raised so far. I have no dea what it is waiting
Is there anything I can do to move this patch forward? I've fixed all the
issues that have been raised so far. I have no dea what it is waiting on,
and if there is anything I can do to get it committed or if it is just a
question of being patient. As I said previously I'd happily write a test
On Wed, Jan 13, 2010 at 10:38 PM, Piotr Caban wrote:
Hi,
There're still some things that needs to be changed.
Thank you for the continued feedback.
In pixels_to_dialog_units:
+ *basex = ((float)size.cx/26+1)/2;
+ *x_pixels = MulDiv(*x_pixels, 4, *basex);
I proposed doing the
the IPropertyPageSite
stuff), but it is mostly complete.
.Geoff
From 07ca9bda0bd66e53cfbdc441b59fa4bc2e988171 Mon Sep 17 00:00:00 2001
From: Geoffrey Hausheer winedevel9...@phracturedblue.com
Date: Thu, 7 Jan 2010 22:45:28 -0800
Subject: Implement OleCreatePropertyFrame from scratch
---
dlls/oleaut32
On Mon, Jan 4, 2010 at 4:39 AM, John Klehm wrote:
On Mon, Jan 4, 2010 at 4:46 AM, Huw Davies h...@codeweavers.com wrote:
On Sun, Jan 03, 2010 at 03:00:12PM -0800, Geoffrey Hausheer wrote:
I found a patch from 2001 written by TAKESHIMA Hidenori that
was posted to wine-patches
(http
On Mon, Jan 4, 2010 at 9:06 AM, Wolfram Sang wrote:
task. There doesn't appear to be anything in this code that would be
patent encumbered, but the code itself certainly falls under
Hidenori's copyright which he has effectively revoked permission to
use.
Strictly speaking, this is not
for a function like this.
Anyhow, I'm open to feedback on what should be done before I submit
the patch for inclusion
FYI: I was unable to find a currently valid email address for Takeshima
.Geoff
From 6fece5fb94617f00345a7116f6a40b783d1c1466 Mon Sep 17 00:00:00 2001
From: Geoffrey Hausheer winedevel9
The following patch is probably wrong, but it fixes my problem with
WriteFile failing when writing to a COM port. The problem appears to be
that NtWaitForSingleObject sends a count of '1' which results in the
wine_server_call in NTDLL_wait_for_multiple_objects returning
'STATUS_USER_APC' which
that works.
This code seems to run around in circles to me.
.Geoff
-Original Message-
From: Geoffrey Hausheer
Sent: Wednesday, April 14, 2004 2:05 PM
Subject: More serial access issues
Well, I broke down and pulled out the oscope and rs232 breakout box to
try to figure out why my app isn't
Well, I broke down and pulled out the oscope and rs232 breakout box to
try to figure out why my app isn't able to communicate with the device.
turns out that Rein's patch is correctly deasserting DSR, however, I am
not getting any data over the Tx pin. And after I checked the output of
On Mon, 12 Apr 2004 09:26:30 +0200, Rein Klazes said:
1) it might be better to call COMM_WhackModem() after tcsetattr() so
previous flow control settings don't interfere with setting the RTS/DTS
lines.
2) #ifdef guards around TIOCM_DTR and TIOCM_RTS?
Agreed, I will fix this in a
In an ongoing effort to get TzMax working, I've been fighting to get it
to talk to the device through the COM port. The problem is that the
device (a wrist-watch...the program is used to download heart-rate data
from said watch) is very difficult to comunicate with. In theory it is
quite simple:
I have an application that seems to work very well, except that the menus
don't work (in wine, they are fine in Windows)
The app is located here (free download):
http://www.acumeninc.com/download/tzmax50v3.21.exe
After some debugging, I found that the app creates a menu, then destroys
it and
13 matches
Mail list logo