Hi, I'm glad I could help you. To go further, in my previous reply I suggested for responsiveness, try to stick to one widget, like the canvas. If you go and try to add 1000 OptionMenus to the Canvas, it will quite possibly slow things up, because all those extra widgets need event handling. There is a good solution though, by popping up toplevel windows to handle your OptionMenus. So in the example I gave, you would add a right-click binding to each active area, when the right-click is processed, it pops open a separate toplevel window containing your OptionMenu. You load the OptionMenu dynamically from a big hash of data. Then REUSE the OptionMenu by deleting all it's current options, and reloading it when it needs to be used again. So, the overall idea is to make a single reusable toplevel window ( or popup ), with a single reusable OptionMenu, which you dynamically reconfigure with appropriate data on each use. This way, you stay responsive, AND MORE IMPORTANTLY, you don't start getting unwanted memory gains from repeated toplevel creations. Always think in terms of reusing widgets if possible, as that keeps the memory footprint under control.
As a quick example, here is a reusable toplevel that you could use. See Re: opening multiple sub-windows in perl tk
| [reply] |
