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.
In reply to Re: Tk on the fly
by graff
in thread Tk on the fly
by Scarborough
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |