wine-devel July 2001

wine-devel@winehq.org

62 participants
189 discussions

RE: -DSTRICT warning fixes
by Patrik Stridvall 28 Jul '01

28 Jul '01

> On Sat, 28 Jul 2001, Patrik Stridvall wrote: > [...] > > The real reason that we should support compiling Wine with -DSTRICT > > is not because handles becomes pointers but because callbacks gets > > the correct prototype. > > > > I case not you haven't realized the obvious, it doesn't matter if > > the handles are 32-bit integer or 32-bit pointers as long as > > all handles are the same. The code either > > No, I think you have missed something: when compiling with -DSTRICT > on all handles are not the same. Note I said same but meant compatible. Wrong choice of words. > For instance you cannot do > hDesk=hAccel. That's because with -DSTRICT on you have: > > typedef struct HDESK__ { int unused; } *HDESK; > typedef struct HACCEL__ { int unused; } *HACCEL; > > Thus HDESK and HACCEL are incompatible pointer types. This > brings us > more type safety which is the whole point of -DSTRICT. Oh sure, but the point is that if code, that are semanticly correct, cares whether you are strict or relax the type, the code it wrong. Perhaps I was I little unclear on that point. Being strict obviously makes it easier to find semantic errors, but that was not the point at all. > About 64bits Windows I don't know yet how we are going to do that. > But you have to check exactly what Windows 64bit does, not just > extrapolate from the way Unix 64bit does things. AFAIK the > approach used > by windows is quite different from that which Unices took. Yes, unfortunately, but I'm primarily worried about Win32 on 64-bit platforms.

1 0

RE: -DSTRICT warning fixes
by Patrik Stridvall 28 Jul '01

28 Jul '01

> > If we do that can just do > > s/DECLARE_OLD_HANDLE/DECLARE_HANDLE/ > > on the handle types on by one and fix the warnings. > > That's precisely the plan, and it is just the opposite of what you are > doing with your patch (you are turning DECLARE_HANDLE back into > DECLARE_OLD_HANDLE). The reason I did that was that they can't be fixed as long as HANDLE/HGLOBAL is the wrong types. When they become the right types the warnings will automatically disappear and we can do s/DECLARE_OLD_HANDLE/DECLARE_HANDLE/. But there is no reason to have a lot of warnings that can't be fixed otherwise until then. > Yes you get a number of warnings if you turn > -DSTRICT on, most of them should disappear once the conversion is > complete; fixing them before that is a waste of time. Since we can't fix before that why show them at all? People that want to fix for example output messages can do, s/DECLARE_OLD_HANDLE/DECLARE_HANDLE/ in their tree, fix them and submit the patches (without the s/DECLARE_OLD_HANDLE/DECLARE_HANDLE/). > This is the > reason why -DSTRICT is not the default yet. Read bug report #90, > Francois explains everything there. OK. I have read bug report #90 now. > And don't forget the number one rule of the -DSTRICT conversion is: > *no* *typecasts*. If you have to add typecasts something is wrong. No typecasts where the handle is used in conjuction with other handles, certainly not, no argument there. The code some expect all handles to be the of same type. However for the debugging output I disagree. I orginally thought as Francois (and you it seems) that handles are pointers and should be treated as such. But then I realized that when we implement Win32 on 64-bit platforms we can't have handles as pointers even internally if we wan't to support x86 emulation and even exposing a 64-bit handle to Winelib application can only cause trouble since they might store it is a 32-bit memory location. Sure we will probably be able to handle 64-bit pointers truncated to 32-bit by storing all objects in the lower 32-bit part of memory, but fear it might cause trouble all the same. Beside doing TRACE("(%p)", handle) on 64-bit platforms will needlessly display the always the same presumably zero upper 32-bit part of the handle. That why I decided to should use TRACE("(0x%08lx)", (DWORD) handle) instead to avoid such issues. In short, the code should IMHO support both 32-bit pointers as well and 32-bit integers as handles presuming of course that all handles use the same. The real reason that we should support compiling Wine with -DSTRICT is not because handles becomes pointers but because callbacks gets the correct prototype. I case not you haven't realized the obvious, it doesn't matter if the handles are 32-bit integer or 32-bit pointers as long as all handles are the same. The code either 1. Just pass them around as the same type of handles of other types of handles (HANDLE/HGLOBAL). 2. Tries to access the underlying object, in such case a void pointer will not do use any good, we must use a cast either after calls to functions like GlobalLock or alone.

2 1

