wine-devel March 2004

wine-devel@winehq.org

128 participants
264 discussions

text edit box not painting text ( on form startup )
by Doug Herbert 09 Mar '05

09 Mar '05

( I have posted a similiar question in wine-users, don't flame me for doing so, just thinking about this some more, perhaps it may be more a developer question ) Ok, I have a windows app, that runs under wine fine - not quite. This app has a form, with many text field edit boxes on. Quite often these edit boxes already have text values, ie. they are not empty - there is a database behind the form. Anyway, the form shows on the screen, but the text within the edit fields is invisible, until you activate each edit box component. When you leave one edit box to the next, the text remains visible. It seems like the repainting is not working, on initial startup of the form. As a way to debug this database app ( I don't have the source code for it ) I wrote a real basic form app in Visual Studio, with two edit boxes, with data in each. Now this basic app shows the text values immediately on startup. So there must be something different that the database app is not doing. I then ran wine using 'wine --debugmsg +edit programname' for both app's. I see both logging 'Creating ANSI edit control, style = xxxxx' but the style reference is different between apps - I am not sure if this the cause or not. The problem app reports style = 54011104 and the basic app shows style = 50010080. Can somebody explain what this style reference means and how do I force an app to use a certain style of edit box ? What other wine class debugmsg types should I use to narrow down the source of this problem ? Is there anyway I can check to see how the database app is repainting text within the text edit components ? Regards Doug Herbert. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

3 4

i810 audio fixes 1/2
by Roderick Colenbrander 21 Apr '04

21 Apr '04

Hi, This is the first of two patches that will fix some problems on soundcards using the i810 audio codec. The main probem with this soundcard is that it only supports a frequency of 48kHz in 16bit stereo mode. This first patch to dsound queries if the card supports 16bit and if so it uses it, else it uses 8bit. Further it also detects if the card supports stereo or not. The patch was inspired by one from transgaming to rewind but that patch did a bit the opposite (defaulting to 8bit ..). Roderick Colenbrander

8 18

err:clipping:CLIPPING_UpdateGCRegion hVisRgn is zero. Please report this.
by Brad Campbell 19 Apr '04

19 Apr '04

