February 2004 - Wine-devel - list.winehq.org

re: dialog:MSGBOX_OnInit
by Dan Kegel 25 Feb '04

25 Feb '04

vishal_wable(a)yahoo.com wrote: > I am trying to run a MFC application in Red Hat Linux 8 using WINE (latest > version). > > When i start the application with wine the application performs some intialization > but when the main window is about to be displayed, the application crashes giving > the following error. > > " fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet" > > The application contains splitter windows and a CGfxOutBar Control. > > There are a couple of modaless dialog boxes that are displayed on the main screen > when the application starts. > > I am compiling the exe in Visual Studio and then running it using wine in LINUX. That message isn't the root of your problem, I bet. http://www.winehq.com/site/documentation has info that might help you. The most common way to proceed is to figure out where the crash by turning on more verbose logging with --debugmsg options; see http://www.winehq.com/site/docs/wine-user/command-line-options#CONFIG-PARAM… Also, there's a way to use Visual Studio's debugger with Wine remotely, but I can't see where that's documented. (Hey, can anyone who knows how to do this point us to the doc?) - Dan -- US citizens: if you're considering voting for Bush, look at these first: http://www.misleader.org/ http://www.cbc.ca/news/background/arar/ http://www.house.gov/reform/min/politicsandscience/

2 1

Re: Switch kernel time functions to the new "time" debug channel
by Dimitrie O. Paun 25 Feb '04

25 Feb '04

