February 2012 - Wine-devel - list.winehq.org

winmm: TRACE unhandled messages
by Joerg-Cyril.Hoehle＠t-systems.com 08 Feb '12

08 Feb '12

Andrew, it's good that you log these now. I had a question in mind since your winmm rewrite: Your rewrite no more maps WOD_XYZ* messages to waveOut functions. I believe that it is possible that an old app entirely uses the generic SendDriverMessage function (esp. in the mciavi/msvfw area, cf. ICSendMessage) instead of the specific wave/midi* ones. Can you be sure that this is not supported by native, esp. w9x? If Wine does not map these, all we'll get to "hear" in AppDB is that attentive people miss sound or music that they remember listening to 10 years ago on native. Regards, Jörg Höhle

2 1

Re: [1/2] user32: Add a bunch of RealChildWindowFromPoint tests.
by Alexandre Julliard 07 Feb '12

07 Feb '12

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > win.c:6753: Test failed: FlashWindowEx succeeded > win.c:6764: Test failed: FlashWindowEx failed with -559038737 > > are intermittent, and have nothing to do with these tests. Maybe not directly, but the failures are clearly caused by your change, and they look pretty bad on the test results. Please fix that. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: po: Remove untranslated English strings from the Romanian translation
by Michael Stefaniuc 07 Feb '12

07 Feb '12

Hello Frédéric, the patch is wrong. Frédéric Delanoy wrote: > --- > po/ro.po | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/po/ro.po b/po/ro.po > index a0912c2..c9375c4 100644 > --- a/po/ro.po > +++ b/po/ro.po > @@ -11803,11 +11803,11 @@ msgstr "Bază" > > #: regedit.rc:282 > msgid "Hexadecimal" > -msgstr "Hexadecimal" > +msgstr "" > > #: regedit.rc:283 > msgid "Decimal" > -msgstr "Decimal" > +msgstr "" Those aren't untranslated but the Romanian words match the English ones. > #: regedit.rc:290 > msgid "Edit Binary" > @@ -13243,7 +13243,7 @@ msgstr "Afișează opțiunile a&vansate" > > #: winecfg.rc:240 > msgid "De&vice:" > -msgstr "De&vice:" > +msgstr "" > > #: winecfg.rc:242 > msgid "Bro&wse..." bye michael

3 3

Re: po: Fix some trailing ellipses errors in Catalan translation
by Alex Henrie 07 Feb '12

07 Feb '12

#: ieframe.rc:68 winhlp32.rc:66 msgid "Print..." -msgstr "Imprimeix" +msgstr "Imprimeix..." I intentionally left the ellipse off of the word "Imprimeix" in Internet Explorer so that the text would fit on the toolbar button. Any suggestions? -Alex

3 2

Re: po: Update finnish locales
by Lauri Kenttä 07 Feb '12

07 Feb '12

On 2012-02-06 23:00, Olli-Pekka Wallin wrote: > +msgstr "KB/s" > ... > +msgstr "Yksi sivua" > ... > +msgstr "Wordpad ojelman kÃƒÂ¤ynnistys epÃƒÂ¤onnistui" I'm sorry to say this, but these translations are really bad. I suggest you either have someone check your translations thoroughly before submitting or leave the whole job for others. (I'm already working on it.) The patch is also based on an old revision and changes a msgid. -- Lauri Kenttä

1 0

SourceForge forbids download
by Aidin Gharibnavaz 07 Feb '12

07 Feb '12

