http://bugs.winehq.org/show_bug.cgi?id=2096
------- Additional Comments From carl.sopchak(a)cegis123.com 2005-24-02 15:38 -------
It's been a while since I've done a CVS update (mainly, because of this bug),
but I did one fairly recently. Wine does not seem to be crashing hard when
printing partial pages of checks now, but I still get the fixme's:
fixme:bitmap:CreateCompatibleBitmap got bad width 1109579968 or height 64,
please look for reason
fixme:bitmap:CreateCompatibleBitmap got bad width 1109579968 or height 64,
please look for reason
fixme:bitmap:CreateCompatibleBitmap got bad width 1109577352 or height 312,
please look for reason
fixme:bitmap:CreateCompatibleBitmap got bad width 1109577352 or height 312,
please look for reason
I'm still willing to work on this, but I'll need some pointers / suggestions /
nudges in the right direction...
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=2753
Summary: WM_NCCALCSIZE returns bogus values when WS_BORDER &
(0,0;0,0)
Product: Wine
Version: CVS
Platform: Other
OS/Version: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: wine-gui
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: carl.sopchak(a)cegis123.com
DefWindowProcA returns a window size of (1,1;1,1) when it processes message
WM_NCCALCSIZE on a window with a rectangle size of (0,0;0,0) and a style of
WS_BORDER. It should return (0,0;0,0).
I tried using the wine-devel mailing list to get help with how to fix it, but I
have not received a reply. Unfortunately, I'm not exactly sure HOW this should
be fixed, without potentially causing colateral damage. The thread title is
"Recent CVS update causes Quicken popup problem/Help please". Here is the final
part of the thread, which explains what is happening within wine:
On Monday, February 21, 2005 03:43 pm, Rein Klazes wrote:
> On 10 Feb 2005 21:19:46 +0100, you wrote:
> > Carl Sopchak <carl.sopchak_at_cegis123.com> writes:
> > > I guess my problem is that I have NO CLUE as to how this SHOULD be
> > > handled. Should the style be set to (style & ~WS_VISIBLE) when the
> > > rectangle is {0,0;0,0}? Should {0,0;0,0} be considered a valid
> > > rectangle in validate_window_rectangles()? Should
> > > validate_window_rectangles() only get called if the rectangle is not
> > > {0,0;0,0}? Or, very possibly, is there something else that should
> > > happen? Just to see what happened, I commented out the call to
> > > validate_window_rectangles, and the popup disappeared as it should.
> >
> > The client rectangle should have been set to {0,0;0,0} too. You should
> > look at the WM_NCCALCSIZE processing (SWP_DoNCCalcSize in
> > dlls/x11drv/winpos.c) and check what's happening there with the
> > rectangles.
>
> Experimenting for another issue, I noticed today:
>
> If I execute this under Win2K for a window with the WS_BORDER style:
> | MoveWindow( hwnd, 0,0,0,0,0);
> | GetWindowRect ( hwnd, &rc);
> | trace(" 1. %ld,%ld-%ld,%ld\n", rc.left,rc.top, rc.right, rc.bottom);
> | DefWindowProcA(hwnd, WM_NCCALCSIZE, 0, (LPARAM)&rc);
> | trace(" 2. %ld,%ld-%ld,%ld\n", rc.left,rc.top, rc.right, rc.bottom);
>
> this is the result:
>
> 1. 0,0-0,0
> 2. 1,1-1,1
>
> It seems to me this should be allowed as valid.
>
> Rein.
This is the same issue. I had sent the following under another subject, so it
didn't get "attached" to this thread, but here is what I found upon further
investigation:
Ok, so what is happening is this: In dlls/x11drv/winpos.c, the pNewWindowRect
is coming into SWP_DoNCCalcSize as (0,0;0,0), wndPtr->rectWindow is
(182,977;662;998), and wndPty->rectClient is (183,978;661,997). Then
winpos.c sends it's own WM_NCCALCSIZE message, and upon return,
params.rgrc[0] is (1,1;1,1)! This, in turn, causes the third and fourth
conditions in the section commented as "If the application sends back
garbage, ignore it" to be true, which in turn causes the next condition to be
false, so the client rectangle (pNewClientRect) does NOT get set. (Follow
that?? <g>)
Tracing through the processing of this WM_NCCALCSIZE, I find it ends up
generating two WM_NCCALCSIZE messages, one being handled by DefWindowProc32.
This leads me to ./windows/defwnd.c, which calls NC_HandleNCCalcSize
in ./windows/nonclient.c. Within NC_HandleNCCalcSize, a call is made to
NC_AdjustRectOuter, then the window's rectangle (winRect) is adjusted based
on this call. It is this call and adjustment of winRect that changes winRect
from (0,0;0,0) to (1,1;-1,-1), which is later "fixed" to (1,1;1,1).
Diving deeper, into NC_AdjustRectOuter, I find that because the window style
has WS_BOARDER set, adjust is set to 1, then InflateRect is called, which
sets rect to (-1,-1;1,1) [returned to NC_HandleNCCalcSize tmpRect variable].
So, there's the problem. The new rectangle size is (0,0;0,0), but has
WS_BOARDER set, so the WM_NCCALCSIZE message returns (1,1;1,1) erroneously.
The only thing is, I'm still not sure where the "best" place would be to check
for the new window rectangle of (0,0;0,0) and handle it appropriately - or
what "appropriate" would be, for that matter...
Further help would be appreciated.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=2751
Summary: messages
Product: Wine
Version: 20050111
Platform: Other
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-loader
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: tamay.yugnuk(a)gmail.com
When I install any program (office or win98) wiht wine
"fixme:font:load_VDMX No suitable ratio found" give me this message and stop.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=66
------- Additional Comments From us(a)the-edmeades.demon.co.uk 2005-23-02 16:11 -------
This is not going to be fixed in a hurry... I looked into this and the problem
is the use of the XOR bits of the cursor. From the comment in x11drv/mouse.c:
* We have to do some magic here, as cursors are not fully
* compatible between Windows and X11. Under X11, there
* are only 3 possible color cursor: black, white and
* masked. So we map the 4th Windows color (invert the
* bits on the screen) to black and an additional white bit on
* an other place (+1,+1). This require some boolean arithmetic:
If you look closely at the cursor, thats why it looks odd. The cursor is
stripes of black, white, XOR and AND - The XOR is emulated by producing a
shadow (which doesnt look great, but I suspect its the specific cursor being
done here)
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=2728
us(a)the-edmeades.demon.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #772 is|0 |1
obsolete| |
------- Additional Comments From us(a)the-edmeades.demon.co.uk 2005-23-02 15:10 -------
Created an attachment (id=773)
--> (http://bugs.winehq.org/attachment.cgi?id=773&action=view)
Patch for both problems
D'oh - Bug introduced as we get wined3d better supported. wined3d needs a
temporary fix, please use this attachment which I'll submit to wine-patches as
well
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
http://bugs.winehq.org/show_bug.cgi?id=2728
------- Additional Comments From nyyr(a)seznam.cz 2005-23-02 14:49 -------
So, i applied that patch. Now the game displayed 3D configuration window,
i choosed D3D HAL using hardware acc. 16-bit depth and windowed mode.
black window showing "loading" test appeared and then another
exception was raised. So i put applied that patch also to directx.c in ddls/d3d8/.
Now the game is running, but is terribly SLOW. On exit from the game it raises
another exception - see log:
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.