Another thing that is well worth knowing about is "closures". This is where a function (or even better a group of functions) share a variable that is hidden from everything else.

So you could do something like:

# These brackets limit the scope of the lexical variables
  {
    # So this is a global variable that can only be seen 
    # between here and the close bracket below
    my(%parts);

    sub register_table
      {
        my($part_name,$part) = @_;

        $parts{$part_name} = $part;
      }

    sub get_table
      {
        my($part_name) = @_;

        return($parts{$part_name});
      }
  }

# So out here we can call &register_table and
# &get_table but we cannot see %parts
[download]

OK so this is a rather simplistic explination of what a closure does. It is good enough for a first level of understanding and there are lots of much better explinations on the web if you are interested

If you want to have access to all of the widgets on a page - create a hash of references and pass that to the subs. But be careful, wait until you have created all the widgets BEFORE you start building the callbacks using the configure method.

jdtoronto

-Mark

If you study the Tk::Widget man page, you should be able to work out a way to retrieve and correctly identify all the child widgets you want whose original variable names happen to be out of scope, so long as some level of parent widget is within scope.

graff has the right idea. I've attached some tested code that puts a pretty face on it. There's probably more than you need in the code, but hopefully it's worth reading.

First of all, you need to stop thinking in terms of the variables that you store your Tk widgets in. Tk doesn't know or care you have a variable named $mnuTerms. What Tk cares about is the widget name -- the 'Name' attribute you pass in when creating a widget. If you don't provide a name, then Tk will generate a name. Widgets always have names even if the name is something like 'button37'.

It's useful to think of Tk as a little widget database. Names are the keys used to fetch widgets.

The Notebook add method is a little different. The first argument is the name of the page you are adding. Notebook hides the details, but a page is really just a Frame and the name of the page is just the frame's 'Name'.

Examples:

  my $label = $frame->Label('Name' => 'title',
                            -text => 'Tk Names Tutorial');
  my $dialog = $top->DialogBox(-title => 'Generated Names',
                               -buttons => [ 'OK' ]);
  my $page = $notebook->add('Bill', -label => 'Billing');
[download]

Using the attached direct_descendant method, you can fetch those widgets like this:

  my $title = $frame->direct_descendant('title');
  my $button = $dialog->direct_descendant('bottom.button');
  my $bill = $notebook->direct_descendant('Bill');
[download]

You may need to fetch a widget with a distinctive name, but you don't know which frame it's in. The more general descendant method allows wildcards to skip over any number of frames. This is slower than direct_descendant, but it's generally fast enough if the search is started close to the widget you want to find.

  my $title = $top->descendant('*title');
  my $mnuTerms = $notebook->descendant('*Bill*terms');
[download]

But what if you don't know the widget name? This often happens because Tk doesn't force you to give widgets names. Use list_descendant_names while debugging to print out the names of all children. Use full_name to print out the complete path to a single widget.

  print join("\n", $notebook->list_descendant_names()), "\n";
  print $mnuTerms->full_name(), "\n";
[download]

You must give descriptive names to widgets that will be fetched later. If you don't, any changes to the order of widget creation will cause Tk to assign different names and that's a maintenance disaster waiting to happen.

Hope that helped. I find this database style of Tk programming eliminates most global variables. Add in a few judicious closures for callbacks and you've got a really clean and modular application.