Two packing problems

Hi,

in the example below i get strange results when:

1. i drag the Adjuster, it seems the Listbox is not
resized

2. When i make the whole window larger, not only the
Tk::Text is enlarged, but also the Frame "top", that
only contains the "Exit" button.

Is this related to the used Tk::Scrolled widget?


Best regards,
Torsten.


#! /usr/bin/perl -w

use Tk;

$mw = MainWindow->new();

$top = $mw->Frame();
$txt = $mw->Frame();
$choice = $mw->Frame();

$lb = $mw->Scrolled('Listbox', '-scrollbars' => 'se');
$lb->pack('-side' => 'left', '-fill' => 'both', '-expand' => 1);

$q = $top->Button('-text' => 'Exit', '-command' => \&ex);
$q->pack('-side' => 'left');

$t = $txt->Scrolled('Text', '-scrollbars' => 'se');
$t->pack('-side' => 'top', '-fill' => 'both', '-expand' => 1);

$choice->packAdjust('-side' => 'left', '-fill' => 'both', '-expand' => 1);
$top->pack('-side' => 'top', '-fill' => 'x', '-expand' => 1);
$txt->pack('-side' => 'top', '-fill' => 'both', '-expand' => 1);


MainLoop;

sub ex {
exit;
}

"Torsten Mohr" <tmohr@s.netic.de> wrote in message
news:chnk1u$akg$1@schleim.qwe.de...
> Hi,
>
> in the example below i get strange results when:
>
> 1. i drag the Adjuster, it seems the Listbox is not
>    resized
>
> 2. When i make the whole window larger, not only the
>    Tk::Text is enlarged, but also the Frame "top", that
>    only contains the "Exit" button.
>
> Is this related to the used Tk::Scrolled widget?
>
>
> Best regards,
> Torsten.
>
>
> #! /usr/bin/perl -w
>
> use Tk;
>
> $mw = MainWindow->new();
>
> $top = $mw->Frame();
> $txt = $mw->Frame();
> $choice = $mw->Frame();
>
> $lb = $mw->Scrolled('Listbox', '-scrollbars' => 'se');
> $lb->pack('-side' => 'left', '-fill' => 'both', '-expand' => 1);
#######
$lb->pack(-in=>$choice, '-side' => 'left', '-fill' => 'both', '-expand' =>
1);
#######
>
> $q = $top->Button('-text' => 'Exit', '-command' => \&ex);
> $q->pack('-side' => 'left');
>
> $t = $txt->Scrolled('Text', '-scrollbars' => 'se');
> $t->pack('-side' => 'top', '-fill' => 'both', '-expand' => 1);
>
> $choice->packAdjust('-side' => 'left', '-fill' => 'both', '-expand' => 1);
> $top->pack('-side' => 'top', '-fill' => 'x', '-expand' => 1);
#######
$top->pack('-side' => 'top', '-fill' => 'x', '-expand' => 0);
#######

> $txt->pack('-side' => 'top', '-fill' => 'both', '-expand' => 1);
>
>
> MainLoop;
>
> sub ex {
>         exit;
> }
>

Jack

On Wed, 08 Sep 2004 20:46:22 +0200, Torsten Mohr <tmohr@s.netic.de>
wrote:
>
>$lb = $mw->Scrolled('Listbox', '-scrollbars' => 'se');
>$lb->pack('-side' => 'left', '-fill' => 'both', '-expand' => 1);

Hi,  just a style comment. Before you get into a "habit" of doing it,
the left side of an options hash element, dosn't need to be quoted.
Not only will it save you some keystrokes, it helps "colorization"
in editors which highlight Perl syntax.

>
>$lb = $mw->Scrolled('Listbox',  -scrollbars => 'se');
>$lb->pack(-side => 'left',  -fill => 'both',  -expand => 1);



--
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html

Jack D wrote:

Thanks!  That solves both problems.


Best regards,
Torsten.

Hi,

> Hi,  just a style comment. Before you get into a "habit" of doing it,
> the left side of an options hash element, dosn't need to be quoted.
> Not only will it save you some keystrokes, it helps "colorization"
> in editors which highlight Perl syntax.

i once got the hint in this newsgroup that i should quote
the keys because at the moment it works, but this may change
in future.


Best regards,
Torsten.

