April 2011 - Wine-Devel - list.winehq.org

Re: Fixes a crypt32 str test. (try 2)

by Juan Lang

Hi Christian, I'd like to see the actual test, preferably incorporated into the test suite. Thanks, --Juan

April 4, 2011

Re: [GSoC] Merge winecfg and Control Panel

by Tony Zhang

OK, I was pretty busy the whole week last week, and didn't get any chance to look into anything. But I cannot agree on this: But all that aside, all changes that winecfg is doing are registry only > changes. IMHO Wine doesn't need yet another program to writes something into > registry. There are already two: regedit and reg. > Yes, there are already regedit and reg to change registry, but they are not easy to use for regular users. Even a lot of Windows users don't know how to modify registry through regedit, not to mention those Linux users who have seldom, if ever, used Windows before. I might be wrong on this, but according to my knowledge, most wine user just want to use it as "easy" as in Windows, and certainly not many Windows users mass with regedit that often -- that is why there is control panel. I do think winecfg has its market, and to make it even better, I would like to combine it into the control panel. -- Tony (Chi Zhang)

April 4, 2011

Re: gsoc theming

by Nikolay Sivov

On 4/4/2011 16:45, Reece Dunn wrote: > On 4 April 2011 13:08, Andrew Green<greeniekin(a)gmail.com> wrote: >> Hi, >> I hate to message you on this email. I have messaged the mailing >> lists. Though I became more confused than anything. > Can you please keep the discussions on the mailing list? Thanks. > >> I would like to propose a project where comctl32 is implement >> correctly in windows for google summer of code. >> As far as i know windows uses SxS to load version 6 of comctl allowing >> theming. > This is correct -- an application needs to add a manifest file to tell > it to load version 6 of the comctl32 DLL in order to get theming > support on Windows. > >> It also uses windows class redirection to hijack controls >> from user32 to be themed(I don't know if it somehow uses subclassing). > This is how it is implemented in wine. Native doesn't subclass, it has its own copy of so called builtin controls in comctl32. First evidence for that is a special class registration call from comctl32 v6 to register themed classes. Second evidence is that new Button functionality for example is available only in comctl32 v6, not in latest user32 module, I doubt they customize existing behaviour, I think it's more likely some message handlers are reused (compiled in both modules) and some are present in comctl32 only. >> The confusing thing on the mailing list i was told not to make a >> separate version of comctl32. Which is understandable from a code >> maintenance point of view. Though contradicts what the gsoc ideas page >> says >> "control is overridden by a themed drawing version by subclassing. >> This is not the way it is implemented on Windows and this causes >> drawing issues and other nasty issues." >> As someone who is to be a mentor of this section. What is the goal? >> and if subclassing is the option, how is this meant to work? > There isn't a contradition. > > AFAICS, the subclassing works -- the subclassed window procedure gets > called correctly. > > The drawing issues can be seen clearly on the button controls -- if > the button changes state (enabled<-> disabled, pressed, etc.) then it > gets drawn without theming. This is because the button control in Wine > does not call WM_PAINT to do the drawing, which the themed button > overrides. Subclass may work fine of course, but could cause problems. For example it's possible that application clears all subclass slots (if we're talking about comctl32 mechanism with procedure stack). When you create button with v6 on windows you don't get sublcassed control (stack is empty), that may be important. Anyway if you subclass let's say a Button you need to override lot of handlers potentially, cause for example new window styles could be rejected by modern user32 but accepted in comctl32 logic. That could cause a mess when different code works with not necessary valid control data. This needs some testing. Another question is to determine if we need to use controls from comctl32 in a first place. If you have active theme it doesn't mean that developer wanted to use it if he doesn't specify manifest to load version 6. So to summarize, the way I see this to be properly done step by step: 1) add class redirect detection for activation context code (ntdll/kernel32). Returned structures are undocumented, but if you dump data you'll see something (I did); 2) (hard part, for me at least) figure out when to invoke class registration call from comctl32 to move registration to comctl32. 3) add tests for user32 to see how builtin classes respond to new version 6 styles/messages; 4) figure out what code could be reused between user32 and comctl32 and reuse as much handlers from user32 as possible. This will need some build tweaks probably, I'm not sure, to share files between dlls. What also bothers me is that I'm not sure comctl32 versions of controls (in windows) use A/W magic for procedures that user32 uses. > Therefore, you will need to either: > 1/ convince Alexandre through tests that these tests do call > WM_PAINT [*] and update the non-themed control accordingly; or > 2/ implement the state tracking/logic in the themed button and have > it call WM_PAINT [*]. > > [*] or the correct custom drawing messages. > > HTH, > - Reece > > >

