August 2005 - Wine-Devel - list.winehq.org

Re: [commdlg] Create interface for path related operations

by Troy Rollo

On Saturday 13 August 2005 12:30, Robert Shearman wrote: > >ChangeLog: > > Create an interface for path related operations used by the file dialogs > > to reduce their dependency on Win32 format paths. > > Why do you want to do that? It will significantly reduce the potential for future conflicts between WineHQ and the branch containing the Unix path APIs. I discussed it with Alexandre on IRC and he indicated that such an approach was acceptable.

Aug. 13, 2005

Re: Help with debugging needed

by Lionel Ulmer

> This looks like a really nasty heap corruption to me, and I'm afraid it's > beyond my knowledge. Can anyone of the ddraw/d3d people help me? I think best would a +ddraw,+heap,+relay,+tid,+seh trace to be able to see where the corruption may occur. And it's not because it crashes into DDraw code that it's DDraw responsible for it :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

Aug. 13, 2005

Re: RichEdit flicker

by Phil Krylov

On Sat, 13 Aug 2005 12:47:19 +0400 Phil Krylov <phil(a)newstar.rinet.ru> wrote: > The paragraph structure should include not MEPF_REWRAP and MEPF_REPAINT > flags, but indexes of rows from which to start re-wrapping and repainting > (e.g. nStartRewrap and nStartRepaint). The wrapping routine should check if > it has actually changed wrapping and set nStartRepaint accordingly. > > ME_Repaint should not call ME_PaintContent directly. Instead, the wrapping > routine (and probably others) should call InvalidateRect for screen areas > that need to be repainted. On other hand, the current code is pretty stable although flickering. Probably flickering could be more easily by drawing to an offscreen bitmap which would be just exposed by WM_PAINT. -- Ph.

Aug. 13, 2005

Re: SHGetPathFromIDList problem

by Michael Jung

Hi Ge, On Friday 12 August 2005 17:19, Ge van Geldorp wrote: > Since this patch: > http://www.winehq.org/hypermail/wine-cvs/2005/06/0338.html > SHGetPathFromIDList() seems broken. The problem is that files stored in the > Desktop directory don't get the path to the Desktop directory prepended. > I've tried to fix it in the attached patch and added a testcase, but the > shell COM interfaces easily confuse me, so perhaps someone with a better > understanding of this stuff should look it over before I submit it to > wine-patches. I think the prepending of the Desktop path should happen in the Desktop Shellfolder, if it's GetDisplayNameOf method is called with the SHGDN_FORPARSING flag is set (instead of in SHGetPathFromIDList). I've modified your patch accordingly and added a testcase. Please submit to wine-patches, if you agree. Thanks for cleaning up all those resource leaks after me. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

Aug. 13, 2005

Re: World of Warcraft

by Jacob Emcken

Hi, cyrix12(a)cox.net wrote: > It's me again. The latest WoW patch (1.5.1) broke stuff again, and now I'm unable to click on anything outside of menu items in game. The issue seems to be related to camera angle, as I am able to click on items/people when I have my camera positioned just right. It's basically unplayable at the moment though. > > Anyway, I'd appreciate it if one of the OpenGL/D3D guys (it's most likely something that would be easily fixed by one of you) could take a look at it if they have some free time. For me the bug has disappeared after upgrading to Ubuntu Breezy with a 2.6.12 kernel and the lastest release of WINE. I stumbled upon a post on a Gentoo forum where a few people said that they didn't need the ugly cadega workaround to play WoW after using kernel 2.6.12. So after I got Ubuntu upgraded from Hoary to Breezy (which uses a 2.6.12 kernel instead of a 2.6.10) I tested WoW with a clean WINE 20050725 (Debian packages from wine.df.net/apt) The bug hasn't shown itself since. I belive it is the kernel upgrade. I dunno, I might have just been lucky. Just wanted to let you know, dunno if I have just been lucky. Regards --Jacob

Aug. 13, 2005

RichEdit flicker

by Phil Krylov

Hi Krzysztof, I want to change wrapping and painting code to minimize flickering and maximize performance. >From what I see, the following could be done: The paragraph structure should include not MEPF_REWRAP and MEPF_REPAINT flags, but indexes of rows from which to start re-wrapping and repainting (e.g. nStartRewrap and nStartRepaint). The wrapping routine should check if it has actually changed wrapping and set nStartRepaint accordingly. ME_Repaint should not call ME_PaintContent directly. Instead, the wrapping routine (and probably others) should call InvalidateRect for screen areas that need to be repainted. What do you as the author of that code think about my suggestions? Or it's possible that you are working in the same direction, and then it would be silly to implement one thing twice? -- Ph.

Aug. 13, 2005

Re: DINPUT: Generic FF effect implementation (FF #4)

by Daniel Remenak

Submitted #5 a couple days ago, along with a short explanation of how it all worked together. Any comments? If you'd like me to change the architecture I'm willing to do so, if you can give me some hints about what direction to go with it. If you want some other changes made, please drop some clues about what they might be. If you want to see more, I have more that can be cleaned up for submission. If you need more clarification on some issue I can give it. I just loathe sitting around wondering if these are good enough or not when I could be working more on them if they need revision or the next batch if they don't ;) --Daniel Remenak On 8/10/05, Alexandre Julliard <julliard(a)winehq.org> wrote: > Daniel Remenak <dtremenak(a)gmail.com> writes: > > > Could I get some feedback on why this has not been applied? I've got > > several additional patches prepared already that depend on it and if > > something needs to be changed I'd like to know before I get even more > > that do. It still applies cleanly to CVS. If it's just not being > > applied because it's considered dead code I can submit the other > > patches that actually use it. > > That would be good. The pseudo vtbl functions that are not used in a > vtbl don't look right to me, but I'm not sure what you are planning to > do with that. > > -- > Alexandre Julliard > julliard(a)winehq.org >

Aug. 13, 2005

Help please

by Fabio Duarte Vilas Boas

i got a problem with the "wine". when i minimize this program it goes to the corner __________________________________________________ Converse com seus amigos em tempo real com o Yahoo! Messenger http://br.download.yahoo.com/messenger/

Aug. 13, 2005

Unsubscribe me from mailing list.

by Setul Patel

Please unsubscribe my email id: setulkumarpatel(a)gmail.com from yours mailing list. Thanking you. Setul Patel

Aug. 13, 2005

Re: [commdlg] Create interface for path related operations

by Robert Shearman

Troy Rollo wrote: >This patch creates an interface for path name related operations (including >things such as finding the file name part, extension, identifying the path >separator character, qualifying file names, changing directories, verifying >file existence) used by the file open dialogs that depend on the path being a >Win32 path name, thus making the file dialog code less dependent on the >structure of path names. > >ChangeLog: > Create an interface for path related operations used by the file dialogs > to reduce their dependency on Win32 format paths. > > Why do you want to do that? -- Rob Shearman

Aug. 13, 2005