A question of colour

Or actually, several questions.

Does anyone have an idea why a RichTextEdit with it's #backcolor set explicitly
to
    RGB red: 214 green: 214 blue: 214.
in the view resource, should display itself as white in D6 when the same code
and resource is (correctly) light grey in D5 ?   Using an inspector shows that
the RichTextEdit's #backcolor /is/ grey, but it doesn't display that way unless
I change it to something else and then back again.

Has anyone figured out how to make splitters vanish as they do in D5 ?  In D6
they seem to render themselves fatter and in a different colour and are clearly
visible as separate elements of a GUI.

And lastly, what's happening with #backcolor in general ?  A lot of my views
(using only standard components) are showing up wrong in D6.  It seems to be
somehow connected with values of
    Color default
which have mysteriously assigned themselves to views #backcolor (such as
ContainerViews and StaticTexts) which are /supposed/ to be nil.  As a result
many of my views are displaying random-looking rectangles of white.   I realise
there are changes in this area in D6, and I can live with the changes, but I
want to understand what the new rules are -- it seems arbitrary so far...

    -- chris

Hi Chris,

> And lastly, what's happening with #backcolor in general

I think it is part of a set of changes to improve support for painting
transparent foreground controls over a background.

That is not an official answer!, but some other changes that I see as
related are:

 - The DolphinWindow class no longer has a class brush. (See View
class>>winClassBrush). This changes the behavior of default processing
of WM_ERASEBKGND (for the better IMO).

 - View>>onEraseRequired: has a new behavior c.w. D5, erasing its
location in its parent if #hasTransparentBackground.

 - Backcolors (or actually the "state of a backcolor") are now
effectively inherited from the parent view. (See View>>actualBackcolor
and View>>ambientBackcolor ). Associated with that are some of the
"special colors" Color none and Color default, are often tested for in
the new backcolor/erase methods, and change their behavior. The
comments of the above methods explain it better than I could.

Personally I think the changes are good step. The system makes sense to
me, and the behavior when using Color default is more consistent than
the slightly adhoc use of nil in D5.

I found implementing UIs in D5 which painted transparent controls over
gradient backgrounds (without flicker) very frustrating ... and ended
up rolling my own. I think the flicker problem will still exist, but I
believe that Vista will do all painting on a back buffer, so it should
not be a problem in the future.

The transparency side of the new "framework" does seem to rely on the
WS_EX_TRANSPARENT style, which from memory just changes the order in
which parent/child views are sent WM_PAINT messages. It has been ages
since I played around with this, but it caused me grief in D5. Maybe
with the changes in D6, this now works better.

FWIW: My guess is this was all driven by trying to get the new toolbar
look. The comment in Toolbar>>onEraseRequired: is worth reading.

> Has anyone figured out how to make splitters
> vanish as they do in D5

It now uses a gradient fill (See Splitter>>onPaintRequired: ). I had
not really noticed them, but I guess it would be more noticeable on
win2k. I see that Splitter>>forecolor and Splitter>>defaultBackcolor
are hard coded rather than using system colors. That looks like a bug
to me and is possibly why they look out of place on win2k.

I am not sure about the RichTextEdits ... I am just glad to see the
last of them :)

Steve

Steve,

> Personally I think the changes are good step. The system makes sense to
> me, and the behavior when using Color default is more consistent than
> the slightly adhoc use of nil in D5.

Thanks for the pointers.  It does seem to make sense now.  Its a pretty
complicated system, but I suspect unavoidably so.

The key change seems to be that the interpretation of nil has changed from "use
the default background" to "inherit from the parent view".  Which is why all
those (Color default) values have appeared -- it's the STB versioning mechanism
replacing the old nils with the new value which should mean the same thing.

Unfortunately my graphical custom views /don't/ use nil to mean that, so
there's be some redesign work involved.  Ho hum....


> > Has anyone figured out how to make splitters
> > vanish as they do in D5
>
> It now uses a gradient fill (See Splitter>>onPaintRequired: ). I had
> not really noticed them, but I guess it would be more noticeable on
> win2k. I see that Splitter>>forecolor and Splitter>>defaultBackcolor
> are hard coded rather than using system colors. That looks like a bug
> to me and is possibly why they look out of place on win2k.

The effect is actually not too bad in emulated Win2K look.  I may even come to
like it in time  -- I just don't like things changing when I haven't /told/
them to change.


> I am not sure about the RichTextEdits ... I am just glad to see the
> last of them :)

Seems to be a straightforward bug.  I can reproduce it using only a clean D6
image with no imports of D5 views.  I'll probably re-post as an explicit bug
report, maybe have a try at fixing it first.

    -- chris