Re: -DSTRICT warning fixes
by Alexandre Julliard 28 Jul '01

28 Jul '01

Patrik Stridvall <ps(a)leissner.se> writes: > However for the debugging output I disagree. I orginally thought > as Francois (and you it seems) that handles are pointers and should > be treated as such. But then I realized that when we implement Win32 on > 64-bit platforms we can't have handles as pointers even internally if > we wan't to support x86 emulation and even exposing a 64-bit > handle to Winelib application can only cause trouble since they > might store it is a 32-bit memory location. Sure we will probably be > able to handle 64-bit pointers truncated to 32-bit by storing all > objects in the lower 32-bit part of memory, but fear it might > cause trouble all the same. Handles are pointers in the Windows API, and they should be pointers inside of Wine. On a 64-bit platforms pointers will be 64-bit, and so will handles. If you want to run 32-bit code on such a platform you need a conversion for pointers anyway, so you might as well use the same conversion for handles. Not to mention that some handles are actually pointers (like HMODULE). So no, there is absolutely no reason to force handles to be 32 bits. > Beside doing TRACE("(%p)", handle) on 64-bit platforms will needlessly > display the always the same presumably zero upper 32-bit part > of the handle. That why I decided to should use > TRACE("(0x%08lx)", (DWORD) handle) instead to avoid such issues. Sorry but this is wrong. Handles are pointers and must be printed as pointers. Assuming that handles are always exactly 32-bit is very shortsighted. > The real reason that we should support compiling Wine with -DSTRICT > is not because handles becomes pointers but because callbacks gets > the correct prototype. No, it's because handles become pointers; you cannot do the -DSTRICT typechecking with integers anyway. Callbacks are a very minor issue; the real point is to fix all incorrect handle manipulations, like implicit 16-bit handle conversions or arithmetic on handle values. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: -DSTRICT warning fixes
by Alexandre Julliard 28 Jul '01

28 Jul '01

Patrik Stridvall <ps(a)leissner.se> writes: > Concerning some parts of my warnings patch that was > partly rejected I disagree with the rejection. > The patch in question is in warnings_rejected.diff. > Note the field "u" is a union. But perhaps you know > and rejected it for other reasons? I know it is a union; I thought it was one of these cases that would get fixed by -DSTRICT, but now I see that it is a slightly different problem. I'll apply it. > If you accept all the strict_*.diff patches, perhaps we > should consider adding -DSTRICT as a permanent flag? > It removes the HOOKPROC/TIMERPROC warnings that is not > possible to fix otherwise. > > If we do that can just do > s/DECLARE_OLD_HANDLE/DECLARE_HANDLE/ > on the handle types on by one and fix the warnings. That's precisely the plan, and it is just the opposite of what you are doing with your patch (you are turning DECLARE_HANDLE back into DECLARE_OLD_HANDLE). Yes you get a number of warnings if you turn -DSTRICT on, most of them should disappear once the conversion is complete; fixing them before that is a waste of time. This is the reason why -DSTRICT is not the default yet. Read bug report #90, Francois explains everything there. And don't forget the number one rule of the -DSTRICT conversion is: *no* *typecasts*. If you have to add typecasts something is wrong. -- Alexandre Julliard julliard(a)winehq.com

1 0

(no subject)
by Ladislav Sladecek 28 Jul '01

28 Jul '01

Alexandre Julliard: > I think GetClipBox is correct, the problem is > that the WM_ERASEBKGND > handler should not be using it, but > GetClientRect. You can try this: Hello Alexandre, thank you for your reccomendation. Unfortunately the DefWindowProc improvement does not help, because the default handler newer gets called in my app. The application (Progress _prowin.exe version 7) uses custom dialog boxes (forms) and also custom controls. The controls handle WM_ERASEBKGND themeselves. I have no access to the sources. What I know about GetClipRect, I know from the trace. I agree that your method (GetClientRect in the handler) is much better, but I cannot use it. I also agree that Windows should return the parent area in GetClipBox as Wine does. Unfortunalelly, the Windows do not do that while the _prowin.exe depends on it. I enclose a simple C example which I hacked to demonstrate this. The example displays two red children in a white parent. The value returned by GetClipBox is wsprintf-ed. If you run the binary in the Windows, you will see two properly sized red rectangles on a white background. If you run the same binary in Wine, you will see only one large red child but no white parent background. If either the CS_PARENTDC or WS_CLIPSIBLINGS gets removed from my example, both Windows and Wine give identical results. Regards Ladislav Sladecek

