October 2002 - Wine-Devel - list.winehq.org

Re: PATCH: dlls/comctl32/listview.c
by Dimitrie O. Paun Oct. 14, 2002

Oct. 14, 2002

On October 14, 2002 04:09 pm, Gerald Pfeifer wrote: > ChangeLog: > Avoid GCC-specific language extension. This is fixed in my latest patch. -- Dimi.

1 0

RE: PATCH: dlls/comctl32/listview.c
by Patrik Stridvall Oct. 14, 2002

Oct. 14, 2002

> On Mon, Oct 14, 2002 at 10:09:12PM +0200, Gerald Pfeifer wrote: > > This is not ANSI/ISO C as far as I (and current GCC) know, so I hope > > this straightforward fix is fine. > > > > Gerald > > > > ChangeLog: > > Avoid GCC-specific language extension. > > > > Index: listview.c > > =================================================================== > > RCS file: /home/wine/wine/dlls/comctl32/listview.c,v > > retrieving revision 1.224 > > diff -u -3 -p -r1.224 listview.c > > --- listview.c 11 Oct 2002 23:34:32 -0000 1.224 > > +++ listview.c 14 Oct 2002 20:04:57 -0000 > > @@ -4467,6 +4467,7 @@ static LRESULT LISTVIEW_GetColumnWidth(L > > break; > > default: > > /* we don't have a 'column' in [SMALL]ICON mode */ > > + ; > Warum nicht einfach ein break; ? Sieht irgendwie "korrekter" aus... [Since when did we become a german speaking list? :-) I CAN read german to some extent but still...] Because its (1) 5 characters shorter (2) Some compilers generate better code. An unnessary "branch" might be generated. But sure, semantically it is not different (providing of course the default is LAST of course). Anyway, I don't really care either way. Do as you wish.

1 0

Re: PATCH: dlls/comctl32/listview.c
by Andreas Mohr Oct. 14, 2002

Oct. 14, 2002

On Mon, Oct 14, 2002 at 10:09:12PM +0200, Gerald Pfeifer wrote: > This is not ANSI/ISO C as far as I (and current GCC) know, so I hope > this straightforward fix is fine. > > Gerald > > ChangeLog: > Avoid GCC-specific language extension. > > Index: listview.c > =================================================================== > RCS file: /home/wine/wine/dlls/comctl32/listview.c,v > retrieving revision 1.224 > diff -u -3 -p -r1.224 listview.c > --- listview.c 11 Oct 2002 23:34:32 -0000 1.224 > +++ listview.c 14 Oct 2002 20:04:57 -0000 > @@ -4467,6 +4467,7 @@ static LRESULT LISTVIEW_GetColumnWidth(L > break; > default: > /* we don't have a 'column' in [SMALL]ICON mode */ > + ; Warum nicht einfach ein break; ? Sieht irgendwie "korrekter" aus...

1 0

Re: Fixed garbage in toolbar buttons
by Dimitrie O. Paun Oct. 14, 2002

Oct. 14, 2002

On October 13, 2002 12:57 pm, Carlos wrote: > Changelog: > * Changed SRCPAINT to SRCCOPY, the first time what > it paints in hImageDC. > } else if (himl->hbmMask) { > BitBlt( hImageDC, 0, 0, cx, cy, hMaskListDC, lx, ly, SRCAND ); > - BitBlt( hImageDC, 0, 0, cx, cy, hImageListDC, lx, ly, SRCPAINT ); > + if (!bIsTransparent && himl->hbmMask) { > + BitBlt( hImageDC, 0, 0, cx, cy, hImageListDC, lx, ly, SRCPAINT ); > + } else { > + BitBlt( hImageDC, 0, 0, cx, cy, hImageListDC, lx, ly, SRCCOPY ); > + } This can not be right. It is equivalent to: PatBlt( hImageDC, 0, 0, cx, cy, PATCOPY); SelectObject(hImageDC, hOldBrush); } - } else if (himl->hbmMask) { + } else if (himl->hbmMask && !(fStyle & ILD_TRANSPARENT) && clrBk != CLR_NONE) { BitBlt( hImageDC, 0, 0, cx, cy, hMaskListDC, lx, ly, SRCAND ); BitBlt( hImageDC, 0, 0, cx, cy, hImageListDC, lx, ly, SRCPAINT ); } else { /* the image is opaque, just copy it */ TRACE(" - Image is opaque\n"); BitBlt( hImageDC, 0, 0, cx, cy, hImageListDC, lx, ly, SRCCOPY); } That is, if we have ILD_TRANSPARENT set, or clrBk == CLR_NONE, we go the SRCCOPY route, ignoring the mask, which is just the opposite of what we need to do! Alexandre, please do not apply it. -- Dimi.

3 3

