July 2009 - Wine-Devel - list.winehq.org

Re: msctf: fully clear the Variant before setting it.

by Huw Davies

On Wed, Jul 01, 2009 at 10:29:22AM -0500, Aric Stewart wrote: > diff --git a/dlls/msctf/compartmentmgr.c b/dlls/msctf/compartmentmgr.c > index 3afcfda..e1c7187 100644 > --- a/dlls/msctf/compartmentmgr.c > +++ b/dlls/msctf/compartmentmgr.c > @@ -537,6 +537,7 @@ static HRESULT WINAPI Compartment_GetValue(ITfCompartment *iface, > if (!pvarValue) > return E_INVALIDARG; > > + memset(pvarValue,0,sizeof(VARIANT)); > pvarValue->n1.n2.vt = VT_EMPTY; > if (!This->variant.n1.n2.vt == VT_EMPTY) > hr = VariantCopy(pvarValue,&This->variant); > This looks wrong; there's something strange going on here. Note also there's VariantInit() which is a cleaner way to set vt to VT_EMPTY. Huw.

July 1, 2009

Re: regedit: Open last key at startup

by André Hentschel

Alexandre Julliard schrieb: > Vladimir Pankratov <scriptkid(a)mail.ru> writes: > >> Hi all. >> >> Open last key at startup. > > Don't resend the same patch every single day, that will only get you > ignored. Instead, spend some more time looking at your patch and I'm > sure you can figure out why it's not going to work. > Hi Vladimir, You may use constants instead of Numbers. In this case KEY_MAX_LEN instead of 260, as i made it in my Q&D-Version on Bug 18239. There (Bug 18239) you may add yourself to CC-List.

July 1, 2009

Re: Ensure that GetSystemMenu returns valid HMENU unless bRevert specified

by Alexandre Julliard

Brent Roman <brent(a)mbari.org> writes: > Originally submitted on 6/14/09. > Resubmitted after comments on this bug: > > http://bugs.winehq.org/show_bug.cgi?id=19134 > > The attached patch against the master branch (as of today) fixes what > appears to be a long standing bug in Wine's > GetSystemMenu function in User32.dll.so. You reformatted the whole function, don't do that. Also please add a test case. -- Alexandre Julliard julliard(a)winehq.org

July 1, 2009

Re: winex11.drv: Move clipboard handling to a separate thread

by Alexandre Julliard

Yuri Khan <yurivkhan(a)gmail.com> writes: > This patch achieves this by creating an auxiliary thread that will run > in the same process that puts data on the clipboard and handle X > selection messages. That looks quite inefficient, especially since you create a new thread every time. You should limit this to the cases where it's really necessary, using clipboard from command line apps is a very uncommon operation. -- Alexandre Julliard julliard(a)winehq.org

July 1, 2009

regression: loader: Reserve some more memory to cover the native ole32 addresses.

by Markus Amsler

commit 8d833ee2e7a1d8b82e2dccf51e0cbc20742a0833 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Thu Jun 25 14:19:09 2009 +0200 loader: Reserve some more memory to cover the native ole32 addresses. After this commit WoW with mesa/r500 falls back to indirect rendering. libGL tries to mmap 256M for the framebuffer but that fails with > libGL error: drmMap of framebuffer failed (Cannot allocate memory) Markus

July 1, 2009

Re: Standard dialogs size & translation

by Alexander Nicolaysen Sørnes

Onsdag 01 juli 2009 14:23:47 skrev Frédéric Delanoy: > Hi, > > I'm currently updating/fixing the (French translation of the) commdlg32 > dialogs. There is a warning in cdlg_XX.rc saying "WARNING: DO NOT CHANGE > THE SIZE OF THE STANDARD DIALOG TEMPLATES" > > However, e.g. in the standard "File Open" dialog, the standard size of > some labels (e.g. "File name") is too small for a correct translation, > and only the start of the message is shown (which is obviously wrong). > > I could manage to get correct translated version by modifying > "internal" sizes (while keeping the total size of the dialog the > same). > > Does the warning only apply to all localized versions, or just for the > English one? What are the potential problems if a dialog is slightly > adapted to fit a particular language? > > Frédéric Changing the internal sizes should be ok; at least that's what Microsoft has done with some of the Norwegian dialogue boxes. Alexander N. Sørnes

July 1, 2009

Re: [2/2] mlang: Add a test for IMultiLanguage2_IsCodePageInstallable.

by Alexandre Julliard

Hans Leidekker <hans(a)codeweavers.com> writes: > Some more testing suggests that the installable set is a superset of > the valid codepages set. So we could just return the set of valid > codepages for now and not hardcode anything. Yes, it should probably use something like IMultiLanguage2_ValidateCodePageEx (and the test should probably use that too). This way we can also return the non kernel32-supported codepages. -- Alexandre Julliard julliard(a)winehq.org

July 1, 2009

Standard dialogs size & translation

by Frédéric Delanoy

Hi, I'm currently updating/fixing the (French translation of the) commdlg32 dialogs. There is a warning in cdlg_XX.rc saying "WARNING: DO NOT CHANGE THE SIZE OF THE STANDARD DIALOG TEMPLATES" However, e.g. in the standard "File Open" dialog, the standard size of some labels (e.g. "File name") is too small for a correct translation, and only the start of the message is shown (which is obviously wrong). I could manage to get correct translated version by modifying "internal" sizes (while keeping the total size of the dialog the same). Does the warning only apply to all localized versions, or just for the English one? What are the potential problems if a dialog is slightly adapted to fit a particular language? Frédéric

July 1, 2009

Re: [2/2] mlang: Add a test for IMultiLanguage2_IsCodePageInstallable.

by Hans Leidekker

On Wednesday 01 July 2009 01:09:52 pm Alexandre Julliard wrote: > >> IsValidCodePage might be helpful yes, although marking it broken is > >> a bit too strong I think, it's just a difference in codepage databases. > >> > >> -Hans > > Yes, broken() seems strong but it's actually meant as > > behaviour_we_dont_want_to_replicate() in this case. > > I'm not convinced we don't want to replicate it. Using something like > IsValidCodePage in the implementation would be better than hardcoding > the list. Some more testing suggests that the installable set is a superset of the valid codepages set. So we could just return the set of valid codepages for now and not hardcode anything. -Hans

July 1, 2009

Re: [2/2] mlang: Add a test for IMultiLanguage2_IsCodePageInstallable.

by Paul Vriens

Alexandre Julliard wrote: > Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > >> Hans Leidekker wrote: >>> On Wednesday 01 July 2009 12:12:47 pm Paul Vriens wrote: >>> >>>>> Would using IsValidCodePage() be helpful here? >>>>> >>>> Yep, something like: >>>> >>>> hr = IMultiLanguage2_IsCodePageInstallable(ml2, i); >>>> if (i == 29001 || /* win2k3 */ >>>> i == 50930 || i == 50931 || i == 50933 || i == 50935 >>>> || i == 50937 || i == 50939 /* vista */) >>>> { >>>> ok(hr == S_FALSE || hr == S_OK || >>>> broken(!IsValidCodePage(i)), "%u: expected S_FALSE or S_OK, got >>>> 0x%08x\n", i, hr); >>> IsValidCodePage might be helpful yes, although marking it broken is >>> a bit too strong I think, it's just a difference in codepage databases. >>> >>> -Hans >> Yes, broken() seems strong but it's actually meant as >> behaviour_we_dont_want_to_replicate() in this case. > > I'm not convinced we don't want to replicate it. Using something like > IsValidCodePage in the implementation would be better than hardcoding > the list. > I was actually pointing only to the failures in the test. These failures (varying number of failures per platform) happen on XP and below. Unfortunately there isn't a 1 to 1 mapping between !IsValidCodePage() and E_INVALIDARG. (The exceptions are mentioned already in the test). The ideal tests would then probably be something like: ret = IsValidCodePage(i); hr = IMultiLanguage2_IsCodePageInstallable(ml2, i); ok((ret && (hr == S_OK)) || (!ret && (hr == E_INVALIDARG)), "Something wrong") There are however numerous errors when running this on all platforms. -- Cheers, Paul.

July 1, 2009