1 0

Re: -DSTRICT warning fixes
by Francois Gouget 28 Jul '01

28 Jul '01

- FIXME("(%x),stub!\n",hrasconn); + FIXME("(0x%08lx): stub\n", (DWORD) hrasconn); [...] I think I would rather use %p to print handles. After all they are pointers, not integers. The annoying aspect of it is that %08p is not very well supported IIRC. Maybe gcc has been fixed though. I forgot to mention it before. But I assume you saw bug #90. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong

1 0

wine on clusters ??
by Francisco Perez 28 Jul '01

28 Jul '01

Hi everybody: Has anybody tried to run wine on a High Availabity cluster ?. Especifically we are interested on a Mosix environment where applications don't need be changed. The windows application to be clustered is a Remote IP network back-up system so no grafic intensive or plug modern like ActiveX and so. Any comments are highly apreciated thanks

1 0

Re: PATCH: wrong clipRect when CS_PARENTDC and WS_CLIPSIBLINGS styles are combined
by Alexandre Julliard 28 Jul '01

28 Jul '01

lsla(a)post.cz writes: > Where the Wine's GetClipRect returns the area of the parent, the > Windows version returns only the area of the child. Therefore in > Wine the WM_ERASEBKGND message erases the whole parent including the > other radio buttons. I think GetClipBox is correct, the problem is that the WM_ERASEBKGND handler should not be using it, but GetClientRect. You can try this: Index: windows/defwnd.c =================================================================== RCS file: /opt/cvs-commit/wine/windows/defwnd.c,v retrieving revision 1.57 diff -u -r1.57 defwnd.c --- windows/defwnd.c 2001/06/20 23:16:34 1.57 +++ windows/defwnd.c 2001/07/27 23:47:26 @@ -457,20 +457,15 @@ case WM_ICONERASEBKGND: { RECT rect; + HDC hdc = (HDC)wParam; HBRUSH hbr = GetClassLongW( wndPtr->hwndSelf, GCL_HBRBACKGROUND ); if (!hbr) return 0; - /* Since WM_ERASEBKGND may receive either a window dc or a */ - /* client dc, the area to be erased has to be retrieved from */ - /* the device context. */ - GetClipBox( (HDC)wParam, &rect ); - - /* Always call the Win32 variant of FillRect even on Win16, - * since despite the fact that Win16, as well as Win32, - * supports special background brushes for a window class, - * the Win16 variant of FillRect does not. - */ - FillRect( (HDC) wParam, &rect, hbr ); + /* GetClientRect used to be GetClipBox, but it is not what + * Windows does, and it breaks badly with CS_PARENTDC */ + GetClientRect( wndPtr->hwndSelf, &rect ); + DPtoLP( hdc, (LPPOINT)&rect, 2 ); + FillRect( hdc, &rect, hbr ); return 1; } -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: winapi update
by Patrik Stridvall 27 Jul '01

27 Jul '01

> make_filter: : can't parse output: 'Make.rules.in is newer > than Make.rules, please rerun ./configure!' Fixed in my tree. > Would it be possible to have the messages pass through as-is when > they are not recognized (with the current directory for context)? [snip] > make_filter: gcc: can't parse output: 'd3ddevice/mesa.c:817: > warning: unused variable `xvis'' I have fixed that for gcc messages (unless --pedantic is specified), however I'm not sure it is good always doing that. I will think about it. > It looks like there's an incompatibility with colorgcc. [snip] > So it must be the controls characters added by colorgcc > that confuse > make_filter. No it wasn't, colorgcc checks whether STDOUT is a TTY or not.

1 0

RE: Even more misc fixes
by Patrik Stridvall 27 Jul '01

27 Jul '01

> > But OK I will try and compile with -DSTRICT and see what happends. > > IIRC somebody tried that but it didn't turn out so well. > > That would be me, probably. I started the conversion to -DSTRICT but > then other priorities came up and now it's on the back burner. I will > get back to it eventually but at the current rate it's hard > to know when > that will be :-( > Compiling with -DSTRICT is not that bad: with a relatively simple > patch it compiles (see attachement). Or at least, it used to. No patch is needed for the file in question. windows/property.c needs a simple patch though. > But there > are tons of warnings, which means tons of places that need > attention and > possibly fixing. That's where the work is. Yes. I've noticed that and I have fixed a few of them as well. However I'm not optimistic on fixing them all on the short term. The problem is not the number of them, the problem is that some of the warnings like the Global* can't be fixing in the .c files. It involves changing the .h files and that generated even more warnings. :-( I will investigate furher, but as I said, I'm not optimistic.