Dear Wine developers, SourceForge blocked download for some countries by default, such as Iran. (More detail can be found here<https://sourceforge.net/blog/some-good-news-SourceForge-removes-blanket-blo…> ) So, if it's not illegal to you to let Iranians download your software, please go to the SourceForge's ProjectAdmin, and set the ExportControl option, to let us enjoy the great work of yours. Thanks.

3 2

Re: po: Update finnish locales
by Francois Gouget 07 Feb '12

07 Feb '12

On Mon, 6 Feb 2012, Olli-Pekka Wallin wrote: > po: Update finnish locales > > #: appwiz.rc:49 > msgid "Installing..." > -msgstr "" > +msgstr "Asennetaan.." It looks like there's a missing dot here. But thanks a lot for the patch. Feel free to tackle any other issue in: http://fgouget.free.fr/wine-po/fi-errors.html Also don't hesitate to let me know about false positives so I can silence them. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

1 0

Re: ID3DXBaseEffect::SetValue
by luis.busquets＠ilidium.com 07 Feb '12

07 Feb '12

For the textures point, it is judt that the implemenyation is just the change of one pointer ----- Reply message ----- De: "Rico Schüller" <kgbricola(a)web.de> Para: "Luis Carlos Busquets Pérez" <luis.busquets(a)ilidium.com> CC: <wine-devel(a)winehq.org> Asunto: ID3DXBaseEffect::SetValue Fecha: mar., feb. 7, 2012 10:03 Am 07.02.2012 06:02, schrieb Luis Carlos Busquets Pérez: > 1. If the functions returns E_FAIL for a sample then > test_effect.c:1917: Test failed: Got result 80004005, expected 0 (D3D_OK) I'll have a look at those. > 2. For D3DXPT_VERTEXSHADER and D3DXPT_PIXELSHADER replying with E_FAIL > avoids > test_effect.c:1812: Test failed: Got result 0, expected 0x80004005 > (E_FAIL) > test_effect.c:1814: Test failed: Got result 0, expected 0x80004005 > (E_FAIL) > test_effect.c:1881: Test failed: Got result 0, expected 0x80004005 > (E_FAIL) Sure, that's not implemented, yet. You should get a FIXME for those cases. > 3. If the function just sets the memory with the data for a bool then > test_effect.c:969: Test failed: Got 46, expected 1 In this case it may be required, that the input has to be converted before it is put into data. A solution would be to use Set*Array to set the values. In general, I think it's also fine to convert the values in get_int() and get_float() in the case of D3DXPT_BOOL with get_bool(data) - I'll send a patch for this. But I also think a test to show, that the value is converted while it is set, is still the way to go. Well SetValue isn't complete, yet. > 5. Concerning textures, the compiler does not accept arrays of textures, > so any change to a texture type should be just a change of the pointer > to the texture at param->data (or NULL) I didn't got the point. Only that it is impossible to declare texture arrays in effect files, which I could confirm. Do you mean, that the HeapAlloc for the additional pointer for textures should be avoided? This could be done, it just needs separate handling for textures. As it is now, it mostly uses the same handling together with the shaders (e.g. IUnknown_Release(*(IUnknown **)param->data)). Cheers Rico

1 0

Re: ID3DXBaseEffect::SetValue
by luis.busquets＠ilidium.com 07 Feb '12

07 Feb '12

Concerning the vertrd a picel shadet, the truth is that sin e very soon in the history of d3dx the functions ID3DXEffect::SetPixelShader and ID3DXEffect::DetVertexShader wete removed. So actually it does not seem that you can change them. Because of that, the MS implementation replies with D3DERR_INVALIDCALL and their implementation in SetValue is straight. ----- Reply message ----- De: "Rico Schüller" <kgbricola(a)web.de> Para: "Luis Carlos Busquets Pérez" <luis.busquets(a)ilidium.com> CC: <wine-devel(a)winehq.org> Asunto: ID3DXBaseEffect::SetValue Fecha: mar., feb. 7, 2012 10:03 Am 07.02.2012 06:02, schrieb Luis Carlos Busquets Pérez: > 1. If the functions returns E_FAIL for a sample then > test_effect.c:1917: Test failed: Got result 80004005, expected 0 (D3D_OK) I'll have a look at those. > 2. For D3DXPT_VERTEXSHADER and D3DXPT_PIXELSHADER replying with E_FAIL > avoids > test_effect.c:1812: Test failed: Got result 0, expected 0x80004005 > (E_FAIL) > test_effect.c:1814: Test failed: Got result 0, expected 0x80004005 > (E_FAIL) > test_effect.c:1881: Test failed: Got result 0, expected 0x80004005 > (E_FAIL) Sure, that's not implemented, yet. You should get a FIXME for those cases. > 3. If the function just sets the memory with the data for a bool then > test_effect.c:969: Test failed: Got 46, expected 1 In this case it may be required, that the input has to be converted before it is put into data. A solution would be to use Set*Array to set the values. In general, I think it's also fine to convert the values in get_int() and get_float() in the case of D3DXPT_BOOL with get_bool(data) - I'll send a patch for this. But I also think a test to show, that the value is converted while it is set, is still the way to go. Well SetValue isn't complete, yet. > 5. Concerning textures, the compiler does not accept arrays of textures, > so any change to a texture type should be just a change of the pointer > to the texture at param->data (or NULL) I didn't got the point. Only that it is impossible to declare texture arrays in effect files, which I could confirm. Do you mean, that the HeapAlloc for the additional pointer for textures should be avoided? This could be done, it just needs separate handling for textures. As it is now, it mostly uses the same handling together with the shaders (e.g. IUnknown_Release(*(IUnknown **)param->data)). Cheers Rico

1 0

Re: comctl32: Remove an obsolete resource attribute.
by Marvin 07 Feb '12

07 Feb '12

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=16849 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

2 1