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

Re: OLEPICTURE: Initialize [orig|himetric][Width|Height] for PICTYPE_ICON case

by Alexandre Julliard

Alex Villacis Lasso <a_villacis(a)palosanto.com> writes: > You are right. I did a copy&paste from the SerializeIcon code. What do > you think about this patch? Better, but note that there is a twist with GetIconInfo, if the icon is monochrome the color bitmap is 0 and you then need to get the info from hbmMask and divide the height by 2 (you can always count on Microsoft to design clean and intuitive APIs...) You also need to delete the bitmaps when done. Note also that GetDC(0) is preferable to CreateCompatibleDC, it avoids creating a new DC just to delete it again. -- Alexandre Julliard julliard(a)winehq.org

March 29, 2005

Re: OLEPICTURE: Initialize [orig|himetric][Width|Height] for PICTYPE_ICON case

by Marcelo Duarte

Alex Villacis Lasso escreveu: > Alexandre Julliard wrote: > >> >> This seems a bit overkill just to retrieve the bitmap size. Couldn't >> you simply do a GetObject on the bitmap? >> >> >> > You are right. I did a copy&paste from the SerializeIcon code. What do > you think about this patch? > > Changelog: > * Initialize [orig|himetric][Width|Height] for PICTYPE_ICON case ... >+ if(GetObjectA(infoIcon.hbmColor, sizeof(bm), &bm) != sizeof(bm)) { > > Maybe GetObjectW is more consistent (get rid w->A calls)?

March 29, 2005

Re: Dragon Naturally Speaking - working.

by peter＠piments.com

Ok , that is the same setup as I have I thought you meant you were using winealsa.drv , thanks for the clarification. It's useful to note what you say about the capture level being relevant Thanks for the post. On Tue, 29 Mar 2005 13:38:13 +0200, Konstantin Goudkov <konstantin(a)goudkov.com> wrote: > Honestly, I don't remember the details. > I haven't touched ALSA in a long time, but I do have the same setup. > > In Wine config (WinMM part), I got > "Drivers" = "wineoss.drv" > So Wine uses OSS, but I use OSS emulation provided by ALSA. > > Try running: > > amixer set Mic cap > amixer set Capture cap 10 > > before running NS. > Maybe that will help. > > >> Great news. Could you give more details on your alsa setup? I have not >> managed to get alsa working with wine appart from putting oss in the >> wine >> config and using alsa-oss >> >> Regards, >> >> >> On Mon, 28 Mar 2005 13:50:08 +0200, Konstantin Goudkov >> <konstantin(a)goudkov.com> wrote: >> >>> I got NS7 working on Debian Sid, after running Sidenet >>> setup on Wine 20050310. >>> It took me a while to figure out that I need to raise the >>> Capture level, not just the Mic volume on ALSA. >>> Without it, it looked like NS (and Wine) didn't not pick up >>> the mic even though I could hear myself on the speakers. >>> >>> Also, sometimes not all buttons are clickable even through they should >>> be, so try "Ctrl-S" during the user setup. >>> >>> -- >>> Konstantin Goudkov >>> >>> >>> >>> >> >> >> >> -- >> Opera 7 mail on Linux >> >> > > -- Using Opera e-mail on Gentoo Linux

March 29, 2005

discusion about a message loop in listview.c

by Dietrich Teickner

Sorry, this helps Agent 2.0 only with a earlyer try, where I have directly checked the loop inside SendMessageTimeout. After moving this to LISTVIEW_SetItemState only FlashFXP 3.02 works. Agent 2.0 has also a meesageloop (veryfied in Odin), it is not the same as with LISTVIEW_SetItemState. Dietrich

March 29, 2005

Re: Resent^2 : Zero out return string in GetMenuStr

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Alexandre, > > also before, there was a NULL written to position Zero of the > string. However there where some checks and function calls that could > return Zero but didn't touch the string. Now there is only a check > that the argument is a pointer before the Null is written. What should be > done in another way? The existing code checks nMaxSiz before writing, you should do the same. -- Alexandre Julliard julliard(a)winehq.org

March 29, 2005

Re: OLEAUT32: fix detection of GIF palette index >= 128 for transparency

by Marcelo Duarte