April 4, 2011

Re: po: Update US English resource

by Alexandre Julliard

Ken Sharp <kennybobs(a)o2.co.uk> writes: > Just ise/ize changes > From 60f207abd03edf7ffac6f129a8bffd537596d54e Mon Sep 17 00:00:00 2001 > From: Ken Sharp <kennybobs(a)o2.co.uk> > Date: Fri, 1 Apr 2011 23:07:03 +0100 > Subject: po: Update US English resource These need to be changed in the original rc files. -- Alexandre Julliard julliard(a)winehq.org

April 4, 2011

Re: gsoc theming

by Reece Dunn

On 4 April 2011 13:08, Andrew Green <greeniekin(a)gmail.com> wrote: > Hi, > I hate to message you on this email. I have messaged the mailing > lists. Though I became more confused than anything. Can you please keep the discussions on the mailing list? Thanks. > I would like to propose a project where comctl32 is implement > correctly in windows for google summer of code. > As far as i know windows uses SxS to load version 6 of comctl allowing > theming. This is correct -- an application needs to add a manifest file to tell it to load version 6 of the comctl32 DLL in order to get theming support on Windows. > It also uses windows class redirection to hijack controls > from user32 to be themed(I don't know if it somehow uses subclassing). This is how it is implemented in wine. > The confusing thing on the mailing list i was told not to make a > separate version of comctl32. Which is understandable from a code > maintenance point of view. Though contradicts what the gsoc ideas page > says > "control is overridden by a themed drawing version by subclassing. > This is not the way it is implemented on Windows and this causes > drawing issues and other nasty issues." > As someone who is to be a mentor of this section. What is the goal? > and if subclassing is the option, how is this meant to work? There isn't a contradition. AFAICS, the subclassing works -- the subclassed window procedure gets called correctly. The drawing issues can be seen clearly on the button controls -- if the button changes state (enabled <-> disabled, pressed, etc.) then it gets drawn without theming. This is because the button control in Wine does not call WM_PAINT to do the drawing, which the themed button overrides. Therefore, you will need to either: 1/ convince Alexandre through tests that these tests do call WM_PAINT [*] and update the non-themed control accordingly; or 2/ implement the state tracking/logic in the themed button and have it call WM_PAINT [*]. [*] or the correct custom drawing messages. HTH, - Reece

April 4, 2011

Re: [2/2] user32: DefDlgProc on WM_QUIT should repost it and terminate the dialog message loop.

by Marvin

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=10328 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

April 4, 2011

Re: [1/2] user32: Add a test for WM_QUIT handling by DefDlgProc.

by Marvin

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=10327 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

April 4, 2011

Re: [PATCH 2/2] comdlg32: Add support for customizing control labels in the item dialog.

by Nikolay Sivov

On 4/4/2011 13:01, David Hedberg wrote: > static HRESULT WINAPI IFileDialog2_fnSetOkButtonLabel(IFileDialog2 *iface, LPCWSTR pszText) > { > FileDialogImpl *This = impl_from_IFileDialog2(iface); > - FIXME("stub - %p (%p)\n", This, pszText); > - return E_NOTIMPL; > + TRACE("%p (%p)\n", This, pszText); > + If you trace text parameter pointer value itself is not very interesting. Why not dumping a string?

April 4, 2011

Re: (без темы)

by Dmitry Timoshkov

Roman Dadkov <romand(a)etersoft.ru> wrote: > 1) Magic field does not contain the correct information when creating a > storage file in Wine. > 2) Some fields are not filled with zeros when creating a storage file > in Wine. But these fields are filled with zeros when creating a storage > file in Windows. How is this different from the previous attempt? Did you address the comments? -- Dmitry.

April 4, 2011

Re: [PATCH] user32/tests: Fixed SetParent test on 64bit Vista

by Dmitry Timoshkov

Austin Lund <austin.lund(a)gmail.com> wrote: > Is there any obvious reason why this passes on the testbot when I sent > it myself, but the automated tests still fail? > > http://test.winehq.org/data/123e4ad41d81bf4edc56eeab9f3cece9b511f690/vista_… > > The reported sequence seems to suggest that all the activate messages > are skipped. (?) I should note that the message tests passed cleanly for me under Vista 64-bit on my laptop's dual boot even without your patch, so I don't know what is going on on that system. -- Dmitry.

April 4, 2011