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

Re: [PATCH] user32: edit control should respond to ctrl + z
by Dmitry Timoshkov Aug. 30, 2007

Aug. 30, 2007

"Lei Zhang" <thestig(a)google.com> wrote: > This lets users hit ctrl + z in edit dialogs. A test case is included. > This should fixed bug 9525. > + /* select all, cut (ctrl-x), undo (ctrl-z) */ > + SendMessage(hwEdit, EM_SETSEL, 0, -1); > + SendMessage(hwEdit, WM_CHAR, 24, 0); > + SendMessage(hwEdit, WM_CHAR, 26, 0); I'd suggest to add checks to make sure that every message you send above really worked. -- Dmitry.

2 1

Re: winex11.drv/wintab32[5/6]: implement WTInfoW
by John Klehm Aug. 30, 2007

Aug. 30, 2007

You forgot the patch. On 8/30/07, Mikolaj Zalewski <mikolajz(a)google.com> wrote: > Now we allow to query the Unicode data > > >

1 0

Re: winex11.drv[2/6]: wintab: skip non-pressure-sensitive devices for wintab32
by John Klehm Aug. 30, 2007

Aug. 30, 2007

You forgot the patch. On 8/30/07, Mikolaj Zalewski <mikolajz(a)google.com> wrote: > Another problem I had was that the laptop touchpad was detected as a > tablet. This may confuse Windows applications, as on Windows it isn't. > Also it confuses Wine because we support only one tablet - we assume > that each cursors have the same resolution. > > Is there a good way to select the correct devices as do we have to add > heuristics like the one in this patch? This patch ignored devices that > don't have the pressure axis. I assume that the WM_MOUSEDOWN gives > enough information so there is little loss that it can't be accessed > with wintab32. > > >

1 0

.NET support
by Jakob Eriksson Aug. 30, 2007

Aug. 30, 2007

Now that GDIplus is shaping up, is there a chance of implementing .forms support in mono with it? regards, Jakob

3 9

Fwd: Re: winmm: Change default driver order to be alsa, coreaudio, oss - try2
by Kuba Ober Aug. 30, 2007

Aug. 30, 2007

---------- Forwarded Message ---------- Subject: Re: winmm: Change default driver order to be alsa,coreaudio,oss - try2 Date: Tuesday 21 August 2007 From: Kuba Ober <kuba(a)mareimbrium.org> To: wine-devel(a)winehq.org On Sunday 19 August 2007, Vitaliy Margolen wrote: > Maarten Lankhorst wrote: > > Forgot to remove the strlen check. > > Isn't this a bit premature? ALSA still does not support proper sound > capture, working mixer, and not stable enough on some configurations. In fact, for whatever it's worth, on some machines running either CentOS5 or FC6, for me alsa is completely broken (choppy sound output from linux alsa applications, etc). :( Cheers, Kuba -------------------------------------------------------

1 0

Re: try2:patch for sysparams.c
by L. Rahyen Aug. 30, 2007

Aug. 30, 2007

On Thursday August 30 2007 07:03, you wrote: > Hello, > > I have corrected a patch. Now font in the menu and a font in winecfg > coincides. Your patch still doesn't work correctly. With 120 DPI setting font size in winecfg and notepad menu is different (menu' font is bigger; no so big as before but still bigger). As I have said, in Windows font size is the same in whole system if I change DPI setting and this is (correct) behavior of current WINE too. Please note that your patch behaves even worse at higher DPI resolutions. For example if I set: "LogPixels"=dword:00000096 ...In system.reg then menu font is of ridiculosly big size. In winecfg I have normal font size suitable for my display resolution. In fact, dword:00000096 setting this is what I use in both WINE and Windows (in Windows I can just use "Custom..." menu; in WINE winecfg isn't yet sophisticated enough). In short: if DPI setting changes then font size should change in linear fashion at the same rate for all fonts. Also please explain what exactly you are trying to fix with your patch (what application)? Are you sure that Windows behaves in the same way as you proposing? Test case probably would be nice thing. Sorry, but purpose of your patch is unclear to me. In your changelog field you tell that "This patch does a font for the menu, statusbar and messages dependent from logpixels" but as far as I know WINE already have correct behavior and respects the LogPixels value (it already sets correct size in menu, status bar and other GUI elements). This is why I'm asking you for an real-world example (with real-world application) of what you are trying to fix. P.S. Don't forget to reply to wine-devel so others can see the discussion.

3 4

Re: dsound: Disable thread calls and increase refcount in dllmain
by Dmitry Timoshkov Aug. 30, 2007

Aug. 30, 2007

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> wrote: > Seems native directsound keeps itself loaded by calling LoadLibrary when > attaching. A simple testcase I wrote confirms that at least for xp, by > not crashing. After seeing this, I decided to write my own test, and can confirm now that this patch looks correct: after a successful LoadLibrary("dsound.dll") FreeLibrary needs to be called 2 times before it starts to return FALSE. Just for fun I tested other dlls as well (GetModuleHandle returns 0 for all of them before the LoadLibrary call): user32 requires 4 FreeLibrary calls after LoadLibrary, dinput - 1, mfc42 - 1, advapi32 - 1, comctl32 - 1. I'm attaching the program I used for testing. > + GetModuleFileNameW(hInstDLL, modname, sizeof(modname)/sizeof(*modname)); > + LoadLibraryW(modname); Probably simple LoadLibrary("dsound.dll") should be enough. -- Dmitry.

3 2

Re: winex11.drv: Support GdiAlphaBlend with blendfn.AlphaFormat == 0 (2nd try, fixes bug #9262)
by Alexandre Julliard Aug. 30, 2007

Aug. 30, 2007

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > I'm not sure if I understood how it's supposed to look like. Is > something like this good? It adds an 'if' in the inner loop, but it's > an 'if' that is easy to predict and this version makes less memory > reads so maybe it will be better. You should put the if outside the loops, and keep the existing fast case with the memcpys and add a separate slower way for when alpha needs patching. -- Alexandre Julliard julliard(a)winehq.org

1 0

re: getting started...
by Dan Kegel Aug. 30, 2007

Aug. 30, 2007

Ed wrote: >I'm brand new to the list and would like to get a Windows application that >I wrote (uCon) to work with wine/winelib. I've submitted it to the application >database. I've tried it on Wine and it *almost* works, so I'd like to pursue >this further by building uCon with Winelib (as is recommended somewhere >in the documentation). Egads. Where does it recommend that? Using winelib is a terrible idea unless you really need it (e.g. on non-x86 platforms, it's your only option). The downside is that your app suddenly becomes very fragile with respect to user updates of wine; they need a synchronized version of your app that matches their version of Wine. I've seen this happen, and it's not pretty. Also, this means double the QA and release trouble. The Right Thing To Do IMHO is just make your app and wine work better together, not use winelib. So your next move is to file bugs in http://bugs.winehq.org describing how your app doesn't work with wine, and work with us to solve them. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

5 7

Re: [2/5] WineD3D: Clear unused channels on R32F and R16F textures on readback
by H. Verbeet Aug. 29, 2007

Aug. 29, 2007

On 29/08/2007, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Can you even use those formats as render target on any cards?

2 1