November 2009 - Wine-Devel - list.winehq.org

Re: comctl32: Implementation the WM_GETTEXT processing of datetime control

by Nikolay Sivov

Ilya Shpigor wrote: > > GetWindowText work with the server side text buffer. Are you offer to use it? > I don't sure that control text and this kind of window text are same things. > Hmm, I'm not sure. Looks like setting text always goes to server call, maybe it's the same thing (synced somewhere?)... Anyway GetWindowText should work, and Wine's implementation uses WM_GETTEXT only for same process windows, so you shouldn't override default handling for this message. > Datetime control have own interpretation of data in the self text buffers. > Using window text will need some synchronization when this data change. Can I > do it? > Or course you can, format a string every time contents change and store it with SetWindowText(). WM_GETTEXT will work through default procedure (I've done it that way for IPAddress control). P.S. Also don't forget comments regarding tests part. Thanks.

Nov. 30, 2009

Re: mciqtz32: Fix open/close omissions.

by Dmitry Timoshkov

You need to provide more information why is this change required, and what is the problem you are trying to fix. -- Dmitry.

Nov. 30, 2009

Re: Implement a stub for PrintWindow in user32

by Dmitry Timoshkov

"Luke Benstead" <kazade(a)gmail.com> wrote: > +/************************************************************************ > + * PrintWindow (USER32.@) > + * > + */ > +BOOL WINAPI PrintWindow(HWND hwnd, HDC hdcBlt, UINT nFlags) > +{ > + return TRUE; > +} If this is a stub, it should not return TRUE, should print a FIXME, and probably set an appropriate last error. Besides, MSDN has a nice hint how to implement this API properly. -- Dmitry.

Nov. 30, 2009

Re: wine.inf: Remove obsolete and duplicate entries.

by Paul Vriens

On 11/30/2009 02:08 PM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Dear reviewers, > > Vitaliy Margolen wrote in the discussion of bug #20693: >> Those entries shouldn't be in the wine.inf in the first place >> (as Alexandre already said). If anything they should be removed >>from there to lessen the confusion. > > Here is a patch to remove those entries. Note that > I'm not familiar enough with the printing system or MS-Windows' > expected vital entries to judge whether the entries should be present > as default fallbacks on systems compiled without cups, > or which have no printer, > or because some apps on MS-Windows crash if they are not present > even when there's no printer > or whatever reason. I just trust your word. > > All I can see is that these entries about [HKLM\HARDWARE] do not make > it into system.reg on my Linux machine even though they are present in > wine.inf, I suppose because the dynamic device detection code > (hal/dbus) removes them (with no printer nor cups-dev installed). > > Regards, > Jörg Höhle > Hi Jörg, This was already (partly) done in commit d19e2ada9ce2d52d8b09e984fe5b12803bf6d4ca. -- Cheers, Paul.

Nov. 30, 2009

Re: comctl32: Implementation the WM_GETTEXT processing of datetime control

by Ilya Shpigor

Hi, Thanks for reply. > I don't think it's a right way. You probably should use window text > instead updating it on every change, > see how GetWindowText is implemented. GetWindowText work with the server side text buffer. Are you offer to use it? I don't sure that control text and this kind of window text are same things. Datetime control have own interpretation of data in the self text buffers. Using window text will need some synchronization when this data change. Can I do it? -- Best regards, Ilya Shpigor.

Nov. 30, 2009

Re: mciavi: Simplify play loop.

by Paul Vriens

On 11/30/2009 01:51 PM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > in the future, MCIAVI will hopefully be able to drive the loop > with either audio or video turned on or off individually > (setaudio/setvideo off), like native (e.g. mciavi can play > the audio tracks only). > Here's a first step towards unification. > > Regards, > Jörg Höhle > Tabs and space mixtures here as well. -- Cheers, Paul.

Nov. 30, 2009

Re: mciqtz32: Fix open/close omissions.

by Paul Vriens

On 11/30/2009 01:47 PM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Regards, > Jörg Höhle > Hi Jörg, You're mixing tabs and spaces here. -- Cheers, Paul.

Nov. 30, 2009

Re: [PATCH] [Server]: when getting the status of an exception, ensure the debugger continue information is not erased when releasing objects

by Alexandre Julliard

Eric Pouech <eric.pouech(a)orange.fr> writes: > diff --git a/server/debugger.c b/server/debugger.c > index 795a24a..4458a3b 100644 > --- a/server/debugger.c > +++ b/server/debugger.c > @@ -677,6 +677,8 @@ DECL_HANDLER(get_exception_status) > if ((event = (struct debug_event *)get_handle_obj( current->process, req->handle, > 0, &debug_event_ops ))) > { > + NTSTATUS status = STATUS_PENDING; > + > close_handle( current->process, req->handle ); > if (event->state == EVENT_CONTINUED) > { > @@ -686,10 +688,10 @@ DECL_HANDLER(get_exception_status) > set_reply_data( &event->context, size ); > current->context = NULL; > } > - set_error( event->status ); > + status = event->status; > } > - else set_error( STATUS_PENDING ); > release_object( event ); > + set_error( status ); Releasing an object should never change the error code. Where do you see that happening? -- Alexandre Julliard julliard(a)winehq.org

Nov. 30, 2009

Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.

by Dmitry Timoshkov

<Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > perhaps I should contribute to this thread given that I > indirectly triggered it via bug #20377. > > IMHO Wine, due to its sandbox nature ... There is no such a nature of Wine. -- Dmitry.

Nov. 30, 2009

RE: Introducing WineTestBot

by Greg Geldorp

Hi Andrew, > From: Andrew Fenn > > This sounds great, one question though. Is there a way to contribute > to your cloud so that members of the community could grow your windows > vm testing army? Interesting idea, it's not something I considered when designing this. The bot currently depends on a VMware specific API. That API, VIX, supports VMware vSphere (ESX), VMware Workstation and VMware Server. I believe Workstation can be controlled only locally, but vSphere and Server are network-capable. So it wouldn't be a big deal to add support for remote vSphere and Server VMs (btw, Server is free as in beer). Other VMs like VirtualBox would take more work to support. If anyone is serious about contributing VMs please contact me and we'll see how to integrate them. Ge.

Nov. 30, 2009