April 2008 - Wine-devel - list.winehq.org

Re: [PATCH] user32: Handle VK_RETURN KeyDown events more properly in EDIT controls.
by Lei Zhang 19 Apr '08

19 Apr '08

On Fri, Apr 18, 2008 at 3:50 PM, El. <elptr(a)users.sourceforge.net> wrote: > When a ES_MULTILINE-styled EDIT responds to a VK_RETURN Key press, it should > send a WM_COMMAND to the default control of the parent window if and only if > that parent is a Dialog box. At least Microsoft's version of notepad.exe > (WinXP) is fixed. > BTW, bug 12478 [1] appears to be related to this. [1] http://bugs.winehq.org/show_bug.cgi?id=12478

1 0

Re: [PATCH] user32: Handle VK_RETURN KeyDown events more properly in EDITcontrols.
by El. 19 Apr '08

19 Apr '08

> "El." <elptr(a)users.sourceforge.net> wrote: > > > @@ -4606,6 +4606,10 @@ static LRESULT EDIT_WM_KeyDown(EDITSTATE *es, INT key) > > { > > HWND hwndParent = GetParent(es->hwndSelf); > > DWORD dw = SendMessageW( hwndParent, DM_GETDEFID, 0, 0 ); > > + > > + if (GetClassLongW(hwndParent, GCW_ATOM) != WC_DIALOG) > > + break; > > You need to add a test case first to confirm that the fix is correct, and > use EDIT_IsInsideDialog to detect if the parent is dialog. Well I'm not sure what to test in the first place, I didn't assume that modifying some aspect of the code to be in compliance with official "standards" required writing any test case. I might be missing what you mean by the "correctness" of the fix, since I'm not really familiar with Wine's patching practices. http://msdn2.microsoft.com/en-us/library/bb775464(VS.85).aspx As for using EDIT_IsInsideDialog, that I can manage.

3 3

[lostwages] update LGPL url, specify version
by Dan Kegel 19 Apr '08

19 Apr '08

Somebody on wine-users asked us to clarify this, so:

1 0

Re: [PATCH 2/2] wined3d: Prevent console spamming in drawPrimitive.
by H. Verbeet 19 Apr '08

19 Apr '08

On 18/04/2008, Alexander Dorofeyev <alexd4(a)inbox.lv> wrote: > Fixes massive slowdown in games like Aliens vs Predator 2. > If you care about performance you should always run with WINEDEBUG="-all" anyway.

2 3

Re: WINED3D: Fix a possible null dereference.
by H. Verbeet 19 Apr '08

19 Apr '08

On 19/04/2008, David Adam <david.adam.cnrs(a)gmail.com> wrote: > The Sting Demo calls the function > IDirect3DDeviceImpl_7_SetMaterial (in ddraw/device.c) with > Mat=NULL. > Then, this makes the function IWineD3DDeviceImpl_SetMaterial (in > wined3d/device.c) crashes in the line > This->updateStateBlock->material = *pMaterial; > So, the patch checks is the material is not null before assignating it. > > This fixes a crash in The Sting demo. > > David Adam > I would like to see a few tests that prove this is the correct behaviour (instead of eg. simply returning WINED3DERR_INVALIDCALL), for ddraw, d3d8 and d3d9.

1 0

Trying to get a grip on how to handle bug reports.
by Kai Blin 19 Apr '08

19 Apr '08

Hi folks, I seem to have done something wrong referring a user to a closed bug report that seemed to be related to the problem he was having. (See bug 11639 for more context) So in order to avoid me being the cause a user defiles the holy status of a closed bug, I'd like to have some clear rules on how to handle related bug reports. And you folks wonder why we don't have a healthy user community. Sometimes I feel like talking to a brick wall. Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

4 4

Re: [PATCH] user32: Handle VK_RETURN KeyDown events more properly in EDITcontrols.
by Dmitry Timoshkov 19 Apr '08

19 Apr '08

"El." <elptr(a)users.sourceforge.net> wrote: > @@ -4606,6 +4606,10 @@ static LRESULT EDIT_WM_KeyDown(EDITSTATE *es, INT key) > { > HWND hwndParent = GetParent(es->hwndSelf); > DWORD dw = SendMessageW( hwndParent, DM_GETDEFID, 0, 0 ); > + > + if (GetClassLongW(hwndParent, GCW_ATOM) != WC_DIALOG) > + break; You need to add a test case first to confirm that the fix is correct, and use EDIT_IsInsideDialog to detect if the parent is dialog. -- Dmitry.

1 0

Hack: Debug a specific critical section WINE_DEBUG_SPINLOCK
by Maarten Lankhorst 18 Apr '08

18 Apr '08

Hi all, I created a hack to debug a specific critical section with WINE_DEBUG_SPINLOCK environment. It was useful for me because it found a very weird deadlock, a thread would terminate before releasing its critical section. It will also change the timeout to 1 second so you will get a faster response on potential latency issues. How to use it? First you need the exact spinlock name. for example in parser.c: pParser->csFilter.DebugInfo->Spare[0] = (DWORD_PTR)(__FILE__ ": ParserImpl.csFilter"); Of course you still need to know what __FILE__ is, this is usually parser.c but I'm not 100% sure that is the same for out of tree builds. So just to be sure: $ strings parser.o |grep csFilter parser.c: ParserImpl.csFilter export WINE_DEBUG_SPINLOCK="parser.c: ParserImpl.csFilter" It will then print a ++ for every time a lock is entered, and -- for every time lock is left., I would recommend mixing this with WINEDEBUG=+tid so you can also see the threads they are in. Comments? Cheers, Maarten.

1 0

Re: Wine release 0.9.60
by Adrian Bunk 18 Apr '08

18 Apr '08

On Fri, Apr 18, 2008 at 05:59:16PM +0200, Alexandre Julliard wrote: >... > Bugs fixed since 0.9.59: >... > 7174 Master of Orion 2 does not switch screen resolution correctly >... That this bug is listed as "fixed since 0.9.59" is wrong, and it sounds as if you wrongly count all bugs closed since 0.9.59 as having been present in 0.9.59? Looking through some of the other bugs (especially older ones) the information in Bugzilla indicates for several other bugs listed in your announcement that they were not "fixed since 0.9.59". You Wine developers are doing a great job, but especially since you are currently actively triaging older bugs "fixed since 0.9.59" is quite different from "closed since 0.9.59". > Alexandre Julliard cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed

2 3

Re: Trouble in compiling Wine 0.9.57 and 0.9.58 on Solaris 10 08/07
by Petr Sumbera 18 Apr '08

18 Apr '08

>isinf is a function / macro which returns wether or not a float is positive >infinite or negative infinite. I think it is a standard C function. Maybe >solaris declares it in some header that needs to be included, like math.h? I have logged for this bug: http://bugs.winehq.org/show_bug.cgi?id=12008 Not sure where to find it exactly. But isinf seems to be defined by ISO 99 (not by standard C). Regards, Petr

4 6