Hi, Andreas Mohr escreveu: >Hi, > >On Tue, Mar 29, 2005 at 12:43:38PM -0500, Alex Villacis Lasso wrote: > > >>I traced this problem to a one-line bug in the GIF loading code. The >>code is supposed to initialize a transparency flag to -1 when no >>transparency is used, or else the palette index of the transparency >>color. The sample image I was using indicates that the transparency >>index is 255. Due to an unintended sign extension, the transparency >>index (held in a Byte array of basic type "signed char") is >>sign-extended to the variable "transparency" of basic type "signed int". >>This causes the flag to be assigned the value -1, which happens to be >>the same value used as a no-transparency indicator. So transparency was >> >> > ....^^^^^^^^^^^^ > >Heh, 3 times "the transparency" in exactly the same line position, 4 times >"transparency" in exactly the same position - what did you smoke?? ;-) > >(or worse, what did *I* smoke to recognize this?? :-) > > You is funny.... I am thinking what you smoked. What I see is that Alex didn't cut the text, but your email client: yes! >OK, I promise I'll stop that useless fun email here. > >Anyway, thanks for all those nice patches, > >Andreas Mohr > > > ;)

March 29, 2005

Re: OLEPICTURE: Initialize [orig|himetric][Width|Height] for PICTYPE_ICON case

by Alexandre Julliard

Alex Villacis Lasso <a_villacis(a)palosanto.com> writes: > + hdcRef = CreateCompatibleDC(0); > + pInfoBitmap = (BITMAPINFO *)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(BITMAPINFOHEADER) + 256 * sizeof(RGBQUAD)); > + pInfoBitmap->bmiHeader.biSize = sizeof(pInfoBitmap->bmiHeader); > + GetDIBits(hdcRef, infoIcon.hbmColor, 0, 0, NULL, pInfoBitmap, DIB_RGB_COLORS); This seems a bit overkill just to retrieve the bitmap size. Couldn't you simply do a GetObject on the bitmap? -- Alexandre Julliard julliard(a)winehq.org

March 29, 2005

Re: ScrollWindow fix for windows with WS_CLIPCHILDREN style, with tests - version 2

by Alexandre Julliard

Rein Klazes <wijn(a)wanadoo.nl> writes: > windows : scroll.c > dlls/user/tests : win.c > > If ScrollWindowEx is called with SW_SCROLLCHILDREN flags for a window > with a WS_CLIPCHILDREN style, then do not use the DCX_USESTYLE flag > option to get a DC for this window. With a couple of regression tests. DCX_USESTYLE has other effects, is it really correct to disable them all? And if so, wouldn't it be better to never use DCX_USESTYLE? -- Alexandre Julliard julliard(a)winehq.org

March 29, 2005

Re: Regression in winealsa (message only?)

by Jeremy White