1 0

Re:Re: native dll's
by José Soriano Díaz 27 Jul '01

27 Jul '01

>From: Francois Gouget <fgouget(a)free.fr> >To: José Soriano Díaz <jose__sor(a)hotmail.com> >CC: wine-devel(a)winehq.com >Subject: Re: native dll's >Date: Thu, 26 Jul 2001 10:10:17 -0700 (PDT) > >On Wed, 25 Jul 2001, José Soriano Díaz wrote: > > > > > Hi there, I'm working in a telerobotics project and I need to >link a > > windows dll in order to use a Cybernet Joystick. > > First I tried to use the winAPI functions LoadLibrary, > > FreeLibrary and GetProccessAddress as I were working on Windows, and > > I recompiled my program with winelib: > > *. winemaker /my_path/ > > *. ./configure > > *. make all > > but it didn't create any executable, what I obtained was a > > lib*.so, because winemaker thought I was trying to compile a dll, > > not to use one. > > To force winemaker to generate an executable simply use it as >follows: > * type "winemaker --cuiexe /my_path" to indicate a console executable > * type "winemaker --guiexe /my_path" to indicate a graphical executable > > You can also use "winemaker -?" to get a list of options supported by >winemaker. > > > > So my question is quite siple How can I link a native dll in > > a Unix project? > > I think you have used the right approach: LoadLibrary / >GetProccessAddress / FreeLibrary. If that works for you then it's the >simplest approach. I'm afraid it doesn't work, when I executed what I compiled , I obtained "Undefined Symbol" in any call to the native dll. Thanks anyway for the advice. _________________________________________________________________ Descargue GRATUITAMENTE MSN Explorer en http://explorer.msn.es/intl.asp

2 1

[Fwd: Re: Any use for glyph bounding boxes in printer driver?]
by Ian Pilcher 27 Jul '01

27 Jul '01

Travis Michielsen wrote: > > What about GetCharABCWidth* what does this function use? (or could it use > this?) I see the function still shows a fixme (or atleast the last time I > checked). > The only one that works for printer fonts is GetCharABCWidthsFloat. I just tested it on Windows 2000 and verified that it always returns 0 for abcfA and abcfC (and returns the advance width in abcfB) when it is called on a printer font. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

Re: ChangeDisplaySettings
by Travis Michielsen 27 Jul '01

27 Jul '01

--- Lionel Ulmer <lionel.ulmer(a)free.fr> wrote: > > This patch partially implements the ChangeDisplaySettings* functions. > > Well, I am 100 % sure that Alexandre will reject it :-) :-\ > If you want to do something like that, you need to implement the feature in > the X11 driver and then call it via the 'USER_Driver.pFunctionName' > protocol. Hmm, I was going to try something like that, however, I had problems with that method simply b/c of the load order between the dlls. ChangeDisplaySettings is implemented in user32.dll which loads BEFORE x11drv. This makes it impossible to initalize the function with the user32.dll. However, with DDraw, the x11drv.dll is loaded before the ddraw.dll! The only way I saw to exchange info was to initialize the function with a call from x11drv.dll. If you can suggest an alternative that takes load order into account I will likely use it. > Moreover, there are already some DDraw-related mode change functions (in > dlls/x11drv/xvidmode.c). This should be factorized between both code. Already using so of that code, although it could probably be cleaned up a bit. I will get to that soon. - Travis Michielsen __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/

2 2

Re: How do I stop clipping?
by Travis Michielsen 27 Jul '01

27 Jul '01

--- Bill Medland <medbi01(a)accpac.com> wrote: > I don't like submitting incomplete code but I may have little choice unless > someone can point me in the correct direction here. As you may guess from > the following, my Windows experience is not that extensive but I think it's > enough to allow me to make sensible contributions. > > I am working on correcting the LISTVIEW_DrawLargeItem function, especially > when the item text is large. I have already got most of the way. However > the problem is this. > > When a user selects a large icon the text should be written completely (by > calling DrawText with DT_NOCLIP). It is doing so; I can prove it by > resizing the window and I will see the full text being displayed for a > selected item. However when drawing it at the moment of selecting it, the > text is being clipped to the usual two and a bit rows. Presumably this > means that there is a clipping rectangle in the DC or the window that I > need to inflate. Or Do I simply invalidate that rectangle (from within the > WM_PAINT handler!!!). > > Any help would be appreciated. > > Bill Looking at the DrawText code I see that DrawText just passes the NOCLIP flag to ExtTextOut, so the problem I likely not with DrawText but with ExtTextOut instead. I can take a look at the code for both functions (time providing) and find out what is happening. - Travis Michielsen __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/

