Scarborough has asked for the wisdom of the Perl Monks concerning the following question:

I do not have a lot if expierance with GUI's and hardly any with Tk until today when I worked throught the excellent tutorial on this site, BIG THANKS. However I have a problem.

I have a sub which returns a hash containing a variable name and a default value excacted from a file. The the hash is a different size each time. I then require to display the name and value and an Entry box to take text which will overwrite the default value later. Displaying the data I can do in a loop, My problem lies in traversing the hash and making an Entry box with a valid name when I don't know the number of items to start with.

I hope my question makes sense and thanks in advance for any help you can give me.

Replies are listed 'Best First'.
Re: Tk on the fly
by gri6507 (Deacon) on May 11, 2004 at 17:19 UTC
    I am not quite sure what it is you are expecting. But assuming that all you want to to show the hash keys and values in a Tk Entry box, then all you need is (untested)
    foreach(keys(%myhash)){ $entry->insert('end', "Key=$_, Value=$myhash{$_}\n"); }
      Thanks, I have used something similar to handle the display of the data from the hash and it works just fine. My main concern was the need to reference the entry boxes by name after some data has been changed in them. After a good nights sleep I think I can use the orginal hash for this.
Re: Tk on the fly
by Ven'Tatsu (Deacon) on May 11, 2004 at 18:47 UTC
    Are you looking for one Entry per value in the hash? If so something like this should work:
    my $pane = $mw->Scrolled('Pane', -height => 150, -width => 200, -scrollbars => 'osoe', )->pack; foreach my $key (keys %hash) { my $frame = $pane->Frame->pack(-side => 'top', -fill => 'x'); $entries{$key} = $frame->Entry->pack(-side => 'right'); $entries{$key}->insert('end', $hash{$key}); $frame->Label(-text => "$key")->pack; }
    I use the scrolled pane so that a large number of entries won't force Tk to expand it's window beyond the screen size.
      Thank you this is very helpful and has confirmed I was in the right area for what I'm trying to achive.
      Thanks.
Re: Tk on the fly
by graff (Chancellor) on May 12, 2004 at 00:54 UTC
    Maybe this isn't an issue for the quantity of data you're dealing with, but as a rule, widgets tend to impose a cost in terms of memory and cpu overhead -- the more widgets, the slower the GUI, especially if you're talking about creating and destroying lots of widgets during interactive operation.

    Actually, you're not likely to see a problem until you get over a few hundreds of widgets (depending on your hardware setup). Still, it would be better to configure the GUI so that it has a constant size and complexity from the user's point of view regardless of data quantity, and so that its memory and execution load grow in very small increments as data quantity increases.

    Consider a layout where you present the hash data in a Listbox, and allow the user to select any one Listbox item at a time, in order to edit the selected item -- this means you need only one Entry widget (or one set of Entry widgets, one for each editable "field" in the Listbox item), where the user can alter the content of the selected item. Once the user hits a "commit" button, the chosen entry is replaced in the Listbox (i.e. delete the old and insert the new at the same index).

    Changing the contents of a Listbox is quick, easy, stable, and doesn't disrupt the user's view of the process. Changing the quantity of Entry widgets, even if these are in some sort of scrolling frame, is slower and more complicated.

      Thankyou for your excelent advice. Coming from the background I do, GUI's are a bit of a mystry to me. I will most definately be using your advice.
      Thanks.