On Wed, 25 Feb 2004, Mike Hearn wrote: > Another confusing debug channel allocation bites the dust... > > -WINE_DEFAULT_DEBUG_CHANNEL(win32); > +WINE_DEFAULT_DEBUG_CHANNEL(time); The win32 debug channel should just die, it's too generic to be useful. The entire friggin' API is Win32 :) Here is a patch that nukes it. ChangeLog Dimitrie O. Paun <dpaun(a)rogers.com> Remove the win32 debug channel, misc cleanup of debugging code. Index: ./dlls/kernel/sync.c =================================================================== RCS file: /var/cvs/wine/dlls/kernel/sync.c,v retrieving revision 1.48 diff -u -r1.48 sync.c --- ./dlls/kernel/sync.c 24 Feb 2004 01:06:30 -0000 1.48 +++ ./dlls/kernel/sync.c 25 Feb 2004 17:16:48 -0000 @@ -52,7 +52,7 @@ #include "wine/debug.h" -WINE_DEFAULT_DEBUG_CHANNEL(win32); +WINE_DEFAULT_DEBUG_CHANNEL(sync); /* check if current version is NT or Win95 */ inline static int is_version_nt(void) Index: ./dlls/kernel/syslevel.c =================================================================== RCS file: /var/cvs/wine/dlls/kernel/syslevel.c,v retrieving revision 1.3 diff -u -r1.3 syslevel.c --- ./dlls/kernel/syslevel.c 5 Nov 2003 00:52:30 -0000 1.3 +++ ./dlls/kernel/syslevel.c 25 Feb 2004 17:17:16 -0000 @@ -35,7 +35,7 @@ #include "wine/library.h" #include "wine/debug.h" -WINE_DEFAULT_DEBUG_CHANNEL(win32); +WINE_DEFAULT_DEBUG_CHANNEL(syslevel); static SYSLEVEL Win16Mutex; static CRITICAL_SECTION_DEBUG critsect_debug = Index: ./dlls/msnet32/msnet_main.c =================================================================== RCS file: /var/cvs/wine/dlls/msnet32/msnet_main.c,v retrieving revision 1.2 diff -u -r1.2 msnet_main.c --- ./dlls/msnet32/msnet_main.c 14 Mar 2003 23:00:53 -0000 1.2 +++ ./dlls/msnet32/msnet_main.c 25 Feb 2004 17:17:44 -0000 @@ -18,7 +18,7 @@ #include "wine/debug.h" -WINE_DEFAULT_DEBUG_CHANNEL(win32); +WINE_DEFAULT_DEBUG_CHANNEL(msnet); /*********************************************************************** * @ (MSNET32.57) Index: ./dlls/wintrust/wintrust_main.c =================================================================== RCS file: /var/cvs/wine/dlls/wintrust/wintrust_main.c,v retrieving revision 1.5 diff -u -r1.5 wintrust_main.c --- ./dlls/wintrust/wintrust_main.c 5 Sep 2003 23:08:26 -0000 1.5 +++ ./dlls/wintrust/wintrust_main.c 25 Feb 2004 17:18:19 -0000 @@ -27,7 +27,7 @@ #include "wine/debug.h" -WINE_DEFAULT_DEBUG_CHANNEL(win32); +WINE_DEFAULT_DEBUG_CHANNEL(wintrust); /*********************************************************************** * WinVerifyTrust (WINTRUST.@) Index: ./windows/user.c =================================================================== RCS file: /var/cvs/wine/windows/user.c,v retrieving revision 1.99 diff -u -r1.99 user.c --- ./windows/user.c 5 Feb 2004 01:24:48 -0000 1.99 +++ ./windows/user.c 25 Feb 2004 17:26:43 -0000 @@ -38,11 +38,7 @@ #include "local.h" #include "wine/debug.h" -WINE_DECLARE_DEBUG_CHANNEL(hook); -WINE_DECLARE_DEBUG_CHANNEL(local); -WINE_DECLARE_DEBUG_CHANNEL(system); -WINE_DECLARE_DEBUG_CHANNEL(win); -WINE_DECLARE_DEBUG_CHANNEL(win32); +WINE_DEFAULT_DEBUG_CHANNEL(system); static SYSLEVEL USER_SysLevel; static CRITICAL_SECTION_DEBUG critsect_debug = @@ -113,7 +109,7 @@ break; } FreeLibrary16( gdi_inst ); - TRACE_(local)("<- userPercent %d, gdiPercent %d\n", userPercent, gdiPercent); + TRACE("<- userPercent %d, gdiPercent %d\n", userPercent, gdiPercent); return (WORD)min( userPercent, gdiPercent ); } @@ -271,8 +267,8 @@ WORD WINAPI UserSignalProc( UINT uCode, DWORD dwThreadOrProcessID, DWORD dwFlags, HMODULE16 hModule ) { - FIXME_(win)("(%04x, %08lx, %04lx, %04x)\n", - uCode, dwThreadOrProcessID, dwFlags, hModule ); + FIXME("(%04x, %08lx, %04lx, %04x)\n", + uCode, dwThreadOrProcessID, dwFlags, hModule ); /* FIXME: Should chain to GdiSignalProc now. */ return 0; } @@ -291,8 +287,8 @@ */ BOOL16 WINAPI ExitWindowsExec16( LPCSTR lpszExe, LPCSTR lpszParams ) { - TRACE_(system)("Should run the following in DOS-mode: \"%s %s\"\n", - lpszExe, lpszParams); + TRACE("Should run the following in DOS-mode: \"%s %s\"\n", + lpszExe, lpszParams); return ExitWindowsEx( EWX_LOGOFF, 0xffffffff ); } @@ -481,7 +477,7 @@ ) { if (i) return FALSE; - FIXME_(system)("(%p,%ld,%p,0x%08lx), stub!\n",unused,i,lpDisplayDevice,dwFlags); + FIXME("(%p,%ld,%p,0x%08lx), stub!\n",unused,i,lpDisplayDevice,dwFlags); strcpy(lpDisplayDevice->DeviceName,"X11"); strcpy(lpDisplayDevice->DeviceString,"X 11 Windowing System"); lpDisplayDevice->StateFlags = @@ -499,7 +495,7 @@ ) { if (i) return FALSE; - FIXME_(system)("(%p,%ld,%p,0x%08lx), stub!\n",unused,i,lpDisplayDevice,dwFlags); + FIXME("(%p,%ld,%p,0x%08lx), stub!\n",unused,i,lpDisplayDevice,dwFlags); MultiByteToWideChar( CP_ACP, 0, "X11", -1, lpDisplayDevice->DeviceName, sizeof(lpDisplayDevice->DeviceName)/sizeof(WCHAR) ); MultiByteToWideChar( CP_ACP, 0, "X11 Windowing System", -1, lpDisplayDevice->DeviceString, @@ -518,7 +514,7 @@ */ FARPROC16 WINAPI SetEventHook16(FARPROC16 lpfnEventHook) { - FIXME_(hook)("(lpfnEventHook=%08x): stub\n", (UINT)lpfnEventHook); + FIXME("(lpfnEventHook=%08x): stub\n", (UINT)lpfnEventHook); return NULL; } @@ -538,10 +534,10 @@ case USUD_LOCALHEAP: return USER_HeapSel; case USUD_FIRSTCLASS: - FIXME_(local)("return a pointer to the first window class.\n"); + FIXME("return a pointer to the first window class.\n"); return (DWORD)-1; default: - WARN_(local)("wReqType %04x (unknown)\n", wReqType); + WARN("wReqType %04x (unknown)\n", wReqType); return (DWORD)-1; } } @@ -558,7 +554,7 @@ * RegisterLogonProcess (USER32.@) */ DWORD WINAPI RegisterLogonProcess(HANDLE hprocess,BOOL x) { - FIXME_(win32)("(%p,%d),stub!\n",hprocess,x); + FIXME("(%p,%d),stub!\n",hprocess,x); return 1; } @@ -569,7 +565,7 @@ LPWSTR winstation,DWORD res1,DWORD desiredaccess, LPSECURITY_ATTRIBUTES lpsa ) { - FIXME_(win32)("(%s,0x%08lx,0x%08lx,%p),stub!\n",debugstr_w(winstation), + FIXME("(%s,0x%08lx,0x%08lx,%p),stub!\n",debugstr_w(winstation), res1,desiredaccess,lpsa ); return (HWINSTA)0xdeadcafe; @@ -579,7 +575,7 @@ * SetProcessWindowStation (USER32.@) */ BOOL WINAPI SetProcessWindowStation(HWINSTA hWinSta) { - FIXME_(win32)("(%p),stub!\n",hWinSta); + FIXME("(%p),stub!\n",hWinSta); return TRUE; } @@ -591,7 +587,7 @@ PSECURITY_INFORMATION pSIRequested, PSECURITY_DESCRIPTOR pSID ) { - FIXME_(win32)("(%p,%p,%p),stub!\n",hObj,pSIRequested,pSID); + FIXME("(%p,%p,%p),stub!\n",hObj,pSIRequested,pSID); return TRUE; } @@ -602,7 +598,7 @@ LPSTR lpszDesktop,LPSTR lpszDevice,LPDEVMODEA pDevmode, DWORD dwFlags,DWORD dwDesiredAccess,LPSECURITY_ATTRIBUTES lpsa ) { - FIXME_(win32)("(%s,%s,%p,0x%08lx,0x%08lx,%p),stub!\n", + FIXME("(%s,%s,%p,0x%08lx,0x%08lx,%p),stub!\n", lpszDesktop,lpszDevice,pDevmode, dwFlags,dwDesiredAccess,lpsa ); @@ -616,7 +612,7 @@ LPWSTR lpszDesktop,LPWSTR lpszDevice,LPDEVMODEW pDevmode, DWORD dwFlags,DWORD dwDesiredAccess,LPSECURITY_ATTRIBUTES lpsa ) { - FIXME_(win32)("(%s,%s,%p,0x%08lx,0x%08lx,%p),stub!\n", + FIXME("(%s,%s,%p,0x%08lx,0x%08lx,%p),stub!\n", debugstr_w(lpszDesktop),debugstr_w(lpszDevice),pDevmode, dwFlags,dwDesiredAccess,lpsa ); @@ -627,7 +623,7 @@ * EnumDesktopWindows (USER32.@) */ BOOL WINAPI EnumDesktopWindows( HDESK hDesktop, WNDENUMPROC lpfn, LPARAM lParam ) { - FIXME_(win32)("(%p, %p, 0x%08lx), stub!\n", hDesktop, lpfn, lParam ); + FIXME("(%p, %p, 0x%08lx), stub!\n", hDesktop, lpfn, lParam ); return TRUE; } @@ -637,7 +633,7 @@ */ BOOL WINAPI CloseWindowStation(HWINSTA hWinSta) { - FIXME_(win32)("(%p)\n", hWinSta); + FIXME("(%p)\n", hWinSta); return TRUE; } @@ -646,7 +642,7 @@ */ BOOL WINAPI CloseDesktop(HDESK hDesk) { - FIXME_(win32)("(%p)\n", hDesk); + FIXME("(%p)\n", hDesk); return TRUE; } @@ -654,7 +650,7 @@ * SetWindowStationUser (USER32.@) */ DWORD WINAPI SetWindowStationUser(DWORD x1,DWORD x2) { - FIXME_(win32)("(0x%08lx,0x%08lx),stub!\n",x1,x2); + FIXME("(0x%08lx,0x%08lx),stub!\n",x1,x2); return 1; } @@ -662,7 +658,7 @@ * SetLogonNotifyWindow (USER32.@) */ DWORD WINAPI SetLogonNotifyWindow(HWINSTA hwinsta,HWND hwnd) { - FIXME_(win32)("(%p,%p),stub!\n",hwinsta,hwnd); + FIXME("(%p,%p),stub!\n",hwinsta,hwnd); return 1; } @@ -677,14 +673,14 @@ * GetUserObjectInformationA (USER32.@) */ BOOL WINAPI GetUserObjectInformationA( HANDLE hObj, INT nIndex, LPVOID pvInfo, DWORD nLength, LPDWORD lpnLen ) -{ FIXME_(win32)("(%p %i %p %ld %p),stub!\n", hObj, nIndex, pvInfo, nLength, lpnLen ); +{ FIXME("(%p %i %p %ld %p),stub!\n", hObj, nIndex, pvInfo, nLength, lpnLen ); return TRUE; } /*********************************************************************** * GetUserObjectInformationW (USER32.@) */ BOOL WINAPI GetUserObjectInformationW( HANDLE hObj, INT nIndex, LPVOID pvInfo, DWORD nLength, LPDWORD lpnLen ) -{ FIXME_(win32)("(%p %i %p %ld %p),stub!\n", hObj, nIndex, pvInfo, nLength, lpnLen ); +{ FIXME("(%p %i %p %ld %p),stub!\n", hObj, nIndex, pvInfo, nLength, lpnLen ); return TRUE; } /*********************************************************************** @@ -692,7 +688,7 @@ */ BOOL WINAPI GetUserObjectSecurity(HANDLE hObj, PSECURITY_INFORMATION pSIRequested, PSECURITY_DESCRIPTOR pSID, DWORD nLength, LPDWORD lpnLengthNeeded) -{ FIXME_(win32)("(%p %p %p len=%ld %p),stub!\n", hObj, pSIRequested, pSID, nLength, lpnLengthNeeded); +{ FIXME("(%p %p %p len=%ld %p),stub!\n", hObj, pSIRequested, pSID, nLength, lpnLengthNeeded); return TRUE; } @@ -700,7 +696,7 @@ * SetSystemCursor (USER32.@) */ BOOL WINAPI SetSystemCursor(HCURSOR hcur, DWORD id) -{ FIXME_(win32)("(%p,%08lx),stub!\n", hcur, id); +{ FIXME("(%p,%08lx),stub!\n", hcur, id); return TRUE; } @@ -709,15 +705,14 @@ */ void WINAPI RegisterSystemThread(DWORD flags, DWORD reserved) { - FIXME_(win32)("(%08lx, %08lx)\n", flags, reserved); + FIXME("(%08lx, %08lx)\n", flags, reserved); } /*********************************************************************** * RegisterDeviceNotificationA (USER32.@) */ -HDEVNOTIFY WINAPI RegisterDeviceNotificationA( - HANDLE hnd, LPVOID notifyfilter, DWORD flags -) { - FIXME_(win32)("(hwnd=%p, filter=%p,flags=0x%08lx), STUB!\n", hnd,notifyfilter,flags ); +HDEVNOTIFY WINAPI RegisterDeviceNotificationA(HANDLE hnd, LPVOID notifyfilter, DWORD flags) +{ + FIXME("(hwnd=%p, filter=%p,flags=0x%08lx), STUB!\n", hnd,notifyfilter,flags ); return 0; } -- Dimi.

