ColorRef puzzle in owner-draw TreeView

Well it puzzles me anyway,,,

I'm messing around with owner-draw tree views, and am hitting a problem with
the colour sometimes turning out to be a ColorRef (whatever they are;
presumably some sort of Windows magic -- or necromancy).  The problem is
that I want to render some tree elements with their text "faded" and
attempting to #fade a ColorRef gives a walkback (they object to #asRGB).

Most of the time the forecolor of the context object used for the owner-draw
tree is a normal RGB, and it all works fine, but now and then (I think
mostly the first time a branch is opened) the ColorRefs creep in.

To reproduce, open a CHB, use the flipper to get to its class TreeView
(easiest way is to use the Visual Object Finder, drag it to the empty space
at the bottom of a  new CHB's class tree, and then Inspect the view aspect).
Set the TreeView's #customDrawBlock to:
        [:ctx || colour |
        colour := ctx forecolor.
        colour class = ColorRef
            ifTrue: [Notification signal: 'Urg!']
            ifFalse: [colour := colour faded].
        ctx forecolor: colour]
and save.

If your machine works the same way as this W2k box, then as the CHB is
refreshed all the class names will be shown faded, and as you open branches
of the tree the Transcript will fill up with 'Urg!'s.  Note, however that
all the classes are shown faded, and that 'Urg!'s don't appear every time
the CHB is drawn.  So *most* of the time, the context object has a normal
colour as its forecolor, but sometimes it has the oddity instead.

I've not seen anything similar happen with owner-draw list views.

For now my workaround for the problem is just to ignore owner-draw requests
when
    ctx forecolor class = ColorRef
and it seems to work OK, but that is only a hack.  There again, I have no
idea what is supposed to be happening here, so maybe that approach is the
only correct one...

    -- chris

Chris,

We must be looking at the same thing (the hierarchal display in the SB)
because I've come across the same problem. I'm not sure what's happening
either but a slightly neater fix is to implement:

ColorRef>>asRGB
    ^self becomeA: RGB

ColorRef>>asIndexColorUsingPalette: hPalette
    ^self asRGB asIndexColorUsingPalette: hPalette

This makes the problem "go away", at least on my system

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---


"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> Well it puzzles me anyway,,,
>
> I'm messing around with owner-draw tree views, and am hitting a problem
with
> the colour sometimes turning out to be a ColorRef (whatever they are;
> presumably some sort of Windows magic -- or necromancy).  The problem is
> that I want to render some tree elements with their text "faded" and
> attempting to #fade a ColorRef gives a walkback (they object to #asRGB).
>
> Most of the time the forecolor of the context object used for the
owner-draw
> tree is a normal RGB, and it all works fine, but now and then (I think
> mostly the first time a branch is opened) the ColorRefs creep in.
>
> To reproduce, open a CHB, use the flipper to get to its class TreeView
> (easiest way is to use the Visual Object Finder, drag it to the empty
space
> at the bottom of a  new CHB's class tree, and then Inspect the view
aspect). branches
> of the tree the Transcript will fill up with 'Urg!'s.  Note, however that
> all the classes are shown faded, and that 'Urg!'s don't appear every time
> the CHB is drawn.  So *most* of the time, the context object has a normal
> colour as its forecolor, but sometimes it has the oddity instead.
>
> I've not seen anything similar happen with owner-draw list views.
>
> For now my workaround for the problem is just to ignore owner-draw
requests

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> Well it puzzles me anyway,,,
>
> I'm messing around with owner-draw tree views, and am hitting a problem
with
> the colour sometimes turning out to be a ColorRef (whatever they are;
> presumably some sort of Windows magic -- or necromancy).  The problem is
> that I want to render some tree elements with their text "faded" and
> attempting to #fade a ColorRef gives a walkback (they object to #asRGB).
>
> Most of the time the forecolor of the context object used for the
owner-draw
> tree is a normal RGB, and it all works fine, but now and then (I think
> mostly the first time a branch is opened) the ColorRefs creep in.
>...

Try the attached. It seems that the tree view occassionally sends prepaint
custom draw notifications with an empty area and both colours set to
CLR_NONE (-1). Quite why it is sending paint requests for an empty area I do
not know (although it is, as you say, always when expanding a node), but you
should find that the attached will suppress subsequent notifications so that
they do not reach the custom draw block.

At the moment I've only tried this on XP with the most recent common
controls, and from reading the help it might not be sufficient for older
versions.

Regards

Blair
--------------------

!IconicListAbstract methodsFor!

nmCustomDraw: pNMHDR
 "Private - Handle a NM_CUSTOMDRAW notification message.
 Implementation Note: Defer creating the header struct as long as possible
to avoid impacting
 draw speed too much as this message can be sent several times per
sub-item."

 | drawStage |
 ^(drawStage := pNMHDR dwordAtOffset: 12) == CDDS_PREPAINT
  ifTrue:
   ["Before any painting"

   "Inform the control whether want any custom drawing of items or their
sub-items"

   ((self customDrawBlock notNil or: [self hasSubItemCustomDraw])
    and: [(RECT fromAddress: pNMHDR asInteger + 20) area ~~ 0])
     ifTrue: [CDRF_NOTIFYITEMDRAW]
     ifFalse: [CDRF_DODEFAULT]]
  ifFalse:
   [(drawStage allMask: CDDS_ITEMPREPAINT)
    ifTrue:
     ["Before painting item"

     | context |
     context := self customDrawContextClass fromAddress: pNMHDR.
     context
      item: (self objectFromHandle: context itemHandle ifAbsent:
[^CDRF_DODEFAULT]);
      view: self. "The control attempts to draw stuff that isn't there on
occassion"
     (drawStage allMask: CDDS_SUBITEM)
      ifTrue: [self customDrawSubItem: context]
      ifFalse:
       ["If item pre-paint stage and we want sub-item, notify the control
accordingly"

       self hasSubItemCustomDraw
        ifTrue: [CDRF_NOTIFYSUBITEMDRAW]
        ifFalse: [self customDrawItem: context]]]]! !
!IconicListAbstract categoriesFor: #nmCustomDraw:!event
handling-win32!private! !

!RECT methodsFor!

area
 "Answer the area of the receiver; the product of width and height."

 ^self width * self height! !
!RECT categoriesFor: #area!accessing!public! !

Blair,

> Try the attached.
[...]
> At the moment I've only tried this on XP with the most recent common
> controls, and from reading the help it might not be sufficient for older
> versions.

It seems to work fine on W2k.  Thanks.

 Unfortunately I've only got the W2k box with me, so I can't try it on NT or
W98.

> Blair

    -- chris