http://bugs.winehq.org/show_bug.cgi?id=9198
--- Comment #6 from Mikolaj Zalewski <mikolaj.zalewski(a)gmail.com> 2007-09-06 15:29:17 ---
The edit box starts as a Unicode control then it gets subclassed once as
Unicode and then a second time as ANSI. Thus at last the control is ANSI. The
text is set with SetWindowTextW. It is first converted to ANSI in the second
subclass winproc then back to Unicode with the first. That winproc should be
Unicode but calls the original (i.e. Unicode) winproc with CallWindowProcA. So
far the tests showed that the fact that the window is ANSI and CallWindowProcA
was used should overweight the fact the the winproc is Unicode and the ANSI
winproc should be called. I will have to check why this works under Windows.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=6181
--- Comment #12 from Bruce-b <bruceb78(a)gmail.com> 2007-09-06 15:18:20 ---
(In reply to comment #11)
> I think that is because of the SMP problem; there's another bug for that.
>
Maybe, i have ATHLON 64 X2 4200+. How can i fix SMP bug ? can i run the game
only on 1 CPU ?
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=6181
--- Comment #11 from Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> 2007-09-06 15:11:02 ---
I think that is because of the SMP problem; there's another bug for that.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=6181
Bruce-b <bruceb78(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bruceb78(a)gmail.com
--- Comment #10 from Bruce-b <bruceb78(a)gmail.com> 2007-09-06 15:05:09 ---
I have exactly the same bug with the free release of C&C and wine 0.9.33 and
0.9.44.
The menu freeze when i click on "option" during game and i must restart X.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=8190
John Welch <pcjohn(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pcjohn(a)gmail.com
--- Comment #5 from John Welch <pcjohn(a)gmail.com> 2007-09-06 14:51:54 ---
This bug can be fixed by using: "wine regsvr32" for every .dll file under the
PlayOnline directory.
You must also run it in a virtual desktop.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=9198
Mikolaj Zalewski <mikolaj.zalewski(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
--- Comment #5 from Mikolaj Zalewski <mikolaj.zalewski(a)gmail.com> 2007-09-06 13:02:56 ---
There is one issue still there - when one chooses the font tool, the edit field
of the font family combo shows only the first letter of the name. In the
drop-down the font names are shown correctly.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=657
Dan Kegel <dank(a)kegel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dank(a)kegel.com
--- Comment #44 from Dan Kegel <dank(a)kegel.com> 2007-09-06 08:44:10 ---
At some point in the future, we might want to do
this, but there is very little urgency, and
many other problems to deal with.
It would be more productive to simply make it
easy for users to install some freely downloadable
app that happens to come with the runtime.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=7404
--- Comment #16 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2007-09-06 08:42:43 ---
Created an attachment (id=7972)
--> (http://bugs.winehq.org/attachment.cgi?id=7972)
Make ShowWindow(SW_MINIMIZE) move a top level window to position -32000,-32000
The app creates a new dialog with CreateDialogIndirectParamA, and in its
WM_INITDIALOG handler does:
ShowWindow(hwdlg, SW_MINIMIZE); // calls SetWindowPos(SWP_SHOWWINDOW)
UpdateWindow(hdlg);
UpdateWindow causes a WM_PAINT, and the app crashes in WM_PAINT handler.
The app (or rather mfc42?) simply doesn't expect to receive WM_PAINT for
a minimized top level window.
Before my patch ShowWindow(hwdlg, SW_MINIMIZE) didn't set SWP_SHOWWINDOW flag
for the SetWindowPos() call, and SetWindowPos() didn't create an update region
for a window. The tests show that ShowWindow(hdlg, SW_MINIMIZE) correctly adds
the flag SWP_SHOWWINDOW to SetWindowPos(), so that part is correct.
What is not correct, is that under Windows ShowWindow(hwdlg, SW_MINIMIZE)
although adds WS_VISIBLE (Wine does as well) actually moves a top level
window to position -32000,-32000, i.e. moves it outside of the desktop.
Attached patch implements the same behaviour under Wine, but this uncovers
another Wine bug: Wine still generates a WM_PAINT message for such a window.
I briefly looked at the code in server/window.c,set_window_pos(), but I'd
better
leave this to Alexandre. To me it looks like a new visible region of a window
should be clipped by parent/desktop, but currently it is not.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=8612
Rick Weed <weed_richard(a)hotmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |weed_richard(a)hotmail.com
--- Comment #2 from Rick Weed <weed_richard(a)hotmail.com> 2007-09-06 04:39:28 ---
I'll confirm this. Some of my characters cause WOW to hang at the loading
screen. These characters are in Ogrimmar and Thunder Bluff. Character in
Booty Bay is okay.
Solution: Roll back from Wine 0.9.44 to 0.9.41. All characters load fine.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.