I have a fix for this bug, but it just handles the current erroneous behavior, it doesn't get fix the real cause of the bug. So, other apps might have problems getting the proper size for their scrollbars still.
Attached is a patch that adds a sanity check to the x11drv so that we never try to create windows that will cause the X server to stop and wine to crash.
Tomorrow, I'll find the real maximum values in the X11 source.
I know this does not fix the real cause of the problem, but it does fix a crash in wine.
On Wed, May 01, 2002 at 03:32:45PM -0400, Michael Cardenas wrote:
Does anyone know how an app determines the size it's scrollbar should be? I think it is done with either the GetDeviceCaps or something in the DC(?)
In crossover office, when word tries to open a document it tries to create a window with class SCROLLBAR of size 16x0, and the document opens fine.
In the public tree, when word tries to open a document, it tries to create a SCROLLBAR window of size 1065353216x0, and X barfs and word crashes.
Running with +relay, the window has the size 981316x0 and the document opens fine.
If anyone has any pointers here, I'd really appreciate it.
thanks michael
On Wed, May 01, 2002 at 09:15:18AM -0400, Michael Cardenas wrote:
This feature works correctly in crossover office, by the way.
...
The crash occurs after create_whole_window and create_client_window are called, when we try to do a TSXSync.
...
trace:x11drv:X11DRV_CreateWindow after create_client_window X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 1 (X_CreateWindow) Value in failed request: 0x0 Serial number of failed request: 2275 Current serial number in output stream: 2278