Re: Composite Widget Problem

Ala Qumsieh wrote:

>Perhaps I'm missing something obvious here, but I'm
>really stumped. Why doesn't the Canvas have a black
>background in this script.
>
>  
>
<code snipped/>

>It's just a composite mega widget with a just a
>(supposedly black) canvas.
>  
>
I think this stems from the basic "policy" that composites shouldn't be 
configuring their colors, and
leaving it up to users who are using the widget to do this with 
options.  There are calls made internally, from Tk::Derived, that 
overrode your black background. It *did* get set -- but was instantly 
overridden by Frame's default background color. Canvas was a child 
within Canvas and got it too. The problem is sometimes for a given 
application you'd like to be able to do this (at least, I sure would), 
and I think it's unfortunate that this is forced. Anyway, there are 
workarounds:

This for example (use afterIdle to configure the background/foreground):

  sub Populate {
    my ($w, $args) = @_;

    $w->SUPER::Populate($args);
    my $c = $w->Component(Canvas => 'Canvas')->pack; 
    $c->afterIdle(configure => $c, qw/-bg black/);
  }


 You can also take your subwidget out of the line of fire by
nesting it within a Frame. By default, all composites propogate
background/foreground to their children, but not descendants, so
you can do something like this:

  sub Populate {
    my ($w, $args) = @_;

    $w->SUPER::Populate($args);
    my $f = $w->Frame->pack;
    my $c = $f->Canvas(qw/-bg black/)->pack;
    $w->Advertise(Canvas => $c);
  }

There are a few other options as well, but they involve overriding key 
internal methods, and it can
get ugly.... so no example there ;-)

Rob



-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ptk" to [email protected]