wine-devel

wine-devel@winehq.org

6 participants
84404 discussions

Re: Fix for focus loops
by Jukka Heinonen 17 May '02

17 May '02

On Tue, May 07, 2002, Alexandre Julliard wrote: > I've been working on this too, and I found that the locally active > model seems to work better with most window managers, even though it's > not 100% correct per the spec. Here's the patch I have, please give it > a try and let me know how it works for you. If your patch is used in globally active mode (Wine config file has "UseTakeFocus" = "Y"), focus loop problem is fixed. However, if I try locally active mode, Wine still enters focus loop. Some comments about the patch and Wine focus handling: - Timestamp used in X11DRV_SetFocus is wrong when focus has been gained either due to WM_TAKE_FOCUS or due to FocusIn. - Routine X11DRV_SetFocus may fail to set focus because focus might have already been passed to another X11 window. In unmanaged mode this is fatal: override_redirect windows receive neither WM_TAKE_FOCUS nor FocusIn and if Wine believes that a window already has focus it won't call X11DRV_SetFocus even when the window receives mouse clicks. - If X11DRV_SetFocus fails, Wine routine that triggered this call (SetForegroundWindow, SetActiveWindow, SetFocus, etc) should also fail. This is what NT5.0 does according to docs, by the way. This would make it easy to see which window really has focus. - It is likely that last_focus will be wrong if routine X11DRV_SetFocus fails as described above. - All Wine windows using override_redirect break ICCCM. This includes all windows in unmanaged mode. In general, it is not possible for override_redirect windows to gain input focus without confusing focus handling of window managers. There are two exceptions to this generalization which likely apply to full-screen applications and menus. - In locally active model, transferring focus from top-level window to active dialog window requires timestamp CurrentTime which breaks ICCCM compliance. This can break window manager focus handling in some cases. This is likely not very big an issue, but I believe that everything that breaks standards should be properly commented. - One not directly focus relared problem is that some window managers always put override_redirect windows on top of managed windows. And when you run some applications in managed mode, Wine creates a full screen override_redirect window which has managed dialog window... Looking at this list makes me believe that fixing Wine focus handling should be assigned much higher priority than it has been so far. -- Jukka Heinonen <http://www.iki.fi/jhei/>

4 6

Problem after update
by Marcelo Welter 17 May '02

17 May '02

Hello I make cvs update -RdP configure make depend make ./snmpapi.spec:6: Expected name, id, length or ordinal make[2]: *** [snmpapi.spec.c] Error 1 make[2]: Leaving directory `/home/marcelo/wine/cvs/wine/dlls/snmpapi' make[1]: *** [snmpapi/snmpapi.dll.so] Error 2 make[1]: Leaving directory `/home/marcelo/wine/cvs/wine/dlls' make: *** [dlls] Error 2 what happen? the syntax of cvs that i use are correct...? Thanks Marcelo

3 2

Component owner for window management/painting
by Andriy Palamarchuk 17 May '02

17 May '02

Any volunteers for handing this kind of problems? Andriy __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

1 0

Re: Patch - check for msghdr.msg_control on Sparc-Solaris
by Warren_Baird＠cimmetry.com 17 May '02

17 May '02

> I think it would be better to do it using a technique similar to how it > is done in scheduler/client.c on line 255: Makes sense to me - it wasn't obvious that msg_control and msg_accrights are always mutually exclusive, which is why I added a separate test... But if we're sure they are always mutally exclusive, this approach makes more sense... Warren

1 0

err:heap:HEAP_ValidateInUseArena
by John K. Hohm 17 May '02

17 May '02

