Wednesday, April 12, 2006, 4:02:58 PM, Ivan Gyurdiev wrote:
> The point of this patch is to pull out things like modifier processing
> (write masks, saturate, swizzle) from different case statements, and put
> them in a more common path, which simplifies code, and makes sure we
> don't miss cas
Duane Clark wrote:
Hmmm, well I found this:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/editcontrols/editcontrols.asp
where is says "By default, the edit control margins are set just wide
enough to accommodate the largest character horizontal ove
Jesse Allen wrote:
On 4/7/06, Molle Bestefich <[EMAIL PROTECTED]> wrote:
trace:xrandr:X11DRV_XRandR_SetCurrentMode Changing Resolution to
1280x1024 @45961 Hz
Starcraft #
Looks like xrandr is broken.
It says "Changing Resolution to 640x480", so tha
Huw Davies wrote:
On Wed, Apr 12, 2006 at 12:26:07PM -0700, Duane Clark wrote:
Huw Davies wrote:
Interesting, so to clarify, even a large edit control and a small
Microsoft Sans Serif has a zero margin?
Yep.
Fascinating. This will probably be a huge clue in working out exactly
what Windows
The Drivers-Listview in winecfg works now (thanks for that fix), but the
Listview-Issues in winefile are still present.
Any Ideas?
I haven't noticed them but I'll try to look into them tomorrow.
Mikolaj Zalewski
Mikołaj Zalewski wrote:
>When resizing the columns of a listview by dragging the header columns
> divider, the list columns resizes after every mouse move while the
> header only draws a tracking line and resizes when the mouse button goes
> up. These patches tries to fix it.
The Drivers-List
On Wed, Apr 12, 2006 at 09:22:10PM +0100, Paul Millar wrote:
> On Wednesday 12 Apr 2006 10:49, Saulius Krasuckas wrote:
> > WRT suite build fails for quite long time already: [1]
> > So that probably was caused by the patch from Huw: [2]
> > It may happen because of missing FreeType 2 stuff: [3]
>
> Not sure how important NetBIOS is, but what do you mean by "the registry
> has to be set up"?
I'm an idiot. Broadcast name resolution works without any setup, and WINS
can be added by those that use it. (That should probably be documented
someplace.)
Hans, I take back what I said about not wa
On Wed, Apr 12, 2006 at 12:26:07PM -0700, Duane Clark wrote:
> Huw Davies wrote:
> >Interesting, so to clarify, even a large edit control and a small
> >Microsoft Sans Serif has a zero margin?
>
> Yep.
Fascinating. This will probably be a huge clue in working out exactly
what Windows does here -
Huw Davies wrote:
On Wed, Apr 12, 2006 at 11:28:21AM -0700, Duane Clark wrote:
Testing more on Win2k shows
that with Tahoma, the edit field sets margins that depend on the font
size. Explicitely setting "Microsoft Sans Serif" gives me the correct
font, and it is indeed True Type, but both marg
Am Dienstag, 11. April 2006 22:43 schrieben Sie:
> In KDevelop, did you set up a new project your ddraw test app? If so, which
> type did you pick? Thanks.
I think I picked a c++ console project.
Stefan
pgp5JeZoMJiW7.pgp
Description: PGP signature
On Wed, Apr 12, 2006 at 11:28:21AM -0700, Duane Clark wrote:
> Testing more on Win2k shows
> that with Tahoma, the edit field sets margins that depend on the font
> size. Explicitely setting "Microsoft Sans Serif" gives me the correct
> font, and it is indeed True Type, but both margins remain z
Huw Davies wrote:
I assume you mean Microsoft Sans Serif not MS Sans Serif. The former
is a TrueType font (micross.ttf) the latter is a bitmap font
(sserife.fon).
Indeed it does look like[1] we should be using Microsoft Sans Serif
for MS Shell Dlg at least for non-CJK locales.
You are right
Hey,
Only one advpack function needs to be converted to unicode,
ExtractFilesA. The problem is that we use cabinet.Extract to extract
the files, but cabinet only provides one version of Extract, and it's
ansi and not unicode. Francois, you noticed that advpack now had A/W
functions, does the new
On Wed, Apr 12, 2006 at 10:14:58AM -0700, Duane Clark wrote:
> Huw D M Davies wrote:
> >
> >MS Shell Dlg maps to either Microsoft Sans Serif or Tahoma depending
> >on Windows version; the default wine.inf maps it to Tahoma so you
> >should check whether you have tahoma.ttf installed. If in doubt a
Duane Clark wrote:
On the other hand, in both Win2k and WinXP, "MS Shell Dlg" seems to be
mapping to "MS Sans Serif". So is having Tahoma the default really the
right thing to do?
And to respond to myself once again, according to:
http://msdn.microsoft.com/library/default.asp?url=/library/en
Duane Clark wrote:
... Most of the other characters appear to be pixel
identical (though the '7' is rendered one pixel to the right of where it
is on Win2k).
Actually, the '7' is correct. The problem is the '8' (I had typed
"6789"). Here are a couple of small images of the problem. The first,
Huw D M Davies wrote:
MS Shell Dlg maps to either Microsoft Sans Serif or Tahoma depending
on Windows version; the default wine.inf maps it to Tahoma so you
should check whether you have tahoma.ttf installed. If in doubt a
+font log will tell you what Wine picks for this font.
In Win2k, it is
В сообщении от 12 апреля 2006 15:17 Mike McCormack написал(a):
> Vitaly Lipatov wrote:
> > В сообщении от 12 апреля 2006 14:18 Alexandre Julliard написал(a):
> >>IsBadReadPtr is broken and should never be used. You need to add an
> >>exception handler around the actual access.
> >
> > I know many M
On Wed, Apr 12, 2006 at 08:55:09AM -0700, Duane Clark wrote:
> Huw D M Davies wrote:
> >
> >I had some fun with this a month or two ago. See the
> >test_margins_font_change test and calc_min_margin_size in the actual
> >code. The deal seems to be that for 'small' edit controls
> >EC_USEFONTINFO r
Dan Kegel wrote:
Duane Clark wrote:
I also have an installer (for Xilinx) that exhibits this problem. I
created a small application that creates a single line edit control
(which is what the Xilinx installer uses). I notice that on Win2k the
EM_GETMARGINS message returns zero for left and right
Huw D M Davies wrote:
I had some fun with this a month or two ago. See the
test_margins_font_change test and calc_min_margin_size in the actual
code. The deal seems to be that for 'small' edit controls
EC_USEFONTINFO results in no margin. 'Small' is currently defined to
be smaller than the ex
I'm having a strange problem with Wine - it will not show any characters
in any windows, UNLESS I delete Wine's registry files - then it will
show characters for the first program run, but no other programs
thereafter (including repeat runs of the first program).
So, for example, I can run "wi
On 4/7/06, Molle Bestefich <[EMAIL PROTECTED]> wrote:
> trace:xrandr:X11DRV_XRandR_SetCurrentMode Changing Resolution to
> 1280x1024 @45961 Hz
> Starcraft #
>
>
> Looks like xrandr is broken.
> It says "Changing Resolution to 640x480", so that sounds great - only
>
Mike Hearn [mailto:[EMAIL PROTECTED] wrote:
> IsBad*Ptr has historically been used throughout Win32 to verify arguments,
> but this was never a good idea and in Vista it has been "banned", which I
> guess means Microsoft have gone through and removed the tests. Or at least
> are not using them any
Huw D M Davies wrote:
I had some fun with this a month or two ago. See the
test_margins_font_change test and calc_min_margin_size in the actual
code. The deal seems to be that for 'small' edit controls
EC_USEFONTINFO results in no margin. 'Small' is currently defined to
be smaller than the ex
On 4/12/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> "Jesse Allen" <[EMAIL PROTECTED]> writes:
>
> > WaitForSingleObject in kernel32. The read call is in wait_reply of
> > dlls/ntdll/thread.c and that is where that thread gets stuck.
>
> Does this help?
>
> diff --git a/server/window.c b/ser
On 4/11/06, Fabian Cenedese <[EMAIL PROTECTED]> wrote:
>
> >Ok, I'm not sure about it waiting for that event. The call is
> >0009:Call kernel32.WaitForSingleObject(0048,) ret=00401c00
> >
> >Anyway I wrote a test app, showwindow.c. It is available on
> >ftp://resnet.dnip.net . The rela
On Tue, Apr 11, 2006 at 04:53:20PM -0700, Duane Clark wrote:
> Tony Lambregts wrote:
> >We now have at least three bugs[1] where the program will not accept the
> >all the characters that are required if we do not use native fonts. The
> >latest bug report was reported just today and the reporter
Hello,
I have found that the DDraw/DirectX 7 over WineD3D patch introduces a
regression. Heroes of Might and Magic IV now displays a menu in the
upper area of the screen, something it is only supposed to do in
windowed mode. The game is then moved a little down, so the bottom of
the screen
Duane Clark wrote:
>I also have an installer (for Xilinx) that exhibits this problem. I
>created a small application that creates a single line edit control
>(which is what the Xilinx installer uses). I notice that on Win2k the
>EM_GETMARGINS message returns zero for left and right messages, but on
On Wed, Apr 12, 2006 at 06:50:36AM -0700, Dan Kegel wrote:
> On 4/11/06, Marcus Meissner <[EMAIL PROTECTED]> wrote:
> > > >> > I have started adding gphoto2 support to twain.dll.
> > > >>
> > > >> Sounds good. I'm mildly surprised twain doesn't
> > > >> support libgphoto2 as a backend already, but
On 4/11/06, Marcus Meissner <[EMAIL PROTECTED]> wrote:
> > >> > I have started adding gphoto2 support to twain.dll.
> > >>
> > >> Sounds good. I'm mildly surprised twain doesn't
> > >> support libgphoto2 as a backend already, but whatever...
>
> I will check how good it works as-is.
http://cowber
I am 'Dumber' in this area but when it writes ARBfp2.0 into the shaders, it should be printing a FIXME.check in this function WineD3DPixelShaderImpl_GenerateProgramArbHW from line 1005 to 1039, in pixelelshader.c, in wined3d
here its checking for pixeelshader version for pixelshader versiion 20 it
On 12/04/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
> Why does wine write ARBfp2.0 into opengl shaders that originated from
> DirectX2.0?
> The shaders I'm seeing all use commands currently available to us [ no
> branches or anything like that ], but are marked v2.0. As a result the
> ARB extensi
Vitaly Lipatov wrote:
В сообщении от 12 апреля 2006 14:18 Alexandre Julliard написал(a):
IsBadReadPtr is broken and should never be used. You need to add an
exception handler around the actual access.
I know many MS's dlls use IsBadReadPtr for check pointers.
IsBadReadPtr is malfunction conc
On Wed, 12 Apr 2006 14:44:18 +0400, Vitaly Lipatov wrote:
> I know many MS's dlls use IsBadReadPtr for check pointers.
> IsBadReadPtr is malfunction conceptually or it is not realized correctly yet?
The problem is you can't use it in thread safe code, because the pointer
may be correct when you te
В сообщении от 12 апреля 2006 14:18 Alexandre Julliard написал(a):
> IsBadReadPtr is broken and should never be used. You need to add an
> exception handler around the actual access.
I know many MS's dlls use IsBadReadPtr for check pointers.
IsBadReadPtr is malfunction conceptually or it is not rea
Rein Klazes <[EMAIL PROTECTED]> writes:
> I have no idea why it was not merged, never got any comments. Cc' ed to
> the developers list for suggestions. A re-diffed patch is attached.
IsBadReadPtr is broken and should never be used. You need to add an
exception handler around the actual access.
Why does wine write ARBfp2.0 into opengl shaders that originated from
DirectX2.0?
The shaders I'm seeing all use commands currently available to us [ no
branches or anything like that ], but are marked v2.0. As a result the
ARB extension fails on them every single time (invalid header -
ARBfp2.
On Tue, 11 Apr 2006 10:24:14 +0200, you wrote:
>> Hi,
>>
>> There are a couple of entries in the bug database (at least #4334 and
>> #4664) where the application calculates a wrong pointer for bitmap data.
>> The application survives on Windows but crashes on wine.
>>
>>
>> Changelog:
>> dlls/x
Again, I updated the wine-wiki at "Building from GIT" to link to the new
version of getwinegit.sh.
see here: http://wiki.jswindle.com/index.php/Installing_Wine#Building_from_GIT
bye
WRT suite build fails for quite long time already: [1]
So that probably was caused by the patch from Huw: [2]
It may happen because of missing FreeType 2 stuff: [3]
If that's the case for us (Paul Millar), can it be worked around by adding
another configure check, guys? Or it isn't worth an effo
"Jesse Allen" <[EMAIL PROTECTED]> writes:
> WaitForSingleObject in kernel32. The read call is in wait_reply of
> dlls/ntdll/thread.c and that is where that thread gets stuck.
Does this help?
diff --git a/server/window.c b/server/window.c
index 8254793..5ceab49 100644
--- a/server/window.c
+++ b/
>>Anyway I wrote a test app, showwindow.c. It is available on
>>ftp://resnet.dnip.net . The relay log is there too. The test app tries
>>to mimic the calls I see. I tested under wine and it does hang. I
>>will see about windows.
>
>I don't know if I did it right. I created an empty Win32 applica
45 matches
Mail list logo
