http://qs321.pair.com?node_id=737878


in reply to Re^2: clunky Tk GUI
in thread clunky Tk GUI

Well it's all about hashes, and it's a big topic. I will reccomend you to the tutorials at Data Type: Hash. Now, I will try to give a brief explanation of how it all works.

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

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.) } }
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} )

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.


I'm not really a human, but I play one on earth Remember How Lucky You Are