Backcolor in TabView

Hi,

    I'm tuning my views, and i've started with my tab views.
    One problem i've found is that the backcolor in WinXP tabs is different
to the backcolor in previous non-XP Windows versions. In WinXP it is more a
#highlight3d color, and in previous versions it was the standard #face3d
color.

    Other problem i've found is with static text view, in which I can't set
it backColor to transparent (nil). It always stays with the face3d color,
unless I explicitly set it to another color.

    Months ago, Andy or Blair mentioned that the backcolor issue was
designed to inherit the container color (aka parent view), but for
performance reasons it wasn't implemented in the "mainstream", I think that
todays average workstation perfomance (a PIII 500, not more), will not feel
the impact of having such "backColor inheritance".

    Is it possible to have a small "patch", using it at our own risk, to
enable that feature?

    Because having framing layouts, which helps to develop GUI's adaptable
to many resolutions, and having the backcolor property being "dynamic", the
target audience may widen a lot, making applications with Dolphin even more
eye-candy than today, and simplifing things to us,  happy Smalltalkers :-)

    Best regards.

--
Esteban.

"Esteban A. Maringolo" <[hidden email]> wrote in message
news:[hidden email]...
Unfortunately it is not as simple as providing background colour
inheritance. XP actually uses a (subtle) gradient filled background for the
tabs, and indeed this would depend on the particular visual style that one
has set. This variable background fill then has to be inherited down into
the static child views (for example) and offset appropriately to make them
appear transparent over the tab background. The version 6 (XP) common
controls will do much of this themselves if one constructs the tabbed dialog
very carefully. It has to obey the following strict set of rules:
1) The tab pages (referred to as "property pages") must themselves be dialog
windows (i.e. instances of DialogView in Dolphin), rather than any other
sort of Container view.
2) The ThemeLibrary function EnableThemeDialogTexture() must be called
passing it the property page handle and the ETDT_ENABLETAB flag
3) The controls must be direct children of the property page - if you embed
controls within a further container (as is common in Dolphin when using
nested layout managers or reference views) then they will not inherit the
gradient filled background.
4) WM_ERASEBKGND must be passed to the controls window procedure, which will
be the case if the backcolor is not set (nil).
5) The maximum height of the property pages is about 600 pixels.

The worst of these restrictions is (3), and this evens causes some problems
in some standard Windows dialogs. If you run the following expression it
brings up the standard windows printer choice dialog:

    PrinterCanvas choose

Look carefully at the General tab of the dialog, and note that area
occuppied by the "Page Range" and "Number of copies" groups has the wrong
background colour. Its quite subtle and hard to see (and so someone at MS
got away with it), but it's not right. Using a tool such as Spy++ to examine
the Window shows that there is another container (actually another "dialog"
window) embedded here. If one calls the EnableThemeDialogTexture() on an
embedded dialog like this it will gradient fill its background, but using
its own client co-ordinates and so the gradient fill will not match up with
the parent.

Another problem is that the controls may not redraw correctly when the
dialog is resized. If you resize a view with a gradient filled background
you may find that the background of individual controls does not always
redraw when controls get moved around by the layout manager (e.g. if you are
using a FlowLayout). This is not very noticeable with the default XP fill
because it is very subtle, but if you use another theme it can become very
noticeable. The only workaround I know of for this is to invalidate the
container views when they are resized. This causes flicker, but fixes the
repaint issue.

Assuming you are on XP, try this out:

    d := (Dialog create: 'Default view') view.
    d hasThickFrame: true.
    t := CardContainer new.
    d addSubView: t.
    t arrangement: #center.
    pp := DialogView new.
    pp hasCaption: false; hasBorder: false; layoutManager: FlowLayout new;
insets: (10 @ 10 corner: 10 @ 10).
    t addSubView: pp.
    pp arrangement: 'Page1'.
    d show.
    1 to: 20 do:  [:i |
      | s1 |
      s1 := StaticText new.
      s1 usePreferredExtent: true.
      pp addSubView: s1.
      s1 text: 'Hello World ' , i displayString].

Notice that the tab page is displaying in a solid colour (I'm assuming you
are on XP here), and doesn't blend cleanly with the tab itself. However the
static text controls do draw "transparently" over the dialog background. Now
file in the following chunk to add a new method:

!ThemeLibrary methodsFor!
enableThemeDialogTexture: hwnd dwFlags: dwFlags
 <stdcall: hresult EnableThemeDialogTexture handle dword>
 ^self invalidCall! !

Which will then allow you to evaluate this expression:

    ThemeLibrary default enableThemeDialogTexture: pp asParameter dwFlags:
"ETDT_ENABLETAB"6. pp invalidate.

You should now see the gradient fill (its subtle and can be very hard to
see, depending on your display) which blends very neatly with the tab view.
Again the static text controls will be draw transparently over this (they
aren't really transparent, but their background is filled using the same
brush so they appear transparent).

Try resizing the dialog so the number of rows and columns changes. You might
be able to spot some redraw problems, but this is difficult with the default
XP theme. If you install a third-party theme with a sharper gradient fill,
you should spot it easily though.

Now try resizeing the dialog so that it is as tall as your screen. Assuming
you are not running on a small screen, you should see that the background
"runs out" when the property page gets too tall. This is because the bitmap
used to create the gradient brush for the background is only 600 pixels
high.

So, it is possible in Dolphin 5.1 almost as shipped to build property
dialogs that use the correct XP visual style, however it is quite
restrictive. We are working on improvements for Dolphin 6 that should allow
more control over background rendering, but in the meantime I've posted a
package on our site containing a property page container view that gets
around most of these restrictions.

http://object-arts.com/Lib/Downloads/Misc/DolphinTabPageView.zip

Hope this helps

Blair