Incomplete area copy Exception on 256 Color Display

> -----Original Message-----
> From: Runar Jordahl [mailto:[hidden email]]
> Sent: Tuesday, May 30, 2006 3:06 PM
> To: vwnc-list
> Subject: Incomplete area copy Exception on 256 Color Display
>
> We have run into a problem in Windows 2000 when using 256 color
> displays. Here is the description of how to reproduce our problem:
>
> 1 Change to 256-color display
> 2 Start a base 7.4 image
> 3 Open a new workspace and  evaluate the snippet below:
>
> |window gc|
> window := TransientWindow openNewIn: (10@10 extent: 100@20).
> gc := ScreenGraphicsContext on: window.
> window close.
> gc colorValueForPaint: SymbolicPaint background.
>
> - If called using a 256 color display, an exception is raised.
> - If called when "true color" (32 bit) is used, no exception
> is raised.
>
>
> The root of the problem in our application is caused by a call to
> SymbolicPaint>>asColorValue. This happens when a closed menu window is
> being used. The implementation of #asColorValue is this:
>
> ^Window currentWindow
> ifNil:
> [| pixmap |
> pixmap := Pixmap extent: 1 @ 1.
> (pixmap graphicsContext)
> paint: self;
> displayRectangle: pixmap bounds.
> pixmap asImage valueAtPoint: 0 @ 0]
> ifNotNil: [:window | window graphicsContext colorValueForPaint: self]
>
> We think there should be a test to ensure that if a window is found,
> it must be valid. In other words; it must answer false to #isInvalid.
> We have a situation where "Window currentWindow" answers a window (a
> TransientWindow), but the window is no longer valid.
>
> We changed the method to look like this:
>
> asColorValue
> | currentWindow |
> currentWindow := Window currentWindow.
> (currentWindow isNil or: [currentWindow isInvalid])
> ifTrue: [| pixmap |
> pixmap := Pixmap extent: 1 @ 1.
> pixmap graphicsContext
> paint: self;
> displayRectangle: pixmap bounds.
> pixmap asImage valueAtPoint: 0 @ 0]
> ifFalse: [currentWindow graphicsContext
> colorValueForPaint: self]
>
> The change does not correct the initial problem described, but it
> ensures that our application never gets into that problem.
>
> Our suggestion is that Cincom look at the initial error, and see
> whether VisualWorks could be changed to behave similar on true color
> and 256 colors displays. Either is should generate an exception in
> both cases, or succeed for both. It would also be nice if someone
> considered whether the proposed change in #asColorValue should be
> included in a later release.
>
> Runar Jordahl
>
>