1 0

Any use for glyph bounding boxes in printer driver?
by Ian Pilcher 27 Jul '01

27 Jul '01

Currently, the Wine PostScript driver stores the bounding box (xMin, yMin, xMax, yMax) for every glyph in every font. This information is not currently used, and I'd like to get rid of it. (Note: this is distinct from the advance width of each glyph, which is certainly required.) >From what I can tell, there is no API that a Win32 application or the Windows GDI can use to get this information from a printer driver. Since I'm not that familiar with either, however, I figure I should try to confirm that this is indeed the case. So, does anyone know of any API that an application or the GDI can use to get the dimensions of an individual glyph from a "real" Windows printer driver? (I have verified that calling the GetTextExtentPoint functions with a one-character string returns the height of the font, not the height of the glyph. For example, it returns the same height for 'A' and '_'.) Thanks! -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

2 1

RE: winapi update
by Patrik Stridvall 27 Jul '01

27 Jul '01

> Btw, what does make filter do? > > Your post to wine-patches says it's nice an all but it does not say > what it does. Try and run it it is self describing. :-) Since Alexandre didn't apply the Makefile patch, running it is a little awkwark. Will fix that it later versions though. Try do: cd wine ./tools/winapi/make_filter make You can also give it parameters like ./tools/winapi/make_filter make clean Warning "make clean" doesn't look that good currently. PS. It filters the make messages and only display important messages. It might not always work 100% though, but I will fix problems as I find them. I wrote it many months ago and have run it from time to time since, so most issues have been fixed. The reason I wrote it was that I was irritated that important messages scrolled of screen. > If it's nice isn't it worth advertising to the Wine > developper community? I had intended to do that if but since I was unsure that Alexandre would apply my Makefile patch I decided to wait until it could present a better "user interface". But by all means test it.

2 1

RE: Even more misc fixes
by Patrik Stridvall 26 Jul '01

26 Jul '01

> [...] > > > Most of these are because of the transition to making > HANDLE a void* > > > and compiling with STRICT. > > > > Yes, I notice this was the case with TIMERPROC casts. > > However it is no so with the HOOKPROC casts, > > and yes it is the same with the real Windows headers. > > ??? > AFAICS there are two versions of HOOKPROC: one for -DSTRICT and a > FARPROC one. Hmm. I looked again and it seems you are right. Must have missed it somehow. Strange. > [...] > > But OK I will try and compile with -DSTRICT and see what happends. > > IIRC somebody tried that but it didn't turn out so well. > > That would be me, probably. I started the conversion to -DSTRICT but > then other priorities came up and now it's on the back burner. I will > get back to it eventually but at the current rate it's hard > to know when > that will be :-( > Compiling with -DSTRICT is not that bad: with a relatively simple > patch it compiles (see attachement). Or at least, it used to. > But there > are tons of warnings, which means tons of places that need > attention and > possibly fixing. That's where the work is. OK. Will look at it later.

1 0

RE: Even more misc fixes
by Patrik Stridvall 26 Jul '01

26 Jul '01

> The volatile stuff in dplay.h is part of the Windows header, you > cannot remove it. No it isn't. I'm not sure why it was added in the first place. It is neither used by Wine, nor defined by Windows. In fact only a few strange headers use volitile at all, and none of them is supported by Wine. > Most of these are because of the transition to making HANDLE a void* > and compiling with STRICT. Yes, I notice this was the case with TIMERPROC casts. However it is no so with the HOOKPROC casts, and yes it is the same with the real Windows headers. > Please don't add typecasts, consider the > warnings as an incentive to do the right fix... As you wish, but as I said HOOKPROC can't be fixed with STRICT. But OK I will try and compile with -DSTRICT and see what happends. IIRC somebody tried that but it didn't turn out so well. Oh well, lets see what happends.

2 1

RE: Even more misc fixes
by Patrik Stridvall 26 Jul '01

