>Objet : Add support for CCSelect sound
Hi Guy,
I wonder if a call to
WCHAR name[] = {
'C','C','S','e','l','e','c','t','\\','.','c','u','r','r','e','n','t',0};
PlaySound(name, 0, SND_ALIAS|SND_ASYNC);
wouldn't do the trick (didn't check it, but it's very likely it's gonna work). I can't
tes
On Sun, 29 Sep 2002 20:34:19 -0400, you wrote:
> To all that answered:
>
> I also abhor the kludge that I wrote.
>
> I also recognize that the test would catch possible *valid* filenames.
>
> I will attempt to find the keys that cause the rename to occur.
>
> However, the point of the patch w
> I just took a look at it, and everything appears normal. I even did a
> checkout of the cvs tree from my home pc to be sure. Double check to
> be
> sure you don't have anything blocking TCP port 2401 at your Firewall
> and/or NAT.
Thanks for your action.
I found the problem I had :
Because of
On September 30, 2002 12:57 am, Alexandre Julliard wrote:
> This will work fine, even if the script starts a Winelib app,
> except if the app depends on inheriting handles from the parent
> process, which is a *very* uncommon case.
And I gather that winedbg is just such a case...
> I believe t
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> If I have a "Run command..." dialog which takes the command name,
> why should I know (and how), that in one I should type winedbg,
> and in another winedbg.exe? In fact, even DOS/Windows users are
> used to be able to specify the probram name _wit
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> To fix this I had to do:
>
> [dimi@dimi wine.build]$ cp ../wine.src/tools/makedep tools/
>
> (I had makedep built already in the source tree)
>
> This doesn't sound right, does it?
You should do a make distclean in the source tree first. make g
On Sat, 2002-09-28 at 01:45, Sylvain Petreolle wrote:
> trying to do a cvs update I get nothing on screen today, even when
> trying to do a simple cvs status (normally it would take seconds).
>
> cvs.winehq.com responds to ping though, could an admin look at it ?
I just took a look at it, and ev
On September 29, 2002 10:25 pm, Alexandre Julliard wrote:
> But that's exactly what it does. You have problems because you know
> too much; with the new scheme a user doesn't even have to know that
> there is a way to configure the debugger, it will just work.
It's a good thing, granted. But my
On September 28, 2002 03:42 am, Dmitry Timoshkov wrote:
> 1. copy WineHQ CVS tree to ~/wine_hq_src
> 2. mkdir ~/wine; cd ~/wine
> 3. ../wine_hq_src/configure; make depend; make
Thanks! But this doesn't work quite right:
[dimi@dimi wine]$ mv wine wine.src
[dimi@dimi wine]$ mkdir wine.build
[dimi@
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> That's very unfortunate, as it is extremely counterintuitive. To the
> point where *I* gave up on using the debugger. A developer. What about
> users? We'll have to explain weird technical reasons: that's a winelib
> app, that's PE executable, etc.
On September 29, 2002 01:54 pm, Alexandre Julliard wrote:
> The problem is that your debugger path points to a Unix script, and
> the new exe loadorder support no longer starts Winelib apps that way.
That's very unfortunate, as it is extremely counterintuitive. To the
point where *I* gave up on u
On September 29, 2002 03:42 pm, Sylvain Petreolle wrote:
> Thus can we consider the result of :
> grep ZeroMemory `find . -name '*.c'` and say "there are probably bugs
> here " ?
I would like to say that that's the case, but I'm a little worried
that will not hold for notification messages. You s
To all that answered:
I also abhor the kludge that I wrote.
I also recognize that the test would catch possible *valid* filenames.
I will attempt to find the keys that cause the rename to occur.
However, the point of the patch was to:
1. Provide the developers with a way not to have their Wi
Thus can we consider the result of :
grep ZeroMemory `find . -name '*.c'` and say "there are probably bugs
here " ?
> Which means that notify_dispinfoT is broken. This way we find the
> bug,
> which is my point exactly against adding this zero memory calls. Not
> only
> they bloat the code, makin
On Sun, Sep 29, 2002 at 09:03:24PM +0200, Sylvain Petreolle wrote:
> Me to... This name is absolutely correct and could be used by another
> program.
> I verified it : I created a file called !$!$.txt and a directory on my
> desktop under Windows NT.
Yep, exactly.
Please research the exact names/
Me to... This name is absolutely correct and could be used by another
program.
I verified it : I created a file called !$!$.txt and a directory on my
desktop under Windows NT.
--- Dmitry Timoshkov <[EMAIL PROTECTED]> a écrit : > "Guy L.
Albertelli" <[EMAIL PROTECTED]> wrote:
>
> > files/file.c
> "Alexandre" == Alexandre Julliard <[EMAIL PROTECTED]> writes:
Alexandre> Uwe Bonnes <[EMAIL PROTECTED]> writes:
>> The event-handle is passed to the winedbg command line:
>> trace:seh:start_debugger Starting debugger format_size 58
>> (fmt=h:\tmp\wine\compile\wine\programs\w
I'm having trouble printing using CUPS. When I try and print in notepad
I get a dialog saying:
Cannot print the Untitled file. Be sure that your printer is connected
properly and use Control Panel to verify that the printer is configured
properly.
My setup is Redhat 7.3 with the following CUPS pa
Uwe Bonnes <[EMAIL PROTECTED]> writes:
> The event-handle is passed to the winedbg command line:
> trace:seh:start_debugger Starting debugger format_size 58
> (fmt=h:\tmp\wine\compile\wine\programs\winedbg\wined
> bg %ld %ld)
> trace:seh:start_debugger h:\tmp\wine\compile\wine\programs\winedbg\wi
> Aspect or Component:
>
> * More DLL Separation
> * BiDi support
> * Review of Wine Server Protocol
> * Finalize Server Protocol
> * PAM (Pluggable Authentication Modules)
> * Visual C++'s native COM support
> * Add DWARF2 support
> * Speed up PDB support
> *
> BTW, I did manage to crash things in gdb proxy mode. Running
> Delphi 5 (my unrealistic fantasy is to get integrated debugging
> working in Delphi), I hit (in programs/winedbg/gdbproxy.c):
>
> 1853 i = write(gdbctx->sock, gdbctx->out_buf, gdbctx->out_len);
> > 1854
On Sunday 29 September 2002 08:53 am, Eric Pouech wrote:
> however, it's strange that your gdb like debuggers crash in -gstabs2
> mode
no crashes, just some weirdness. using -gstabs2, I get relative
paths all over the place, including lots of "../../xxx.c" paths, laid
out in an inconsistent mann
Hallo,
since some time for me the debugger doesn't start when a program
crashes. As there was a lot of reorganization, my non-standard setup (try to
run wine in place) and due to lack of time to verify (workload, holidays) I
can't tell when exactly the breackage occured.
The exception (here in
No, we should be able to compile withiout mesa if we did before my patch.
Unfortunately I dont know how to do this (I did warn alongside my patch) -
Is there any chance you could work out how dlls/ddraw handles this issue so
we can do the same.
I suspect for non-gl enabled machines (until we go v
Hello ,
When I started the ToDo's I was unsure about what section to place some Tasks under
so I just made...
1) Tools:
2) Instructions:
3) Aspect or Component:
And placed items under those three sections and ask for feedback about
where they belong.
I have moved alot of the Tasks from my ori
Hello,
Here is the changes to ( National Language Support )
Does it look alright with everyone ?
If not let me know and ill patch it again .
Everything else is the same I removed BiDi from Aspect or Component:
as well.
Tom
Wine ToDo's as of 9/29/02
Contact : [EMAIL PROTECTED]
Hi,
I noticed recently that Wine was able to do anti-aliasing for font sizes >16
although my Gnome 2 looked nice with anti-aliasing of <16. I started to
look why Wine apps were only anti-aliased for >16, and I came across this:
--- dlls/x11drv/xrender.c.orig 2002-09-29 12:56:27.0 +0200
Ove Kaaven a écrit :
>
> I can imagine Eric has a better patch for the following problem:
> OSS/Commercial does not allow an open device to continue operation after a
> SNDCTL_DSP_RESET, the device must be reopened (which is what their API
> docs recommend). The following patch is what we have in
György 'Nog' Jeney a écrit :
>
> Apply this patch and observe nearly the whole wine recompile :)
>
> ChangLog:
> * include/winuser.h
> * win/win.c
>Implement {G|S}etWindowLongPtr
I don't want to see a whole wine recompilation every day, so I think
those defs
#define SetWindowLong WINE
> + case 'k': /* 'const' modifier */
> + case 'B': /* 'volatile' modifier */
> + /* just kinda ignore the modifier, I guess -gmt */
> + if (DEBUG_PTS_ReadTypedef(ptd, NULL, &ref_dt) == -1) return -1;
> + new_dt = DEBUG_NewDataType(DEBUG_GetType(ref_dt), NU
I don't understand this.
Do you mean a command line greater than 126 chars is executed only when
CMDLINE is set?
> And, finally, you are ignoring long command lines
> from DOS program stored in CMDLINE environment
> variable. (I have already exchanged private email with
> Chris Morgan about this
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
> >1. Add support for Hebrew and Arabic: worker Shachar Shemesh.
> >
> Actually, he had that one under "BiDi support".
Yes, I know. I would suggest to move "BiDi support" as an item
of a larger task "National Language Support".
--
Dmitry.
> Look reasonable?
No. Command tail is not null terminated so you
cannot use strlen. DOS exec function "load and exec"
is synchronous so you should return to caller only
after created process has finished. In addition
to hFile lead found by Ove Kaaven, you are leaking
handles in PROCESS_INFORMAT
Dmitry Timoshkov wrote:
>Here are (once more) items I had sent you earlier:
>
>1. Add support for Hebrew and Arabic: worker Shachar Shemesh.
>
Actually, he had that one under "BiDi support".
>2. Add support for more keyboard layouts to x11drv.
>3. Figure out what should be done for better supp
34 matches
Mail list logo
