--- Roderick Colenbrander [EMAIL PROTECTED] wrote:
Hi,
Now that I have thought about it a while longer perhaps it is the right idea
to already start using uxtheme. If I remember correctly uxtheme is already
usable the only problem is that we don't use it to actually modify the look
of wine
This is about frame edges and button edges on WINE...
On Windows, the default behavior is the outer left-top edge of a frame is
painted with COLOR_BTNFACE and the inner left-top is colored with something
white (COLOR_BTNHILIGHT maybe???). But for caption buttons and push buttons,
they are
Rémi Assailly [EMAIL PROTECTED] wrote:
There were a fixme warning us that a structure were not sure ( line 1898 ).
I checked it and it seems correct. The only differences I found are :
- ULONG_PTR dwItemData instead of DWORD dwItemData which is the same
thing with win32 and also win64 (
On Thu, 4 Nov 2004, Robert Reif wrote:
Jakob Eriksson wrote:
As shown by:
http://test.winehq.org/data/200411021000/2000_IDWASEMPTY_1/winmm:capture.txt
capture.c:571:found 1 WaveIn devices
capture.c:302: 0: Avance AC'97 Audio
Sorry, the fix was trivial (or at least I think it is).
After I wandered around on the net for a while I think I found a solution to
the edges problem: buttons should be drawn with a BF_SOFT border type.
Patch submitted to wine-cvs. Hope it gets committed :)
Francois Gouget wrote:
On Thu, 4 Nov 2004, Robert Reif wrote:
Jakob Eriksson wrote:
As shown by:
http://test.winehq.org/data/200411021000/2000_IDWASEMPTY_1/winmm:capture.txt
capture.c:571:found 1 WaveIn devices
capture.c:302: 0: Avance AC'97 Audio
Any problem with this one Alexandre?
On Thu, 04 Nov 2004 01:00:37 +, Mike Hearn wrote:
- Always add .dll extension when loading modules
Index: loader.c
===
RCS file: /home/wine/wine/dlls/ntdll/loader.c,v
retrieving
Hans Leidekker [EMAIL PROTECTED] wrote:
@@ -523,6 +524,11 @@
{
InstallUILevel = INSTALLUILEVEL_BASIC|INSTALLUILEVEL_PROGRESSONLY;
}
+ else if(!strcasecmp(argv[i]+2, b+!))
Please use lstrcmpiA instead of strcasecmp. A difference between unix
system locale and current ANSI code page in
Rémi Assailly [EMAIL PROTECTED] wrote:
Excuse me,
I did not want to write that ULONG_PTR is 32 in Win32 _and_ Win64, but I
wanted to write that ULONG_PTR and DWORD were the same. I was wrong here
: DWORD is always 32bits, no ?
Right, DWORD is a 32-bit entity in both Win32 and Win64.
So,
Hi,
On Sat, Nov 06, 2004 at 07:30:20AM -0800, Walt Ogburn wrote:
+/* Special case: X turns shift-tab into ISO_Left_Tab. */
+/* Here we change it back. */
+if ((ret == 0) (keysym == XK_ISO_Left_Tab))
+{
+ret = 1;
+ lpChar[0] = 0x09;
+}
+
if (ret ==
Hi Andreas,
On (a), you are certainly correct. I'll swap the order and resubmit.
As for (b), the if (ret == 0) just below is followed by an else which
does the actual unicode conversion. I wanted to put in the tab character
and change ret to 1 in time to get into the else. It the ISO_Left_Tab
On Saturday 6 November 2004 15:52, Dmitry Timoshkov wrote:
+ else if(!strcasecmp(argv[i]+2, b+!))
Please use lstrcmpiA instead of strcasecmp. A difference between unix
system locale and current ANSI code page in Wine might lead to undesired
side effects.
Here's a patch relative to my
Dimitrie O. Paun wrote:
On Thu, Nov 04, 2004 at 08:02:24PM +, Mike Hearn wrote:
Long term the plan is to use SIGUSR2 to implement SetThreadContext, with
SIGUSR1 uploading the sigcontext to the server for GetThreadContext like
in the patch.
That requires modifying DOSVM so it doesn't use
Hi Walt,
Do you know what shift-tab does under such circumstances in
Windows? If
it's the same as regular tab, you could just map ISO_Left_Tab onto
tab, like below.
I'm not sure about native, but your patch fixes my app (i.e. makes
shift-tab move backward through the tabbing order). It also
Hello,
Hans Leidekker wrote:
I have an InstMsiA.exe that uses two undocumented msiexec command line
parameters: /m and /D and uses an undocumented modifier (!) with the /q
parameter. Our msiexec fails when it encounters these and responds with
a usage message.
For /m I found the following, don't
Eric Pouech a écrit :
see Changelog for the details
A+
with the patch this time.
A+
Name: dbghelp_undname
ChangeLog: implement SymUnDName and UndecorateSymbolName on top of msvcrt.__unDName
License: X11
GenDate: 2004/11/06 18:24:05 UTC
ModifiedFiles:
In trying to get Guild Wars to work, I've come across the lack of D3D8
support in Wine. I'd like to try to help on this front, but I'm not sure
who to talk to or where to start.
Cedega has D3D8 support, but I'm presuming that if I contribute there,
my code won't migrate back to base Wine.
Can
Le sam 06/11/2004 à 14:35, Joel Konkle-Parker a écrit :
In trying to get Guild Wars to work, I've come across the lack of D3D8
support in Wine. I'd like to try to help on this front, but I'm not sure
who to talk to or where to start.
Cedega has D3D8 support, but I'm presuming that if I
On Tue, Nov 02, 2004 at 03:47:40AM +0100, Holly Bostick wrote:
What binary is going to be invoked when the user double-clicks, if
different applications need to be run with different versions/types of
Wine?
One could just offer a script that toggles the version of Wine being
used. Click
On Sat, 06 Nov 2004 16:15:53 -0600, Ryan Underwood wrote:
One could just offer a script that toggles the version of Wine being
used. Click on the script, dialog box pops up Windows programs will
now be launched using Wine[X], and maybe some more information
regarding the suitability for games
Vincent Béron wrote:
Wine has D3D8 support too, and had for some time now. As a lot of things
in Wine, it's not complete (yet), but it does exist.
Can anyone lead me in the right direction here?
dlls/d3d8/
Right, I realize that. I was looking for information about how to help
out with the
[EMAIL PROTECTED] seems to be the most
informed D3D around at the moment.
Kevin
- Original Message -
From: Joel Konkle-Parker [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Saturday, November 06, 2004 5:03 PM
Subject: Re: D3D8
Vincent Béron wrote:
Wine has D3D8
22 matches
Mail list logo