Hi Paul, I see the same behavior after Robert's change to use plug:hw:0 (and removing my settings in ~/.wine/config). The attached patch 'fixes' the problem for me; can you try it? However, to be honest, the real issue is that I don't really understand what's going on. It appears as though the plug: devices are legitimate PCM device names, but that you can't use them for the control interface. If that's true, then this patch is correct. I just can't find any sensible Alsa document to give me comfort that this is right. I'd appreciate affirmation of this or a pointer to better Alsa doco <grin>. Cheers, Jeremy Paul Vriens wrote: > On Thu, 2005-03-24 at 21:26, Jeremy White wrote: > >>Hmm. That's my patch, but it bumps into one from Robert Reif. >> >>Robert, is plug:hw:N the correct device naming convention for >>PCM opens? I've always done plughw:N. It appears as though >>the snd_hctl_open of plug:hw:0 is failing. >> >>I can't tell because of the lack of Alsa documentation which >>is supposed to be right; if we're supposed to do plughw:0 >>instead of plug:hw:0, I'll have to fudge that code for the >>volume control stuff. >> >>Paul, you can test this for yourself by adding a >> >>[ALSA] >>"PlaybackDevice"="plughw" > > > This doesn't make a difference. > >>to your config (or just try "hw" if that fails too). > > > The error message disappears but a new is there: > > fixme:wave:ALSA_WaveInit - > > >>and seeing if everything still works (if the error below >>goes away but a new one pops up, then I have work to do :-/). >> >>Cheers, >> >>Jeremy >> > > It doesn't seem to affect the sound though. > > Running current CVS with a +wave gives: > > trace:wave:ALSA_WaveInit using waveout device "plug:hw:0" > trace:wave:ALSA_WaveInit dev=0 id=Intel ICH name=Intel 82801DB-ICH4 subdev=0 subdev_name=subdevice #0 subdev_avail=0 subdev_num=1 stream=PLAYBACK subclass=GENERIC MIX > trace:wave:ALSA_TraceParameters FLAGS: sampleres=false overrng=true pause=true resume=true syncstart=true batch=true block=true double=true halfd=true joint=true > trace:wave:ALSA_TraceParameters access=(null) > trace:wave:ALSA_TraceParameters format=(null) > trace:wave:ALSA_TraceParameters channels_min=1, channels_min_max=10000 > trace:wave:ALSA_TraceParameters buffer_size_min=1, buffer_size_min_max=4294967294 > trace:wave:ALSA_TraceParameters rate_min=4000 rate_max=4294967295 > trace:wave:ALSA_TraceParameters buffer_time_min=1 buffer_time_max=4294967295 > trace:wave:ALSA_TraceParameters periods_min=0 periods_max=4294967295 > trace:wave:ALSA_TraceParameters period_size_min=0, period_size_min_max=4294967295 > trace:wave:ALSA_TraceParameters period_time_min=83 period_time_max=2048000 > trace:wave:ALSA_TraceParameters tick_time=1000 > trace:wave:ALSA_WaveInit Configured with dwFmts=000fffff dwSupport=00000060 > ALSA lib control.c:654:(snd_ctl_open_noupdate) Invalid CTL plug:hw:0 > trace:wave:ALSA_WaveInit using waveout device "plug:hw:1" > trace:wave:ALSA_WaveInit using wavein device "plug:hw:0" > trace:wave:ALSA_WaveInit dev=0 id=Intel ICH name=Intel 82801DB-ICH4 subdev=0 subdev_name=subdevice #0 subdev_avail=0 subdev_num=1 stream=CAPTURE subclass=GENERIC MIX > trace:wave:ALSA_TraceParameters FLAGS: sampleres=false overrng=true pause=true resume=true syncstart=true batch=true block=true double=true halfd=true joint=true > trace:wave:ALSA_TraceParameters access=(null) > trace:wave:ALSA_TraceParameters format=(null) > trace:wave:ALSA_TraceParameters channels_min=1, channels_min_max=10000 > trace:wave:ALSA_TraceParameters buffer_size_min=1, buffer_size_min_max=4294967294 > trace:wave:ALSA_TraceParameters rate_min=4000 rate_max=4294967295 > trace:wave:ALSA_TraceParameters buffer_time_min=1 buffer_time_max=4294967295 > trace:wave:ALSA_TraceParameters periods_min=0 periods_max=4294967295 > trace:wave:ALSA_TraceParameters period_size_min=0, period_size_min_max=4294967295 > trace:wave:ALSA_TraceParameters period_time_min=166 period_time_max=2048000 > trace:wave:ALSA_TraceParameters tick_time=1000 > trace:wave:ALSA_WaveInit Configured with dwFmts=000fffff > trace:wave:ALSA_WaveInit using wavein device "plug:hw:1" > trace:wave:ALSA_widMessage (0, DRVM_INIT, 00000000, 00000000, 00000000); > trace:wave:ALSA_widMessage (0, WIDM_GETNUMDEVS, 00000000, 00000000, 00000000); > trace:wave:ALSA_wodMessage (0, DRVM_INIT, 00000000, 00000000, 00000000); > trace:wave:ALSA_wodMessage (0, WODM_GETNUMDEVS, 00000000, 00000000, 00000000); > > The message is already present after a clean tools/wineinstall and: > > regsvr32 ir50_32.dll (needed for AVI). > > Cheers, > > Paul. > >

March 29, 2005

Re: Resent^2 : Zero out return string in GetMenuStr

by Uwe Bonnes

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.org> writes: Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >> Anything wrong with this patch? >> >> Changelog: dlls/user/menu.c: GetMenuStrA|W Initialize return string >> as an empty string Alexandre> You need to take the specified length into account before Alexandre> writing to the string. Alexandre, also before, there was a NULL written to position Zero of the string. However there where some checks and function calls that could return Zero but didn't touch the string. Now there is only a check that the argument is a pointer before the Null is written. What should be done in another way? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

March 29, 2005