G'day all, Due to restrictions in my current setup I'm not subscribed to wine-devel at the moment, please cc me. This is a longstanding bug with Word97. It exists in Crossover office 2.1.0 as well and was reported in the Codeweavers database months ago. It usually results in the "style" drop down box on the far left of the toolbar blanking it's entries. I have a pretty complex default template that has a number of styles in it that all render with funky true-type fonts. When you scroll up and down this list a couple of times, wine ceases to render the entries. It used to lock up in an endless loop somewhere, but now it bombs with the below error message. I compile from CVS a couple of times a week, and subject to time I'm happy to do anything at all to assist in debugging this if it will help someone. (I have worked around it by creating tool bars with all my styles on it so I don't have to use this box) Regards, Brad fixme:hook:NotifyWinEvent (32773,0x30035,-4,11)-stub! fixme:hook:NotifyWinEvent (32773,0x30035,-4,10)-stub! err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes fixme:hook:NotifyWinEvent (32773,0x30035,-4,9)-stub! err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes fixme:hook:NotifyWinEvent (32773,0x30035,-4,8)-stub! err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes fixme:hook:NotifyWinEvent (32773,0x30035,-4,7)-stub! err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes fixme:hook:NotifyWinEvent (32773,0x30035,-4,6)-stub! err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes fixme:hook:NotifyWinEvent (32773,0x30035,-4,5)-stub! err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes fixme:hook:NotifyWinEvent (32773,0x30035,-4,4)-stub! err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes fixme:hook:NotifyWinEvent (32773,0x30035,-4,3)-stub! err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes fixme:hook:NotifyWinEvent (5,0x10022,-3,0)-stub! fixme:ole:I_RpcWindowProc (0x10026,0000001c,00000000,00000000): stub err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 28 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 28 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 28 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 28 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 28 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 28 bytes err:clipping:CLIPPING_UpdateGCRegion hVisRgn is zero. Please report this.

2 1

Game support
by James Perry 14 Apr '04

14 Apr '04

Hi everyone, I've been following Wine development for a while but now I think it's time to contribute something. I don't use Windows anymore (except for PowerPoint at work), but I decided it would be good to be able to play some games on Linux. So I grabbed Wine from CVS, compiled it up and tested some games, with the intention of finding where the problems were and hopefully fixing them. I have put my results on a web page at: http://www.epcc.ed.ac.uk/~jamesp/wine-games.html to avoid making this posting even longer. Note that I haven't looked in detail at most of these yet, I just tried them out once to see what would happen. I'm gradually working through the list, debugging them. I've already submitted one patch (to solve a D3D blend mode problem that affected SonicR). I have traced a number of the other problems to specific aspects of Wine, but I'm not sure how to go about fixing them. Any advice on these points from experienced developers would be welcome: 1. MusicVR exits with this error: X Error of failed request: GLXBadDrawable Major opcode of failed request: 145 (GLX) Minor opcode of failed request: 11 (X_GLXSwapBuffers) Serial number of failed request: 10522 Current serial number in output stream: 10523 I traced it to the line: glXMakeCurrent(default_display, None, NULL) in dlls/opengl32/wgl.c. My OpenGL (nVidia) doesn't seem to like the drawable being set to None, although according to the GLX docs, this should be OK. Simply commenting out the line makes the game work fine, but I don't think this is the right fix. Any ideas? 2. Settlers III crashes almost straight away, in the code of the PE-Crypt protection system. This is caused by the processor's direction flag (which controls whether pointers are incremented or decremented by string instructions) getting reset somewhere, probably in Wine code. Can anyone comment on treatment of this flag in Wine? Is it likely to be clobbered in lots of places? Basically, is there any hope of getting this working? I'm not sure where to start with this one. 3. South Park Rally creates its DirectInput object using the generic OLE functions, which doesn't work in Wine right now. I have some initial code to support this, but not sure if it does everything it needs to. I have: - copied regsvr.c from the DirectSound DLL and edited it to register the DirectInput classes, and implement the DirectInput Dll[Un]RegisterServer methods - removed the stubs of those functions from dinput_main.c - added regsvr.c to the list of source files in dinput's Makefile.in, and added ole32 and advapi32 to the list of imports It would also be good if the default registry created by winebuild contained the necessary entries to make this work (I had to add them by hand), but I couldn't find where the initial registry entries come from. If this all sounds OK, I can submit it as a patch. Although even with this support, South Park Rally fails with another DirectX problem. One step at a time though... 4. The CD audio in Sonic 3D doesn't play in Wine yet. I found there were two separate problems causing this. First, it's trying to use CD device 2. No idea where this number comes from, as I have only one CD-ROM in the system, and the game doesn't seem to be specifying device 2 anywhere. Anyone know where mcicda gets the device ID from, save me spending ages looking for it? Second, it's using TMSF (track,minutes,seconds,frames) format to specify locations on the CD. These appear as colon-separated values in the MCI commands (e.g. "02:00:00") but the argument parser chokes on them, expecting a single integer. I got around this by hacking MCI_GetDWord to recognise the colons and parse these arguments correctly, but maybe that's not the way to do it... any suggestions? Sorry this post is so long. Finally, I'd just like to say great job everyone! I was impressed that things like DirectX, InstallShield and even SecuROM copy protection are working so well - they're flawless on some of the games I tried. It's really come on since I first tried it back in 2000. Cheers, James

6 12

programs/winecfg/main.c breakage
by Gerald Pfeifer 11 Apr '04

11 Apr '04

I'm afraid the following change to programs/winecfg/main.c date: 2004/03/16 01:32:36; author: julliard; state: Exp; lines: +2 -0 Need to include config.h. broke FreeBSD (and others): /sw/gcc-3.3.2/bin/gcc -c -I. -I. -I../../include -I../../include -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o main.o main.c In file included from main.c:35: /usr/include/unistd.h:189: error: conflicting types for `select' ../../include/winsock.h:975: error: previous declaration of `select' Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

1 1

winapi_stats
by Tom 03 Apr '04

03 Apr '04

Hi, http://www.winehq.org/site/winapi_stats Is incorrect as it shows Total 19640 100% 100% would be nice but its incorect! Tom

3 6

abnt2 delete keys problem
by Rafael Ávila de Espíndola 02 Apr '04

02 Apr '04

I am having the following problem with a abnt2 (Brazilian) keyboard: When the numlock is off both delete keys work correctly. If the numlock is on both key produce a delete plus a comma. The message http://www.winehq.org/hypermail/wine-patches/2002/12/0329.html appears to describe the same problem. But the proposed patch didn't work for me. Attached is a xev log. The numlock is initially on. Them the I press the middle keyboard delete, keypad delete, numlock, middle keyboard delete and keypad delete. Thanks for any help. Rafael Ávila de Espíndola

2 4

OleDropTargetInterface prop on: RegisterDragDrop at: dlls/ole32/ole2.c
by Sebastian Wain (Hotmail) 01 Apr '04

01 Apr '04

Dear Wine Devel list, I was reading the Drag&Drop implementation in the Wine sources and didn't find a SetProp() of the handle with the property "OleDropTargetInterface" to the IDropTarget pointer. I think it's not a well documented property (not in MSDN) but it appears to be useful if somebody (sometime) will try to automate drag&drop operations. Cheers, Sebastian Wain -- http://swain.webframe.org

2 1

Regression in file handleing.
by tony_lambregts＠telusplanet.net 01 Apr '04

01 Apr '04

Andrew Talbot reports a regression in icon handling in this bug report. http://bugs.winehq.org/show_bug.cgi?id=2135 apparently it was caused by this patch http://cvs.winehq.org/patch.py?id=11698 -- Tony Lambregts

2 1

Fwd: Re: Source code visualization tools?
by Blake Leverett 01 Apr '04

01 Apr '04

Joel Konkle-Parker wrote: > Is there such a thing as a source code visualization tool that makes a > "map" of a program's source? Kind of like: > > main() > | > | > function1() > /\ > / \ > func2() func3() > | > | > func4() > > I'm basically looking for something that will help me "see" how a > program is laid out so that I can start working on it. > > Thanks in advance. > > I was looking for a similar thing a while back. One great tool for navigating the wine source is the etags program. In the wine source directory, type 'make etags'. This makes a file called TAGS. Then, start emacs, and type alt-x visit-tags-table, and load the tags file. You can navigate the source by function. See the tags manpage and the emacs manpage for the tags section for details. Blake `--------------- Forwarded message (end)

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel March 2004