1 0

VB-Error: Type mismatch
by Fabian Cenedese 25 Feb '04

25 Feb '04

Hi Who invented VB...? Ah yeah, right... I'm trying (again) to run a VB app on wine. But it never shows up. Instead I only see a dialog with this Type mismatch error and then it quits. I tried to find the place where it goes wrong. Apparently it tries to parse a number from a string in VB notation. 0009:trace:ole:VarParseNumFromStr (L"&H8000",1024,0x00000000,0x408bdee0,0x408bdae0) With my own debug messages I found that it bails out with this reason: ole:VarParseNumFromStr: Not all chars were consumed This leads to a nice exception which is caught from the VB dll: 0009:Call kernel32.RaiseException(c000008f,00000001,00000002,408be0c8) ret=6a87479d 0009:trace:seh:EXC_RtlRaiseException code=c000008f flags=1 addr=0x404b9b30 0009:trace:seh:EXC_RtlRaiseException info[0]=deadcafe 0009:trace:seh:EXC_RtlRaiseException info[1]=deadcafe 0009:trace:seh:EXC_RtlRaiseException eax=408bdf70 ebx=4057691c ecx=00000000 edx=00000004 esi=408be0d0 edi=408bdf8c 0009:trace:seh:EXC_RtlRaiseException ebp=408bdfcc esp=408bdf70 cs=0023 ds=002b es=002b fs=1007 gs=0000 flags=00000212 0009:trace:seh:EXC_CallHandler calling handler at 0x11004246 code=c000008f flags=1 0009:CALL MSVBVM60.__vbaExceptHandler(<unknown, check return>(0x40340000,00000002,00000040): returning 42b4c020 ) ret=401cac8b And this in return presents me the nice error dialog. 0009:trace:resource:LoadStringW L"Type mismatch" loaded ! Is this function VarParseNumFromStr supposed to understand VB notation as well? The docs from MS I found don't say anything about how the numbers have to be formed to be parsed well. In a small test program in C I only got the same result on Windows for these parameters. So the implementation seems ok so far. But then where did this string come from? Some property? 0009:Call oleaut32.SysAllocStringLen(42b4b70c L"FontColor",00000009) ret=6a939fac 0009:trace:heap:RtlAllocateHeap (0x40340000,00000002,00000018): returning 42b4b6a8 0009:Ret oleaut32.SysAllocStringLen() retval=42b4b6ac ret=6a939fac 0009:Call user32.CharUpperBuffW(42b4b6ac L"FontColor",0000000a) ret=6a934b66 0009:Ret user32.CharUpperBuffW() retval=0000000a ret=6a934b66 0009:RET MSVBVM60.rtcUpperCaseVar() retval=408be230 ret=1102ff69 0009:CALL MSVBVM60.__vbaVarTstEq(408be1e0,408be230) ret=1102ff8e 0009:Call oleaut32.VarCmp(408be230,408be1e0,00000000,00030001) ret=6a94f05b 0009:trace:ole:VarCmp (0x408be230->(VT_BSTR),0x408be1e0->(VT_BSTR|VT_HARDTYPE),0x00000000,0x00030001) 0009:trace:ole:VariantInit (0x408bdff8) 0009:trace:ole:VariantInit (0x408be008) 0009:Call kernel32.CompareStringW(00000000,00030001,42b4b6ac L"FONTCOLOR",ffffffff,1100b858 L"VALUE",ffffffff) ret=40c164be 0009:Ret kernel32.CompareStringW() retval=00000001 ret=40c164be 0009:Ret oleaut32.VarCmp() retval=00000000 ret=6a94f05b 0009:RET MSVBVM60.__vbaVarTstEq() retval=00000000 ret=1102ff8e 0009:CALL MSVBVM60.__vbaFreeVar() ret=1102ff96 0009:Call oleaut32.SysFreeString(42b4b6ac L"FONTCOLOR") ret=6a94f0df 0009:trace:heap:RtlFreeHeap (0x40340000,00000002,42b4b6a8): returning TRUE 0009:Ret oleaut32.SysFreeString() retval=00000001 ret=6a94f0df 0009:RET MSVBVM60.__vbaFreeVar() retval=00000001 ret=1102ff96 0009:CALL MSVBVM60.rtcMidCharVar(408be220,408be1f0,00000003,408be230) ret=1102ffff 0009:Call oleaut32.SysAllocStringByteLen(42b4bfb8,00000008) ret=6a8742d9 0009:trace:heap:RtlAllocateHeap (0x40340000,00000002,00000018): returning 42b4b6a8 0009:Ret oleaut32.SysAllocStringByteLen() retval=42b4b6ac ret=6a8742d9 0009:RET MSVBVM60.rtcMidCharVar() retval=408be220 ret=1102ffff 0009:CALL MSVBVM60.__vbaVarCat(408be210,408be220,408be1d0) ret=11030014 0009:Call oleaut32.VarCat(408be1d0,408be220,408be210) ret=6a938e10 0009:trace:ole:VarCat (0x408be1d0->(VT_BSTR),0x408be220->(VT_BSTR),0x408be210) 0009:trace:heap:RtlAllocateHeap (0x40340000,00000002,00000018): returning 42b4bfd0 VARIANT: VarCat: L"&H"+L"8000"=L"&H8000" and so on I know that color properties can have standard system values which start with &H8000... But is this the reason? And why does this get into VarParseNumFromStr? Thanks bye Fabi

