- Wine-Devel - list.winehq.org

Re: LOCALE: Don't copy value if buffer is too small
by Alexandre Julliard Feb. 26, 2004

Feb. 26, 2004

Fabian Cenedese <Cenedese(a)indel.ch> writes: > Ok, I saw that you fixed the WCHAR/byte mess. But there is still a possibility that > the function can copy a string longer than buffer if it already has an appended null. That shouldn't happen, NtQueryValue should have signaled an overflow in that case. Do you have a test case showing the problem? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: Native NetBSD audio driver
by Yorick Hardy Feb. 26, 2004

Feb. 26, 2004

I was thinking to look at the integration of the oss and NetBSD drivers this weekend (following Eric and Dimi's suggestion). Should I rather wait until some restructuring is done? The inclusion of the NetBSD audio driver is not urgent since oss already works quite well, and it stagnated on my hard disk for months before I submitted anyway. I am not going to volunteer for the restructuring since I have a long overdue thesis to finish ;-). >> I think it might be worthwhile considering restructuring the audio >> drivers into hardware independent wave, direct sound, midi >> and mixer sections and a hardware dependent low level >> implementation for oss, alsa, ... > >Yes we should definitely do something like that. This sound driver >business is becoming a huge mess. Kind regards, Yorick Hardy. -------------------------------------------------------- This message was sent using MetroWEB's AirMail service. http://www.metroweb.co.za/ - full access for only R59. Free WebMail, Calendar, Anti-Virus, Anti-Spam, 10 emails Phone Now! 086 11 11 440

1 0

Help needed to get the application work for native linux editors
by saravanan Feb. 26, 2004

Feb. 26, 2004

Hai friends, I successfully ran a script manager(keyboard Manager/driver) developed for windows (using VC++) in Linux using wine. Its working in the wordpad application called using wine.I want to make it work in Linux editors. The technical details about the working of the keyboard driver is as follows. 1) The keyboard driver is a keyboard hooker program. The keyboard driver will trap all the keystrokes from the keyboard and convert the Ascii value to the appropriate native language Character code. 2) First we have to get the handle of the window/control where the cursor is currently located, for that the GetFocus API is used. 3) Virtual-key code of the key that generated the keystroke message is converted to appropriate another code for making the keyboard Inscript or phonetic and send using Postmessage API. I have some doubts. Do these APIs written for windows work in linux. In linux , How could i get the handle of the window where the cursor is currently located. What are the changes that i should make in the source code to make it work for linux editors. Looking for your suggessions. Thanks in advance . Saravanan ______________________________________ Scanned and protected by Email scanner

1 0

Re: DCE: LockWindowUpdate
by Mike Hearn Feb. 25, 2004

Feb. 25, 2004

Hi Ken, I'm really sorry about this but I already implemented LockWindowUpdate about a month or two ago. Unfortunately it is blocking on moving invalidation handling into the wineserver, and was not applied. So, I'm afraid that (a) the work has already been done and (b) the patch you sent, is wrong. I made the same mistake at first - unfortunately LockWindowUpdate is a global thing, ie the locked window is held in-kernel on Windows. Alexandre: I said at the time we should apply the patch I sent but disable it, so it doesn't get lost/forgotten about. Here's another reason we should do that - it'll stop people reimplementing what has already been done. thanks -mike On Wed, 25 Feb 2004 13:28:19 -0500, Ken Belleau wrote: > When there is a locked window, GetDCEx and related functions now returns > DCs with an empty visible region unless DCX_LOCKWINDOWUPDATE is > specified.

2 1

re: dialog:MSGBOX_OnInit
by Dan Kegel Feb. 25, 2004

Feb. 25, 2004

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 Feb. 25, 2004

Feb. 25, 2004

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 Feb. 25, 2004

Feb. 25, 2004

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 Feb. 25, 2004

Feb. 25, 2004

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 Feb. 25, 2004

Feb. 25, 2004

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 Feb. 25, 2004

Feb. 25, 2004

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