I am implementing a COM object in comcat.dll that allocates itself with HeapAlloc and frees itself on its last Release with HeapFree. I am using it in a simple test program that creates it and releases it, and when the Release happens I get this: err:heap:HEAP_ValidateInUseArena Heap 40340000: in-use arena 40378878 next block has PREV_FREE flag It seems to be saying that I'm freeing an already-free block. I ran the test program with --debugmsg trace+all, and I can see that the only uses of the heap during the lifetime of my object instance are one ntdll.RtlAllocateHeap that returns 40378880, and one ntdll.RtlFreeHeap that gets 40378880 as its third param. The RtlFreeHeap is immediately followed by the err:heap, which then spits out a bunch of heap info. It seems pretty obvious that I'm freeing the block of memory I had just allocated; what else might be causing the err:heap? Here is the interesting section of the trace: 080701d0:trace:ole:COMCAT_ICatInformation_EnumCategories 080701d0:Call ntdll.RtlAllocateHeap(40340000,00000008,00000020) ret=4397c0f3 080701d0:trace:heap:RtlAllocateHeap (40340000,0000000a,00000020): returning 40378880 080701d0:Ret ntdll.RtlAllocateHeap() retval=40378880 ret=4397c0f3 080701d0:trace:ntdll:NTDLL_vsnwprintf (2147483647,L"%lX") 080701d0:Call advapi32.RegOpenKeyExW(80000000,40566ce8 L"Component Categories",00000000,00020019,40378898) ret=4397c170 080701d0:Call ntdll.RtlInitUnicodeString(40566bd8,40566ce8 L"Component Categories") ret=40660189 080701d0:Ret ntdll.RtlInitUnicodeString() retval=0000002a ret=40660189 080701d0:Call ntdll.NtOpenKey(40378898,00020019,40566be0) ret=40660194 080701d0:trace:reg:NtOpenKey (0x80000000,L"Component Categories",20019,0x40378898) 080701d0: open_key( parent=-2147483648, access=00020019, name=L"Component Categories" ) Open key ERROR 080701d0: open_key() = OBJECT_NAME_NOT_FOUND { hkey=0 } 080701d0:trace:reg:NtOpenKey <- 0x0000 080701d0:Ret ntdll.NtOpenKey() retval=c0000034 ret=40660194 080701d0:Call ntdll.RtlNtStatusToDosError(c0000034) ret=4066019a 080701d0:Ret ntdll.RtlNtStatusToDosError() retval=00000002 ret=4066019a 080701d0:Ret advapi32.RegOpenKeyExW() retval=00000002 ret=4397c170 080701d0:trace:ole:COMCAT_IEnumCATEGORYINFO_AddRef 080701d0:trace:ole:COMCAT_IEnumCATEGORYINFO_Next 080701d0:trace:ole:COMCAT_IEnumCATEGORYINFO_Release 080701d0:Call ntdll.RtlFreeHeap(40340000,00000000,40378880) ret=4397be9d 080701d0:err:heap:HEAP_ValidateInUseArena Heap 40340000: in-use arena 40378878 next block has PREV_FREE flag

2 1

Re: wine/ dlls/Makefile.in dlls/avicap32/Makefile. ...
by Dimitrie O. Paun 17 May '02

17 May '02

On May 16, 2002 11:37 pm, Alexandre Julliard wrote: > Log message: > Removed most imports of ntdll since we no longer import Wine internal > functions from there. Yay! I've been advocating putting all the wine-specific stuff in a "helper" dlls (libwine) for soo long now, specifically for the purpose of the "Windows" port. Now, the linking things is still a bit of mistery to me. Let's see: -- libwine is linked with all DLLs using the host's native dynlinking tool -- when a program is loaded, _wine_ loads the required DLLs which in turns gets linked by the OS to libwine. Is that so? To be honest, this is how I *think* it works, I haven't actually gone through the code, but I'm feeling lazy tonight :))) -- Dimi.

2 1

Re: wine/ controls/menu.c dlls/commdlg/cdlg32.c dl ...
by Dimitrie O. Paun 17 May '02

17 May '02

On May 16, 2002 10:55 pm, Alexandre Julliard wrote: > > Log message: > Export the debugging API from libwine instead of ntdll. > Removed debugres_[aw]. I think you need to test for null strings in default_dbgstr_[aw]n, no? Also, the default implementations are there for the mingw port? We normally use the ones from NTDLL_dbgstr_*, right? -- Dimi.

2 1

64bit values in API args...
by Vincent Béron 17 May '02

17 May '02

I have a little problem implementing VerifyVersionInfo{A,W}. Here's the prototype of the function (W): BOOL WINAPI VerifyVersionInfoW( LPOSVERSIONINFOEXW lpVersionInfo, DWORD dwTypeMask, DWORDLONG dwlConditionMask) with DWORDLONG being a 64bit value. Now, how do I translate that in kernel32.spec? The current declaration in kernel32.spec is @ stdcall VerifyVersionInfoW(long long long long) VerifyVersionInfoW with either a try to get a "long long" type (undistinguishable from 2 longs), or by just assuming a virtual fourth argument to get the right total argument size. Now, this seems really fishy. I'm not very familiar with the way a C compiler places arguments either in registers or on the stack, but I'm not sure the way it is currently declared is the best way to do it. I'd prefer to define a new type for use in spec files, meaning a 64bit argument. Comments? BTW, for the moment VerifyVersionInfo seems to be the only place in Wine where the DWORDLONG type is used, but that doesn't mean there are no other unimplemented API using it. Vincent

1 0

Component owner for controls
by Andriy Palamarchuk 17 May '02

17 May '02

Does anybody want to voluteer to take ownership over usual controls? I already have owners for common controls Andriy __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com

2 1

Open watcom
by Uwe Bonnes 17 May '02

17 May '02

Hallo, today, there was an announce of a 0.0.8 release of open watcom on the linux announce newsgroup: http://www.openwatcom.org ftp://ftp.openwatcom.org/watcom/openwatcom Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Jump to page:

2025

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