2 4

Theming widgets
by Kevin Koltzau 25 Feb '04

25 Feb '04

I'm starting to work on theming some widgets, and I've come up with a few methods of doing this: 1) Add theming code to every widget itself, static link to uxtheme.dll 2) Add theming code to every widget itself, using LoadLibrary/GetProcAddress 3) Subclass widgets when uxtheme.dll is loaded and override default painting Windows takes a totally different approach, using a different version of common controls that implement theming, under windows in order to enable theming you first need a manifest to load the proper version of comctrl32 then you also must call InitCommonControls which registers the standard controls (BUTTON,EDIT,etc) Going with that, I think #3 might be the best option, and extend InitCommonControls to subclass the standard controls if theming is enabled Any comments/suggestions?

2 2

dialog:MSGBOX_OnInit
by vishal wable 25 Feb '04

25 Feb '04

Hello Sir, I am trying to run a MFC application in Red Hat Linux 8 using WINE (latest version). When i start the application with wine the application performs some intialization but when the main window is about to be displayed, the application crashes giving the following error. " fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet" The application contains splitter windows and a CGfxOutBar Control. There are a couple of modaless dialog boxes that are displayed on the main screen when the application starts. I am compiling the exe in Visual Studio and then running it using wine in LINUX. Could you please help me to solve this problem. Regards, Vishal Wable --------------------------------- Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want.