Re: Changes in dlls/urlmon/umon.c
by Dimitrie O. Paun Oct. 14, 2002

Oct. 14, 2002

On October 13, 2002 08:34 am, Carlos wrote: > Changelog: > * dlls/urlmon/umon.c > Changed some calls from W to A type. Please don't do that. Better implement the W functions in wininet. -- Dimi.

1 0

Re: alsa driver configuration
by Sylvain Petreolle Oct. 14, 2002

Oct. 14, 2002

Set "Drivers=winealsa.drv" at section [WinMM]. Documentation is outdated about this. Developers : Whats's needeed to edit sgml files ? --- "Gabriel A. Arcos A." <gabrielarcos(a)cantv.net> a écrit : > Hi all !! I have intalled wine-20021007 and I want to use the alsa > driver on it. I have search all the documentation but I have not > found > any info. there are something to change in the ~/.wine/conf file? I'm > trying to play Counter Strike but I can't ( I have installed > propertly > the opengl stuff in compilation time of wine). > > thanks in advance. Gabriel Arcos. > > > > _______________________________________________ > wine-users mailing list > wine-users(a)winehq.com > http://www.winehq.com/mailman/listinfo/wine-users ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

3 3

Re: Fix disabled toolbar button actions
by Duane Clark Oct. 13, 2002

Oct. 13, 2002

Carlos wrote: > Hello, > > Testing 12zip.exe, found that you can click in a > toolbar button what is disabled, and it shows a window. > The next patch fixes the problem, please if someone > is working in the toolbar code, check if it is a correct fix. > > Changelog: > * Fix disabled toolbar button actions. On one of my apps, fpga_editor, this completely breaks the main toolbar. The active buttons no longer work at all. Oddly enough, this app has a popup window with it's own toolbar. The buttons on this window have always appeared to be disabled, even though only some of them should be. But despite their appearance, the buttons work correctly, both before and after this patch.

1 0

Compilation errors
by Shachar Shemesh Oct. 13, 2002

Oct. 13, 2002

make[2]: Entering directory `/home/sun/sources/wine/wine/dlls/d3d8' ../../tools/makedep -I. -I. -I../../include -I../../include -I/usr/X11R6/include -C. basetexture.c cubetexture.c d3d8_main.c device.c directx.c indexbuffer.c resource.c surface.c swapchain.c texture.c vertexbuffer.c volume.c volumetexture.c math.h: No such file or directory math.h was first included from device.c:26 make[2]: *** [depend] Error 1 make[2]: Leaving directory `/home/sun/sources/wine/wine/dlls/d3d8' make[1]: *** [d3d8/__depend__] Error 2 make[1]: Leaving directory `/home/sun/sources/wine/wine/dlls' make: *** [dlls/__depend__] Error 2 The strange thing is that /usr/include/math.h exists, and seems ok. Then again, it does not appear to be in the include path provided for the command. Explanations? Shachar

5 5

Changes in Bitmap behaviour
by Uwe Bonnes Oct. 13, 2002

Oct. 13, 2002

Hallo, Xilinx webpack 4.2 running with native Common Controls shows an artefact in the display of bitmaps associated with the listview widget. This behaviour changed with http://cvs.winehq.com/patch.py?id=5720 by Michael Stefaniuc <mstefani(a)redhat.de>, but still is not right. Appended I have jpegs of the error. The first file (comctl32-builtin.jpeg) shows the behaviour with builtin commctl32, which looks good. The second file (comctl32-native-prepatch.jpeg) shows the behaviour with todays cvs, Michael's patch reversed and native comctl32/commctrl (NT4). We get a discontinous black background of the bitmap The last file (comctl32-native-prepatch.jpeg) is with native comctl32/commctrl (NT4) and todays unmodified cvs version. No we have a all black background. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

4 9

OpenGL textures are wrong under HalfLife
by David D. Hagood Oct. 13, 2002

Oct. 13, 2002

My old motherboard died, and so I upgraded from a single P3 to a dual P3 system. I went to run HalfLife, which had been running beautifully under Wine, and now all the wall textures are screwed up. There is nothing of the proper textures in them - it's not like the colors are screwed up, more like the actual data is screwed up. However, it IS consistent from run to run - the same patterns on the same vertexes each time. The various "humans" in the level are fine - it is just the environment that is screwed. This is running the OpenGL setting in HL - I thought I'd try the DirectX setting, but all I get there is "This is not supported by your card". Now, I have upgraded XFree to the latest CVS pull, I rebuilt my kernel, and upgraded Wine, so it COULD be any of the above. However, I pulled an older version of Wine from another machine with the same results. Native GL programs like Q3A, RTCW, and UT all look fine, so the native GL layer is running well. Could this be an artifact of SMP? Or is there something that Wine does differently in accessing the GL libraries from a native app that would explain this?

1 0