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

Re: commctrl: dialog theming

by Evil

Mike McCormack wrote: > Could you please try the attached patch? > > I fear that Wine doesn't go forward as much as it should for lack of > testing :/ > The patch worked great! At least, it appears to work a lot better than before. There are still some graphical glitches, for example: If you switch server technology between yes and no when defining a site, the combo box doesn't completely reappear... but it's actually useable now! Please have this committed to CVS. Thanks Mike! Great Job! -Jesse

Aug. 19, 2005

Re: Mouse-buttons swapped after winetest

by Vitaly Lipatov

Hi, Can you pay attention to this patch? It really fixes the problem but not discussed in the list and not applied: http://www.winehq.com/hypermail/wine-patches/2005/08/0018.html В сообщении от 25 Июнь 2005 00:28 Paul Vriens написал(a): > On Fri, 2005-06-24 at 17:44, Saulius Krasuckas wrote: ... > > Such checks doesn't work on winME. I have reverted them and tests is > > doing fine. Further, following [2]: > > I agree these changes don't make sense. Although Vitaly says in his > patch: > /* MSDN says it returns previous state of swapbutton always */ > it doesn't seem to be the case for at least win98/winME/NT/W2K and XP > (which is almost all versions !) > Reverting the above fixes, it for me as well. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

Aug. 19, 2005

Re: USER32: fix gcc 4.0 warnings

by Alexandre Julliard

Mike McCormack <mike(a)codeweavers.com> writes: > When switching on a WORD value, case values should also be WORD values > to avoid value out of range warnings. We shouldn't be switching on a WORD, that magic item handling is broken. -- Alexandre Julliard julliard(a)winehq.org

Aug. 19, 2005

Weird issue with advapi32 tests on nt 4.0

by Ivan Leo Puoti

The advapi32 tests save a key, load it and delete the file, and all is fine. But on nt 4.0 sp6 I'm getting a *really* weird, thing, a saved_key.LOG comes out of the blue, it appears to get written to disc after the RegLoadKey call at line 543 of dlls/advapi32/tests/registry.c, however this really shouldn't happen, why should RegLoadKey write this empty file? Has anyone else seen this? I was tempted to send a patch to just delete the file but I'm curious about where this file is coming from and why it gets created, anyone have a clue?. Ivan.

Aug. 19, 2005

Re: winefile: TRY2 Fix for encoding Ru.rc

by Dmitry Timoshkov

"Yuri Kozlov" <kozlov.y(a)gmail.com> wrote: > Changelog: > fix for encoding Ru.rc > --- wine/programs/winefile/Ru.rc 2005-06-20 15:45:39.000000000 +0400 > +++ bwine/programs/winefile/Ru.rc 2005-08-18 19:56:37.000000000 +0400 > @@ -20,6 +20,8 @@ > > LANGUAGE LANG_RUSSIAN, SUBLANG_DEFAULT > > +#pragma code_page(1251) Why do you need it? Specifying a language should be enough, at least it works for all other resource files, including russian ones. -- Dmitry.

Aug. 19, 2005

Re: commctrl: dialog theming

by Mike McCormack

Evil wrote: > Dreamweaver's "Add Site" (and other) dialog are completely broken when > using the built-in comctl32. OK, there is a patch that is in CrossOver that has not yet been committed to WineHQ for some reason, that fixes this problem. > This was known way before I ever started using WINE (because I learned > of it by searching old mailing lists). I even added it to the app > database months back. Could you please try the attached patch? I fear that Wine doesn't go forward as much as it should for lack of testing :/ Mike

Aug. 19, 2005

Re: commctrl: dialog theming

by Evil

Vitaliy Margolen wrote: >...So having an option to use native comctl32 is not such a bad idea. > > > I couldn't agree more. I can't imagine that DreamWeaver's the only program that's broken (or will be broken, as new features are added and problems are worked out) when using the built-in implementation. I guess I'll backlevel for now, but I was loving playing with the newest DX patches. -J

Aug. 19, 2005

Re: [Bug 3165] Patch available

by Mike McCormack

Duane Clark wrote: >> Well the patch does improve the cursor. I can now see it. Although it >> is only grey. It there any reason why the best cursor selection method >> always checks for bits == 1. What about color cursors? >> > > I don't really understand how the patch fixed things, but... > Riven uses a bunch of color cursors (hands pointing various directions). > Without the patch, only the standard pointer cursor was generated. This > cursor appeared and disappeared normally (the cursor is supposed to > disappear while some Quicktime clips are playing, and then reappear). > With the patch, the color cursors reappeared and all are correct. It should improve things over the original code that was there in cursoricon.c revision 1.9. That code first checked if there was only one cursor, then returned it, but if there was more than on cursor, it would choose one a 1bpp cursor. That scheme would miss out picking a cursor at all if there was two coloured cursors. The new scheme makes sure that we always start with one cursor and improve over that. I think the problem is that standard X cannot support coloured cursors. The Xcursor extension appears to, but we don't support that. Any volunteers? Mike

Aug. 19, 2005

Re: [Bug 3165] Patch available

by Duane Clark

Kevin DeKorte wrote: > On Thursday 18 August 2005 03:24 am, Dripple wrote: >> Hi, >> >> I tested the patch submitted in >> http://bugs.winehq.org/show_bug.cgi?id=3165 Bugzilla page with Notes. >> Seems to fix the issue. >> >> Regards. >> >> Dripple. > > Well the patch does improve the cursor. I can now see it. Although it is only > grey. It there any reason why the best cursor selection method always checks > for bits == 1. What about color cursors? > I don't really understand how the patch fixed things, but... Riven uses a bunch of color cursors (hands pointing various directions). Without the patch, only the standard pointer cursor was generated. This cursor appeared and disappeared normally (the cursor is supposed to disappear while some Quicktime clips are playing, and then reappear). With the patch, the color cursors reappeared and all are correct.

Aug. 18, 2005

Re: Should all builtin DLLs have version information?

by Detlef Riekenberg

Paul Vriens wrote: > the subject says it all. If yes, I will start adding some for the ones IMHO that's a good idea. -- By By ... ... Detlef

Aug. 18, 2005