1 0

Document Crosstest
by Uwe Bonnes 25 Feb '04

25 Feb '04

Hallo, http://www.winehq.com/site/docs/wine-devel/testing-windows 4.5.3. With MinGW should read: Have mingw installed. For an RPM package look e.g. at http://mirzam.it.vu.nl/mingw/ Run "make crosstest". Run test like "wine -- msvcrt_crosstest.exe scanf.c" on wine or "msvcrt_crosstest.exe scanf.c" on windows -- 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

Re: More msvcrt scanf tests
by Alexandre Julliard 25 Feb '04

25 Feb '04

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > + todo_wine ok(strstr(buffer,"e+008") != 0,"Sprintf different \"%s\"\n",buffer); > + sprintf(buffer,I64x,(ULONGLONG)0xffffffffffffffff); Long long constants are not portable, you need to compute them from long constants. -- Alexandre Julliard julliard(a)winehq.org

5 9

RFC: OlePicture patch
by Fabian Cenedese 25 Feb '04

25 Feb '04

Hi Can anybody comment on this? http://www.winehq.org/hypermail/wine-patches/2004/02/0121.html I know that it's not the best solution (or if it is it's without explanation). I tried to find anything about this magic number but I found nothing. Unless someone has a reason _not_ to apply it I vote in favour of it. It helps VB programs with the SSTab control without pictures assigned to the tabs to load properly. As there are no pictures it shouldn't read more data from the stream and try to create a picture with wrong data. Thanks bye Fabi