Torsten Mohr wrote:
> Hi,
>
> 
>
>
> i once got the hint in this newsgroup that i should quote
> the keys because at the moment it works, but this may change
> in future.

Not exactly :) If I'm not mistaken, you got the hint that you should
have a leading dash in front of your option keys since old Tk versions
allowed option names with no leading dashes.

The quotes are not required in this case because of Perl's "fat comma"
operator (=> ) which is identical to a normal comma, except that it
automagically treats what is on its left as a quoted string. So, the
following are identical:

-option => 'value'

and

'-option', 'value'

--Ala

Ala Qumsieh wrote:
<snip>

> The quotes are not required in this case because of Perl's "fat comma"
> operator (=> ) which is identical to a normal comma, except that it
> automagically treats what is on its left as a quoted string. So, the
> following are identical:
>
>     -option => 'value'
>
> and
>
>     '-option', 'value'
>
> --Ala

Isn't the leading dash technically an exception to the rule? I thought the r
ule
was if the thing on the left of the fat comma looks like a bareword it will 
be
automagically quoted, otherwise it will be evaluated. Since lots of people u
se
the -name form for keys in an option hash a 'negated bareword' exception was
added to the rule.

I may of course be completely wrong :)
MB

Matthew Braid wrote:

> Isn't the leading dash technically an exception to the rule?

Yes. Perl recognizes that this is a bareword and not a "negative
string". It does not attempt to subtract it from nothing. Otherwise, you
would get warnings like:

Argument "option" isn't numeric in subtraction at ...

(assuming you have warnings enabled of course).

But this has nothing to do with the fact that earlier Tk versions
allowed options without dashes. Tk804 requires the dashes.

>                                                              I thought
> the rule was if the thing on the left of the fat comma looks like a
> bareword it will be automagically quoted, otherwise it will be
> evaluated. Since lots of people use the -name form for keys in an option
> hash a 'negated bareword' exception was added to the rule.

I never saw => evaluate its left hand side, and couldn't come up with a
case were it will. According to perlop, the left hand side of => will
always be treated as a quoted string:

The => operator is a synonym for the comma, but forces any word to its
left to be interpreted as a string (as of 5.001). It is helpful in
documenting the correspondence between keys and values in hashes, and
other paired elements in lists.

--Ala

Ala Qumsieh wrote:

<snip> 
>
>
> I never saw => evaluate its left hand side, and couldn't come up with a
> case were it will. According to perlop, the left hand side of => will
> always be treated as a quoted string:
>
>   The => operator is a synonym for the comma, but forces any word to its
>   left to be interpreted as a string (as of 5.001). It is helpful in
>   documenting the correspondence between keys and values in hashes, and
>   other paired elements in lists.
>
> --Ala

Sorry, by 'evaluated' I meant it is considered to be a normal expression, eg
:

$two = 2;
%hash = (1 => "one",
$two => "two",
1 + $two => "three",
FOUR => 4);
print join(", ", sort keys %hash), "\n";

results in:
1, 2, 3, FOUR

not
$two, 1, 1 + $two, FOUR

or some other weird output.

MB

Matthew Braid wrote:

> Sorry, by 'evaluated' I meant it is considered to be a normal
> expression, eg:
>
> $two = 2;
> %hash = (1 => "one",
>          $two => "two",
>          1 + $two => "three",
>          FOUR => 4);
> print join(", ", sort keys %hash), "\n";
>
> results in:
>  1, 2, 3, FOUR
>
> not
>  $two, 1, 1 + $two, FOUR
>
> or some other weird output.

That's due to precedence. Again, perlop to the rescue:

left        terms and list operators (leftward)
left        ->
nonassoc    ++ --
right       **
right       ! ~ \ and unary + and -
left        =~ !~
left        * / % x
left        + - .
left        << >>
nonassoc    named unary operators
nonassoc    < > <= >= lt gt le ge
nonassoc    == != <=> eq ne cmp
left        &
left        | ^
left        &&
left        ||
nonassoc    ..  ...
right       ?:
right       = += -= *= etc.
left        , =>
nonassoc    list operators (rightward)
right       not
left        and
left        or xor

Terms have highest precedence, so they get evaluated first. Addition has
a higher precedence than =>, so it gets executed next:

1 + $two => "two"
becomes
1 + 2    => "two"
becomes
3        => "two"

--Ala