Vitaliy Margolen wrote:
Hmm, reverting my change didn't fix it. So I would say it was broken before.
Vitaliy
Yes, it seems so
Vitaliy Margolen wrote:
Restore focus should not select all text in edit control. Only tabbing into it
should do that (according to msdn).
Vitaliy Margolen
changelog:
user/defdlg.c:
- Restore focus to the current control without selecting text
As with Vijay's patch, this patch breaks TABbi
James Hawkins wrote:
All of these
bugs need to be reopened (including 2858) and marked as blockers of
the meta-bug "IE6 fails to install".
>
Reopening them is pointless, because most of them are so old that
ie6setup does not fail in that way anymore. So they would be resolved as
fixed until we
Dan Kegel wrote:
Marking the other bugs as duplicates of 2858 was probably fine,
but I think we ought to leave 2858 open, or if we do not plan to
fix it, mark it "WILLNOTFIX" rather than "FIXED". The instructions in the
appdb are arguably a workaround rather than a fix.
I'm happy to do either
0 (PDT)
Received: by 10.65.115.6 with HTTP; Mon, 10 Oct 2005 08:45:20 -0700 (PDT)
Message-ID: <[EMAIL PROTECTED]>
Date: Mon, 10 Oct 2005 08:45:20 -0700
From: Dan Kegel <[EMAIL PROTECTED]>
To: Richard Cohen <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Dan Kegel wrote:
Good point. Got a few examples bug numbers that were resolved like that?
See http://bugs.winehq.org/show_bug.cgi?id=2858
I recently resolved a lot of whiskery old bugs, essentially "IE6
installer fails",
with directions to the AppDB, because it fixes the user's problem, and
Lionel Ulmer wrote:
As I often switch between Desktop and non-Desktop mode, I found it annoying
to each time having to re-enter my preferred 'Desktop' settings of 800x600.
So created the 'DesktopDisabled' key.
It annoys me as well. Instead of creating another key, why not set the
Desktop key to
We certainly don't want it in 2 places.
BTW
* The "last changed" query is actually "created"
* The "Submit" button should be "Commit"
Richard.
Vitaliy Margolen wrote:
Saturday, October 8, 2005, 5:53:13 AM, Richard Cohen wrote:
+ ok(_read(tempfd,btext,LLEN) == 1, "_read expected 0 got '\\n'\n");
What's not right about it?
ret = _read(tempfd,btext,LLEN);
ok(ret == 0, "_r
Vijay Kiran Kamuju wrote:
Hi, with what patch?
I meant, if you comment out those two lines. :)
Richard.
Vitaliy Margolen wrote:
> + _lseek(tempfd, -1, FILE_END);
+ ok(_read(tempfd,btext,LLEN) == 1, "_read expected 0 got '\\n'\n");
That doesn't look right.
Richard.
Hi Vijay
You wrote:
The testcase program given is running correctly,
The testcase doesn't run correctly here with the patch -- you can no
longer TAB out of the edit control.
Richard.
Ken Larson wrote:
Well I am actually using a command-line with CL to compile it, but it
was true that I had a WinMain instead of main.
I've changed the WinMain to main, but this doesn't seem to be the issue.
The issue appears to be initializing winsock. The following simple main
program, whe
Huw Davies wrote:
On Fri, Sep 09, 2005 at 12:46:10PM +0100, Richard Cohen wrote:
..
Changing SYMBOL_CHARSET -> DEFAULT_CHARSET, FIXED_PITCH -> DEFAULT_PITCH
>> ..
We shouldn't need to do this. Fixing marlett.ttf would be the right
thing to do.
...
I agree that marlett.tt
Jeremy Newman wrote:
Interesting, when it does get the mime type, it inlines it for text
types. I'll add the mime type text/x-diff to /etc/mime.types and see
what happens.
Dont't you mean text/x-patch?
Richard
Uwe Bonnes wrote:
Go ahead with implementing ;-)
Here is a implementation that can exclude relay calls from builtin dlls.
I used '' as the magic word because '%' is possible in file
names.
Calls to window procedures and DLL attach/detach are still shown, but
that is the same as the origin
Alexandre Julliard wrote:
No it's not correct, the current directory needs to be per-task for
Win16 apps.
OK, I'll check why it's not being set correctly, perhaps in WinExec.
Richard.
Marcus Meissner wrote:
Why?
When you're debugging 16bit programs, sometimes you only want to see
16bit calls.:)
Richard.
Mike McCormack wrote:
> In C, variables are traditionally lower case, and macros are upper case.
... but constants are also traditionally upper case. :)
Robert Shearman wrote:
... paths that exist are saved with the Unicode version
of their path name, but paths that don't are saved without.
Alexandre Julliard wrote:
The easiest is probably to go back to always loading GDI. Something
like this should do the trick:
That works for me.
Alexandre Julliard wrote:
The problem is probably
that GDI isn't pre-loaded, which is the case for 32-bit apps now that
GDI no longer needs the local heap.
That would explain it.
What app is causing the problem?
Scansoft Paperport version 6 (.5? -- there are different version numbers
all
Sven Paschukat wrote:
This patch breaks installation of Microsofts MSI 2.0, InstMsiA.exe.
During install with
WINEDLLOVERRIDES="msiexec.exe=n,b" wine InstMsiA.exe
there comes the error:
"Installer besitzt keine ausreichenden Berechtigungen, um
diese Datei zu verändern: C:\Config.Msi\658-rbf.
Alexandre Julliard wrote:
Richard Cohen <[EMAIL PROTECTED]> writes:
Rediffed against HEAD
Richard Cohen wrote:
... and almost certainly Win9x, 2k, XP
Changelog:
+ IEnum::Clone shouldn't do a Reset.
+ Don't assume the ROT is already empty when testing
The
Alexandre Julliard wrote:
A todo is supposed to mark something that will need to be addressed
later on. Obviously we can't fix the Windows code, so that's not a
todo, it's just a behavior of the API that should either be handled by
the test, or simply not tested at all if the results are not reli
Richard Cohen wrote:
This fixes a longstanding bug whereby winemine would move 1 pixel down
the screen for every new game.
Changelog:
- Fix off-by-one in menu height calculation (& therefore
AdjustWindowRect) + test
diff -N -u -r -p dlls/user/nonclient.c dlls/user/nonclie
The original patch
http://www.winehq.org/hypermail/wine-patches/2004/09/0395.html
was from me, back in last September. It included a test which showed
that it was correct. But AJ didn't like the way I did the test :( and I
haven't got round to resubmitting it.
Richard.
Alexandre Julliard wrote:
Richard Cohen <[EMAIL PROTECTED]> writes:
Closing Win16 programs using the Window manager doesn't work any more,
because 16 bit programs don't recognize the WINE internal messages, so
they don't get processed.
This should be fixed now.
Almost. In Peek
Closing Win16 programs using the Window manager doesn't work any more,
because 16 bit programs don't recognize the WINE internal messages, so
they don't get processed.
This patch moves the internal messages to just below 0x, but perhaps
there is a better way?
Richard.
diff -N -u -r dlls/us
Richard Cohen wrote:
Since 'gcc -c *.c -o bigobject.o' doesn't work, would something like the
attached patch (using #include) be acceptable ?
Of course you can use the same technique to compile all the user tests
in one file. The total size of the .o goes from 3.2M to 1.2M
dlls/user/tests/winsize.c 1970-01-01 01:00:00.0 +0100
+++ dlls/user/tests/winsize.c 2004-09-24 12:39:16.0 +0100
@@ -0,0 +1,242 @@
+/*
+ * Unit tests for AdjustWindowRect
+ *
+ * Copyright 2003 Richard Cohen
+ *
+ * This library is free software; you can redistribute it and/or
+ * mo
Huw D M Davies wrote:
On Tue, Sep 21, 2004 at 07:40:17AM -0700, Jon Griffiths wrote:
Hi,
I have an app that calls GetObject on SYSTEM_FONT and then uses the
returned LOGFONT.lfWidth in a calculation. Wine currently returns 0
for the width, which causes a divide by zero error here.
Testing under XP
Dmitry Timoshkov wrote:
dlls/user/tests/win.c already has AdjustWindowRect tests,
see test_nonclient_area. If you could add your tests there
that would be great.
Yes, I saw the tests in there.
I preferred keeping it as a separate file so that it is simple to
understand - it just runs through all t
Something broke when Alexandre moved visible region calculation into the
server.
It happens even in notepad in desktop mode, when you move the window
$ ./wine notepad
X Error of failed request: BadDrawable (invalid Pixmap or Window parameter)
Major opcode of failed request: 70 (X_PolyFillRect
Dimitrie O. Paun wrote:
Richard,
You patch from Nov 28:
http://www.winehq.org/hypermail/wine-cvs/2003/11/0299.html
says (among other things):
"Compiling with -lwine needs to use the given -L paths."
In other words, it adds all the -Lxxx libs to the linking step
for the wrapper. I see no reas
Pavel Roskin wrote:
I have looked at winegcc source and it seems it will greatly improve
portability. I think it's a good idea to switch to winegcc first.
Provided you don't care about delay-loading libraries, you can already
compile the programs with winegcc. Here's the patch
--
Richard
diff -u
Dimitrie O. Paun wrote:
OK, so I'm confused: if we both agree that we should be passing .a and
.so stuff to gcc, why are we ignoring these libs? (At this point, I'm
not sure at all of the context of the patch, it may be that just the
comment is a bit confusing).
The patched code looks like ...
---
Dimitrie O. Paun wrote:
+ Remove . from default library search path
This may break Winelib apps. Did you check that MinGW does not
search . for libs?
Yes, of course I checked. If any winelib apps break, then they are
broken and need fixing.
+ -lwine needs passed in -L paths
What do you mean
flyker wrote:
> After install version 20030911 i run very simply program compiled with
> wine and after it the system (RedHat 9.0) become very slow,
> it does not respond keyboard and mouse and it much use hard disk.
> I think it alloc memory in cycle.
> After some time the system kill wine.
> Inst
Dimitrie O. Paun wrote:
True, but I think it may screw up configure scripts. They do work with
a.out, don't change as I'm fairly sure they will break with a.exe.
Then won't the configure scripts break with mingw as well ?
Richard.
Dimitrie O. Paun wrote:
On Tue, 9 Sep 2003, Richard Cohen wrote:
...rather than adding -L to both the DLLs and static libraries
No functional changes.
I'm not sure this is correct, as the order of -L and -l may be
significant. That is to say, if I do
-LdirA -la -LdirB -lb
then the s
Dimitrie O. Paun wrote:
I'm still not sure I like this one, as I said, a.out is a gccism,
No, a.exe is a mingw-ld ism ;-)
and should be handled in winegcc. winewrap does not have to be
command line compatible to the GNU tool (as it currently stands),
we can require an output name for it.
We have a
Dimitrie O. Paun wrote:
>...
That's not a good strategy, we'll have to be in line with the gcc
people, and breaking compatibility like so is no good. Let's float
the question on their mailing list before we settle on something.
OK, do you want to do it or shall I?
In any case, we need to have our
42 matches
Mail list logo
