October 2007 - Wine-devel - list.winehq.org

Re: [1/3] comctl32: Do not call parent of tool window for tip text
by Ann & Jason Edmeades 29 Oct '07

29 Oct '07

> Sending message to parent in tooltip code > probably simply works around toolbar's broken behavior. In this case I think > I've identified a line in toolbar.c that fails to properly detect empty string > causing not appearing tooltips in Radmin. I'll try to submit another patch with > this fix shortly. Thanks for checking this out - If your new patch makes tooltips work, I should probably be quiet... But.. I was looking through my notes of when I was working on this bug, looking at SPY++ logs from windows and comparing them with +spy,+message,+msg etc logs from wine. My notes indicated I was seeing the following sequence (I have hwnds or whatever spy logs written down): Tooltip sends toolbar needtextW Sends to base class tbn_GetInfoTipA which didn't return anything Sends tbn_GetInfoTipA to its parent which didn't return anything Tooltip sends baseclass ttn NeedTextA Which forwards to parent as ttn NeedTextA My notes and investigations could be wrong, does this tie up with what you were seing? Jason

2 1

Misplaced Property Sheet buttons
by Peter Åstrand 29 Oct '07

29 Oct '07

I'm debugging a problem where the standard buttons on a property sheet are misplaced. The application is Magna Cura. The screenshot http://www.cendio.com/~astrand/wine/62-tab-size/unpatched.png demonstrates the problem: The buttons are only partially visible. It turns out that the parent window for the Buttons changes size several times. The height is: 228 95 466 436 450 The PROPSHEET_AdjustButtons function, however, is only called in WM_INITDIALOG, so the buttons are positioned based on the height 466, and never repositioned. What's the proper fix for this? I've tried this patch: --- propsheet.c (revision 13243) +++ propsheet.c (arbetskopia) @@ -3828,6 +3828,13 @@ return TRUE; } + case WM_WINDOWPOSCHANGED: + { + PropSheetInfo* psInfo = (PropSheetInfo*) lParam; + PROPSHEET_AdjustButtons(hwnd, psInfo); + return FALSE; + } + default: return FALSE; } This solves the position problem, but instead the Help button disappears. See screenshot http://www.cendio.com/~astrand/wine/62-tab-size/patched.png. Any ideas? Best regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Linköping Phone: +46-13-21 46 00 ThinLinc User Group 2007 Höstkonferens --- 15-16 november, Linköping. Program och anmälan: http://www.thinlincusergroup.se/aktiviteter

2 2

Re: [1/3] comctl32: Do not call parent of tool window for tip text
by Ann & Jason Edmeades 29 Oct '07

29 Oct '07

Hi Alexander, > In the process of debugging I > also determined that Windows doesn't seem to send this message to > parent at all (tested on win98-Qemu, winXP SP2-Qemu and winXP SP1 > normal installation). So I'm deleting this second call altogether and > a conformance test for this situation will be included in the next > patch. > Under some circumstances, it must - see bug 9233 (and my patch at url below) http://www.winehq.org/pipermail/wine-patches/2007-August/042660.html http://www.winehq.org/pipermail/wine-cvs/2007-August/035236.html I debugged this through to the point where the parent was definitely retrieving the information (I watched spy logs of the application in question) and I believe reversing this patch will break radmin again... It's a free download, can you please test you havent regressed that application with the patch Jason

2 1

re: RICHED20: fix test crash on WinXP-SP2
by Dan Kegel 29 Oct '07

29 Oct '07

Alex Lasso wrote: > First of several patches to make riched20 tests actually pass on Windows. Without your patch, "make test" crashes for me on Wine. Your patch fixes the crash. So this isn't just a problem on Windows, thanks for fixing it! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Re: tools/widl/typegen.c pointer initialization
by Dan Hipschman 29 Oct '07

29 Oct '07