26 Jul '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > No it isn't. I'm not sure why it was added in the first place. > > It is neither used by Wine, nor defined by Windows. > > It is in the Windows headers I have. It is not in my Microsoft Visual C++ 6.0 header, but perhaps you have a newer version? DPlay using volatile seems a little strange, so I thought is was wrong especially since it was not in my version, but then I have seen stranger things. :-) > > As you wish, but as I said HOOKPROC can't be fixed with STRICT. > > Why not? Because it would be incompatible (warning wise) with Winelib applications compile with -DSTRICT since Windows doesn't provide a special -DSTRICT version of HOOKPROC. The application might pass a FARPROC to it and expect it to work. Well, of course it works but it would generate a warning.

1 0

Re: winapi update
by Alexandre Julliard 26 Jul '01

26 Jul '01

Patrik Stridvall <ps(a)leissner.se> writes: > The make_filter.diff patch is quite nice. > > Try it after applying it with by running: > make filter I'm not sure about the portability of the wildcard rule. Why don't you have make_filter call make instead of the other way around? This would avoid the need for changing the makefiles at all. -- Alexandre Julliard julliard(a)winehq.com

2 1

RE: winapi update
by Patrik Stridvall 26 Jul '01

26 Jul '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > The make_filter.diff patch is quite nice. > > > > Try it after applying it with by running: > > make filter > > I'm not sure about the portability of the wildcard rule. Why don't you > have make_filter call make instead of the other way around? This > would avoid the need for changing the makefiles at all. Well, make_filter actually calls make already. :-) Seriously, one reason that I added it to the Makefiles in the first place is that make_filter doesn't know what version of make to use. Sure it is called make on almost all systems and gmake (GNU Make) on most of rest, but since the user knows and calls "make", $(MAKE) contains the correct "make". Oh well, I guess just calling make will work on most platforms, it will on all platforms that I current use. The Wine Makefile is supposed to be portable so I guess it will have to do.

1 0

Re: Even more misc fixes
by Alexandre Julliard 26 Jul '01

26 Jul '01

Patrik Stridvall <ps(a)leissner.se> writes: > No it isn't. I'm not sure why it was added in the first place. > It is neither used by Wine, nor defined by Windows. It is in the Windows headers I have. > As you wish, but as I said HOOKPROC can't be fixed with STRICT. Why not? > But OK I will try and compile with -DSTRICT and see what happends. > IIRC somebody tried that but it didn't turn out so well. No it needs a lot of fixes, which is what the warnings are here to remind us of. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Even more misc fixes
by Alexandre Julliard 26 Jul '01

26 Jul '01

Patrik Stridvall <ps(a)leissner.se> writes: > * include/commctrl.h, > include/dplay.h: > Cleanup/removal of unnessary things that would have made > winapi_* parsing more complicated. The volatile stuff in dplay.h is part of the Windows header, you cannot remove it. > * dlls/comctl32/commctrl.c, > dlls/comctl32/tab.c, > dlls/dinput/dinput_main.c, > dlls/dsound/dsound_main.c, > dlls/ole32/clipboard.c, > dlls/ole32/ole2.c, > dlls/wineps/ps.c, > dlls/winmm/joystick.c, > dlls/winmm/wineoss/midi.c, > loader/dos/dosmod.c, > windows/caret.c: > Fixed some warnings. Most of these are because of the transition to making HANDLE a void* and compiling with STRICT. Please don't add typecasts, consider the warnings as an incentive to do the right fix... -- Alexandre Julliard julliard(a)winehq.com

1 0

How do I stop clipping?
by Bill Medland 26 Jul '01

26 Jul '01

I don't like submitting incomplete code but I may have little choice unless someone can point me in the correct direction here. As you may guess from the following, my Windows experience is not that extensive but I think it's enough to allow me to make sensible contributions. I am working on correcting the LISTVIEW_DrawLargeItem function, especially when the item text is large. I have already got most of the way. However the problem is this. When a user selects a large icon the text should be written completely (by calling DrawText with DT_NOCLIP). It is doing so; I can prove it by resizing the window and I will see the full text being displayed for a selected item. However when drawing it at the moment of selecting it, the text is being clipped to the usual two and a bit rows. Presumably this means that there is a clipping rectangle in the DC or the window that I need to inflate. Or Do I simply invalidate that rectangle (from within the WM_PAINT handler!!!). Any help would be appreciated. Bill

1 0

Re: Handling X errors using exception handlers
by Alexandre Julliard 26 Jul '01

26 Jul '01

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > Do you plan to implement it or should I do it (be warned though that I can > work on it only if the weather is bad this week-end :-) ). I'll do it. I had a version working some time ago, I just need to adapt it to the new per-thread displays. -- Alexandre Julliard julliard(a)winehq.com

1 0

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 July 2001