1 0

Fun quickfix
by Mike Hearn 25 Feb '04

25 Feb '04

Hi, Here's an easy to fix bug for somebody wanting to get into Wine hacking, or who has a spare few minutes. The basic problem is with the tab control and can be seen by running http://bylands.dur.ac.uk/~mh/Tab.exe ... that (from control spy). As you can see on the bottom row, the top of the tabs are overdrawn by the row above. Putting a Sleep call into the tab drawing code reveals that we're not drawing the tabs in any particular order (presumably it's the order they were added) and reading the code indicates that having TAB_DrawItem overdraw its bottom is the expected behaviour. The code can be seen in dlls/comctl32/tab.c, in TAB_Refresh and TAB_DrawItem One fix is to draw the tabs from top row to the bottom, instead of in a random order. In order to do that, you need to read the code in TAB_SetItemBounds and add a new field to TAB_ITEM to record which row it was placed in. Then, in TAB_Refresh, firstly sort the TAB_ITEMS topmost to bottommost before drawing them. This shouldn't be too hard, but would fix a nasty visual glitch in Wine. If anybody feels like doing it but gets stuck feel free to ask here for help. On the other hand if you're an old hand at Wine feel free to fix it too, there's little point keeping bugs around for training purposes :) thanks -mike

3 2

