Instead of storing individual widgets in separate scalars, you can store those scalars in a orderly hash structure, which will allow you to access them by a key. So for instance, say you had 2 pages, and 3 widgets on each page. You could be "clunky" and call them $page1_widget1, $page1_widget2, $page1_widget3, and $page2_widget1, $page2_widget2, $page2_widget3.
You can see how clunky that is. An alternative, would be to store them all in a hash, like
Now, all you need to do to access any widget, is the $page and $widget number. For instance, the 2ond widget on page2, would be $hash{2}{2}. ( or $hash{$page}{$widj} )my %hash; # NOT my $hash, unless you want to set it up reference sty +le # then create in loops $hash{$page}{$widget} #like foreach my $page(1..2){ #add the page $hash{$page}{'page'} = $nb->add(......) #fill each page with widgets foreach my $widg( 1..3){ $hash{$page}{$widj} = $hash{$page}{'page'}->Button(.....opt +ions.) } }
This is a very simple example of course, and real world apps each need the best hash setup. It sort of is an art that is learned by spending a few afternoons setting up hashes and experimenting. There are 2 great benefits to storing widgets in a hash.
1. It makes accessing and looping thru them easy. You can loop thru all the widgets on page2 for instance.
2. And this comes later.... if you want to put your script into a package or module, the hash is already setup to be blessed. Instead of $hash{$page}{$widj} you would have $self->{$page}->{$widj}.
A whole book could be written on this, so I'm stopping now. Just play around with simple apps, and store things in hashes...it won't take long for you to figure it out.
In reply to Re^3: clunky Tk GUI
by zentara
in thread clunky Tk GUI
by honyok
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |