7.4.1 dies on color depth change

Does anyone have a solution for VW apps not coping with color depth
changes on Windows?

In the best case, all cached pixmaps for scrollbars etc. contain
garbage. Mostly, this causes a Pixmap primitiveFailed error immediately
or shortly afterwards. In an app sealed with RTP, opening this error
message dialog causes a redisplay of the offending pixmap, causing the
same error again - RTP interprets this as an infinitely recurring error
and shuts down VW immediately, no questions asked.

The root cause is that VW does not recognize the Windows event for a
change in color depth. There's also the issue of how to re-initialize
the graphics system after that change.

The problem is exacerbated by three dubious solutions in VW:
1) opening a dialog does a refresh of windows that it covers (I'd have
to check the details on that),
2) opening a dialog without an explicit parent processes all buffered UI
events in all windows, before trying to find the default parent window.
This certainly causes more problems that it solves, as it gets all kinds
of things out of order. E.g. if a buffered event would open a second
dialog, the second dialog opens before the first.
3) RTP's decision to bomb out is hardly ever justified. Does anyone have
production-tested code that circumvents this?

Cheers,
Steve

There's an AR on the graphics issue (don't recall the number).  As to
this one though, I maneuvered my way around that in BottomFeeder a
long while back.  In the public store, have a look at package
RSS-ErrorHandling, specifically, class BfRuntimeEmergency.

I subclassed the RTP notifier (there's a step allowing that in the
packager), and then overrode #notify.  Have a look at what I did there


>3) RTP's decision to bomb out is hardly ever justified. Does anyone have
>production-tested code that circumvents this?
>
>Cheers,
>Steve

<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView

As I recall, I experimented with just shutting down the WindowingSystem and restarting it in response to such events, which more or less worked, but I had a problem getting duplicates of windows opened and didn't look further to work around it.

At 03:29 AM 11/30/2006, Steven Kelly wrote:

Does anyone have a solution for VW apps not coping with color depth
changes on Windows?

In the best case, all cached pixmaps for scrollbars etc. contain
garbage. Mostly, this causes a Pixmap primitiveFailed error immediately
or shortly afterwards. In an app sealed with RTP, opening this error
message dialog causes a redisplay of the offending pixmap, causing the
same error again - RTP interprets this as an infinitely recurring error
and shuts down VW immediately, no questions asked.

The root cause is that VW does not recognize the Windows event for a
change in color depth. There's also the issue of how to re-initialize
the graphics system after that change.

The problem is exacerbated by three dubious solutions in VW:
1) opening a dialog does a refresh of windows that it covers (I'd have
to check the details on that),
2) opening a dialog without an explicit parent processes all buffered UI
events in all windows, before trying to find the default parent window.
This certainly causes more problems that it solves, as it gets all kinds
of things out of order. E.g. if a buffered event would open a second
dialog, the second dialog opens before the first.
3) RTP's decision to bomb out is hardly ever justified. Does anyone have
production-tested code that circumvents this?

Cheers,
Steve

my circumvention is to not package with RTP in the first place :)

does re-starting the image fix the problem? i.e. the problem only occurs  
if a user changes color depth while VW is up, right?

and thanks for pointing this out I'll test it here

-Charles

On Thu, 30 Nov 2006 15:45:00 -0500, Alan Knight <[hidden email]> wrote:



--
Charles A. Monteiro
http://wiki.nycsmalltalk.org
http://www.monteirosfusion.com
http://monteirofusion.blogspot.com

"Charles A. Monteiro" <[hidden email]> wrote:

| my circumvention is to not package with RTP in the first place :)

| does re-starting the image fix the problem? i.e. the problem only occurs
| if a user changes color depth while VW is up, right?

That's right.  VW supports all known Windows pixel depths, so yes it would have to.

---
The surest sign that intelligent life exists elsewhere in           Calvin &
the universe is that none of it has tried to contact us.             Hobbes.
--
Eliot     ,,,^..^,,,    Smalltalk - scene not herd     x4581 [hidden email]

Mark Pirogovsky spotted that James has kindly published the fix to a
package named "Bf-DepthChangeFix" in the public repository. Share and
Enjoy!

Steve
PS this is also useful when using VW over Remote Desktop or similar, and
reconnecting to a session left open - the color depth often changes. A
bit like ThrottledCursor, which is also useful with remote desktops:
http://www.parcplace.net/list-search/vwnc-archive?query=ThrottledCursor

> -----Original Message-----
> From: Charles A. Monteiro [mailto:[hidden email]]
> Sent: 01 December 2006 15:28
> To: Alan Knight; Steven Kelly; vwnc
> Subject: Re: 7.4.1 dies on color depth change
>
> my circumvention is to not package with RTP in the first place :)
>
> does re-starting the image fix the problem? i.e. the problem only
occurs
> if a user changes color depth while VW is up, right?
>
> and thanks for pointing this out I'll test it here
>
> -Charles
>
> On Thu, 30 Nov 2006 15:45:00 -0500, Alan Knight <[hidden email]>
wrote:
>
> > As I recall, I experimented with just shutting down the
WindowingSystem
> > and restarting it in response to such events, which more or less
worked,
> > but I had a problem getting duplicates of windows opened and didn't
look
> > further to work around it.
> >
> > At 03:29 AM 11/30/2006, Steven Kelly wrote:
> >> Does anyone have a solution for VW apps not coping with color depth
> >> changes on Windows?
> >>
> >> In the best case, all cached pixmaps for scrollbars etc. contain
> >> garbage. Mostly, this causes a Pixmap primitiveFailed error
immediately
> >> or shortly afterwards. In an app sealed with RTP, opening this
error
> >> message dialog causes a redisplay of the offending pixmap, causing
the
> >> same error again - RTP interprets this as an infinitely recurring
error
> >> and shuts down VW immediately, no questions asked.
> >>
> >> The root cause is that VW does not recognize the Windows event for
a
> >> change in color depth. There's also the issue of how to
re-initialize
> >> the graphics system after that change.
> >>
> >> The problem is exacerbated by three dubious solutions in VW:
> >> 1) opening a dialog does a refresh of windows that it covers (I'd
have
> >> to check the details on that),
> >> 2) opening a dialog without an explicit parent processes all
buffered
> UI
> >> events in all windows, before trying to find the default parent
window.
> >> This certainly causes more problems that it solves, as it gets all
> kinds
> >> of things out of order. E.g. if a buffered event would open a
second

Eliot wrote:
> VW supports all known Windows pixel depths (...)

Well, not entirely true. See my message with title "Incomplete area
copy Exception on 256 Color Display". I tried to provide a fix for it
in another mail to the group, but I do not think it has been included
in the newest product versions. Details below:

"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."