Re: Pipe tests coprrected
by Ferenc Wagner 25 Feb '04

25 Feb '04

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Changelog: > dlls/kernel/tests/pipe.c > Added tests for redirected STDIN/STDOUT > Added todo_wine test for waiting on closed pipe > > The tests now succeed on NT40(vmware) They do on XP, too. The MinGW-compiled binary now won't run from a network drive. Also, test 3 of 7 loops, so I didn't run it. Apart from that, the report goes like below. -- Feri. pipe.c:823:test 1 of 7: pipe.c:645: Test failed: CreateNamedPipe failed pipe.c:647: Test failed: WriteFile to not-yet-connected pipe pipe.c:649: Test failed: ReadFile from not-yet-connected pipe pipe.c:653: Test failed: CreateFile failed pipe.c:673: Test failed: CloseHandle pipe.c:825:test 2 of 7: pipe.c:264: Test failed: CreateNamedPipe failed pipe.c:272: Test failed: CreateNamedPipe failed pipe.c:274: Test failed: CloseHandle pipe.c:275: Test failed: CloseHandle pipe.c:284: Test failed: CreateNamedPipe failed pipe.c:292: Test failed: nMaxInstances not obeyed pipe.c:295: Test failed: CloseHandle pipe.c:304: Test failed: CreateNamedPipe failed pipe.c:312: Test failed: PIPE_ACCESS_* mismatch allowed pipe.c:315: Test failed: CloseHandle pipe.c:827:test 3 of 7: should be fixed pipe.c:829:test 4 of 7: pipe.c:149:test_CreateNamedPipe starting pipe.c:174: Test failed: connecting to nonexistent named pipe should fail with ERROR_FILE_NOT_FOUND pipe.c:186: Test failed: CreateNamedPipe failed pipe.c:189: Test failed: CreateFile failed pipe.c:248: Test failed: CloseHandle pipe.c:250:test_CreateNamedPipe returning pipe.c:831:test 5 of 7: pipe.c:833:test 6 of 7: pipe.c:835:all tests done pipe: 44 tests executed, 0 marked as todo, 19 failures.

1 0