On Sun, Oct 28, 2007 at 01:51:34PM +0100, Gerald Pfeifer wrote: > In tools/widl/typegen.c we have the following snippet > > static void write_user_tfs(FILE *file, type_t *type, unsigned int *tafsoff) > { > unsigned int start, absoff, flags; > unsigned int align = 0, ualign = 0; > const char *name; > type_t *utype = get_user_type(type, &name); > > which passes name to get_user_type without initializing it. get_user_type > in return has the following piece of code: > > static type_t *get_user_type(const type_t *t, const char **pname) > { > for (;;) > { > type_t *ut = get_attrp(t->attrs, ATTR_WIREMARSHAL); > if (ut) > { > if (pname) > *pname = t->name; > return ut; > } > > It is unclear to this reader (and various versions of GCC I tested), > whether we don't really use *name (*pname) uninitialized here. Now > it is possible that through some of the, hmm, tricky logic in these > two functions combined with some environmental guarantees it happens > that we don't, but it seems better to be proactive here. The logic is as follows: We wouldn't be in write_user_tfs if the predicate is_user_type wasn't true for that type, which means *pname (name) will always be initialized since it gets set precisely when get_user_type returns non-NULL (which is the is_user_type test). I don't think initializing it to NULL is helpful since it would crash just the same as if it weren't initialized. name *must* have a valid (non-NULL) value. This may silence a warning, but it's making the logic of the code more confusing by setting the variable to a value that doesn't make any sense in that context. get_user_type is the initialization. Better than this would be to put "assert(is_user_type(type));" above the initializations to convince the programmer at least that name will get initialized correctly in get_user_type. If that doesn't convince the compiler then I don't think it's worth it to try to placate it since we're supposed to be wrting code for humans, not computers. Some projects use a macro like "name IF_LINT(= NULL);" to quiet warnings while informing the reader that the initialization is not necessary. I suppose that's slightly better as well. I think the real problem is that the code is just not clear enough. I've been meaning to add asserts. Where asserts are impractical: comments.

2 2

Re: [PATCH] Currently the serial code interprets
by Juan Lang 29 Oct '07

29 Oct '07

Hi Tom, > Content-Type: text/x-patch; name=0001-XONXOFF-reversion.patch > Content-Transfer-Encoding: base64 Apparently gmail's encoding .patch files as base64. It should be text/plain. Please try renaming it to, e.g., 0001-XONXOFF-reversion.diff and try again. --Juan

1 0

Pegasus Mail: program closes when sub-program closes
by Joel Barnett 28 Oct '07

28 Oct '07

Sent to bugzilla, and to this email addy, as per winehq instructions: http://www.pmail.com/downloads_maine_t.htm Version to look at is 4.41, a free download. This email app does a normal shutdown whenever the editor is closed, e.g., after a new email is sent. This is not normal behaviour. In Windows the app stays open, so that one can continue sending, receiving, reading, writing email, etc. In old versions of wine, this error doesn't happen, (ver. 20050830). The regression error occurs as early as 0.9.20. Based on posts to the wine appdb for this app, it is likely that the regression error ocurred >=0.9.14. The editor in Pmail was not written by the developer and maintainer, David Harris, but rather licensed by him. Recent wine code seems to interpret an ordinary call to close the editor as a call to close the program itself. When Pmail starts, a 0 byte file, mailbox.lck is created in the mail box of the user. When the user closes the program normally, this file is deleted. Since the shutdown regression error deletes the lock file, I conclude the call to close the editor is being misinterpreted by wine as a call to shutdown Pmail. Joel Barnett New super maintainer for Pegasus Mail p.s. - I'm new at this, please forgive me if my report is funky. I did check bugzilla and didn't find anything relevant.

1 0

Re: ddraw: allow explicit backbuffer
by Stefan Dösinger 28 Oct '07

28 Oct '07

Am Sonntag, 28. Oktober 2007 01:18:53 schrieb EA Durbin: > based on patch by Jaroslav Reznik, this fixes bug 9008 and allows the game > combat pillows to launch There is a test in the ddraw tests that shows that this is not allowed. This test will break I guess. However, maybe it is a version differece. The test tests IDirectDraw7 I think, maybe the game uses an older version.

2 1

Re: ddraw: allow explicit backbuffer
by Marcus Meissner 28 Oct '07

28 Oct '07

On Sat, Oct 27, 2007 at 06:18:53PM -0500, EA Durbin wrote: > > based on patch by Jaroslav Reznik, this fixes bug 9008 and allows the game combat pillows to launch > > _________________________________________________________________ > Climb to the top of the charts! Play Star Shuffle: the word scramble challenge with star power. > http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct > From d6c94c504f555f773c2c90d7fcbd4bf3500fe490 Mon Sep 17 00:00:00 2001 > From: EA Durbin <ead1234(a)hotmail.com> > Date: Sat, 27 Oct 2007 18:16:27 -0500 > Subject: ddraw: allow explicit backbuffer, based on a patch by Jaroslav Reznik > > --- > dlls/ddraw/ddraw.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/ddraw/ddraw.c b/dlls/ddraw/ddraw.c > index 7785624..a84fc36 100644 > --- a/dlls/ddraw/ddraw.c > +++ b/dlls/ddraw/ddraw.c > @@ -2283,7 +2283,7 @@ IDirectDrawImpl_CreateSurface(IDirectDraw7 *iface, > return DDERR_NOEXCLUSIVEMODE; > } > > - if(DDSD->ddsCaps.dwCaps & (DDSCAPS_FRONTBUFFER | DDSCAPS_BACKBUFFER)) { > + if(DDSD->ddsCaps.dwCaps & (DDSCAPS_FRONTBUFFER || DDSCAPS_BACKBUFFER)) { This is wrong. You changed a logical OR into a boolean OR and the bitmask will no longer work... Something else needs to be changed, like removing either the DDSCAPS_BACKBUFFER part or the FRONTBUFFER part of the |. Ciao, Marcus

1 0

Re: implement FatalExitHook()
by Maarten Lankhorst 28 Oct '07

28 Oct '07

Hi EA, I can find absolutely no info on FatalExitHook, are you sure it's supposed to exit the process, rather then making the argument be called in case of exit? Cheers, Maarten.

2 2