http://bugs.winehq.org/show_bug.cgi?id=6971
--- Comment #212 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-01-17 01:35:44 ---
(In reply to comment #210)
Explain how will that work for full-screen apps? And what part of _never_
warping mouse is so hard to understand?
ANY REAL solution should NOT warp mouse. And report MOUSE movements not the
POINTER movements.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=3427
Vitaliy Margolen <vitaliy(a)kievinfo.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
--- Comment #8 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-01-17 01:28:48 ---
(In reply to comment #6)
The bug you talking about is bug 16729.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=3427
Vitaliy Margolen <vitaliy(a)kievinfo.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
--- Comment #7 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-01-17 01:26:46 ---
Create new bug. This one is _REALLY_ closed.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=8287
--- Comment #21 from Artem S. Tashkinov <t.artem(a)mailcity.com> 2009-01-17 00:48:58 ---
The bug is still there (tested on GIT).
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=6682
--- Comment #17 from Artem S. Tashkinov <t.artem(a)mailcity.com> 2009-01-17 00:46:54 ---
> Removing deprecated CVS/GIT version tag.
What version is relevant nowadays?
> If still present, update version field to earliest known version of wine that had this bug.
All known wine versions have this bug.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=6661
Dylan Smith <dylan.ah.smith(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dylan.ah.smith(a)gmail.com
Status|NEW |ASSIGNED
--- Comment #9 from Dylan Smith <dylan.ah.smith(a)gmail.com> 2009-01-16 19:54:35 ---
The problem is that ascii richtext is being sent using the EM_SETTEXTEX
message, but it is also using the unicode codepage (1200). It seems as if
native richedit controls look at the initial bytes for the ascii string "{\rtf"
or "{\urtf" regardless of which codepage is used, then determines that the
string has an ascii encoding in the rich text format.
I sent a test case and a fix to wine-patches.
[1/2] richedit: Added test for detecting ascii rtf with unicode codepage.
http://www.winehq.org/pipermail/wine-patches/2009-January/067834.html
[2/2] richedit: EM_SETTEXTEX detects ascii richtext with unicode codepage.
(Fixes Bug 6661)
http://www.winehq.org/pipermail/wine-patches/2009-January/067835.html
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=6194
Juan Lang <juan_lang(a)yahoo.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks|5713 |
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=5713
Juan Lang <juan_lang(a)yahoo.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends on|6194 |
Component|winsock |-unknown
Summary|Google Pack installer aborts|Google Pack installer aborts
|because Background |
|Intelligent Transfer Service|
|not implemented |
--- Comment #9 from Juan Lang <juan_lang(a)yahoo.com> 2009-01-16 16:25:22 ---
>From a +module,+relay log:
0009:Call KERNEL32.GetModuleHandleA(0040e3b0 "mscoree.dll") ret=004065e7
trace:module:LdrGetDllHandle L"mscoree.dll" -> (nil) (load path L"C:\\Program
Files\\Google\\Common\\Google
Updater;.;C:\\windows\\system32;C:\\windows\\system;C:\\windows;C:\\windows\\system32;C:\\windows")
0009:Ret KERNEL32.GetModuleHandleA() retval=00000000 ret=004065e7
0009:Call KERNEL32.ExitProcess(8007007c) ret=00406616
Oddly, I do have .net 2.0 installed via winetricks, so I'm not sure why that's
failing. Anyway, it's not a BITS bug, so I'm removing that dependency.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=6971
--- Comment #211 from Tomasz Sałaciński <tsalacinski(a)gmail.com> 2009-01-16 13:51:04 ---
I think this might be the best solution - I wrote a patch that worked
flawlessly with all games but only when app's window was on the center of the
screen <- tested it with many applications and it worked like a charm. The only
problem was the mouse dmz - I don't know how to make mouse events readable by
the app if it leaves the window.
>From my experience on fast moves you'll need at least ~200 pixels.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=6971
--- Comment #210 from Marc Mengel <marc.mengel(a)gmail.com> 2009-01-16 13:30:31 ---
So I've been reading the discussion for this bug, and I hope this isn't an old,
already ruled out idea, but instead of all of this discussion of mouse-warping,
how about an option that runs the Wine application in a window which is nested
centered inside a surrounding mouse-dmz window, say about 50px wider than the
app window. If your mouse is in the mouse-dmz, but outside the application's
window, the mouse events still go to the application; but if the user drags the
mouse outside of the mouse-dmz, you pretend the mouse is still at the edge of
the mouse-dmz until it comes back inside. Then you could set the width of the
mouse-dmz wider for apps that need out-of-window mousing.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.