Tkinter 网格管理器的大小限制
我正在编写一个 Python 应用程序来解析二进制文件列表、聚合其中数据的统计信息并输出结果。我可以轻松地将这些结果输出为 .tsv 文件，但编写此程序是为了方便我的同事，因此我尝试让它在新窗口中显示结果，以防止有时必须在 Excel 中打开文件。现在，我基本上将 Tkinter 框架嵌入到滚动画布中，并将包含数据标签的较小框架网格化到框架中。 （较小的框架似乎是使所有边框与网格线对齐所必需的；否则它们将被收缩以适合标签）
这种方法适用于一百列以上，甚至十行。但是当我开始将行数增加到数百行时，我开始遇到奇怪的问题。程序可能会变得无响应，新窗口可能不会显示，并且所有标签都放置在屏幕的左上角，而不是绘制在网格中。由于这似乎是一个与比例相关的问题，我想知道我是否只是用数以万计的元素来放置网格管理器。所以我有两个问题：1）我是否会遇到这样的限制，或者问题出在其他地方，2）是否有更好的方法在 Tkinter 中实现类似 Excel 的表格显示来避免这些问题？
I'm writing a Python application to parse a list of binary files, aggregate statistics on the data in them, and output results. I can easily output these results as a .tsv file, but this program is being written for the convenience of my coworkers, so I'm trying to have it display the results in a new window to sometimes prevent having to open the file in Excel. Right now I'm basically embedding a Tkinter frame in a scrolled canvas and gridding smaller frames containing labels of the data into the frame. (The smaller frames seem to be necessary to get all the borders to line up with the gridlines; otherwise they are shrinkwrapped to fit the labels)
This approach works with upwards of a hundred columns and maybe ten rows. But when I start increasing the number of rows to the hundreds, I start encountering odd problems. The program might become unresponsive, the new window might not display, and all the labels, rather than being drawn in the grid, are all placed in the top left corner of my screen. Since this appears to be a scale-related problem, I'm wondering if I'm simply overwhelming the grid manager with tens of thousands of elements to place. So I have two questions: 1) Could I be running into such limitations, or is the problem elsewhere, and 2) Is there a better way to implement an Excel-like table display in Tkinter that steers clear of these problems?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我编写了一个测试程序以两种方式显示数据，一次使用框架和网格，一次直接在画布上绘制文本。
使用框架+网格技术，100行乘10列的性能还算可以接受。当我增加到 200 行时，性能下降了 2 倍以上，而当我增加到 300 行时，性能已无法使用。我的意思是，初始显示花了几十秒。然而，一旦窗口出现，性能就可以接受了。
直接在画布上绘制文本项，性能明显更好。我可以显示 300 行 x 10 列，并且初始显示几乎是瞬时的。当我有 1000 行 100 列时，性能仍然可以接受，启动可能需要 2-3 秒。
因此，对于大量单元格，最好直接在画布上绘制它们。这意味着您需要自己计算行的高度，并对列进行一些数学计算 - 使用固定宽度的列或跟踪最宽的列，然后相应地调整坐标。
I wrote a test program to display the data two ways, once using a frame and grid and once drawing text directly on the canvas.
Using the frame+grid technique, the performance of 100 rows times 10 columns was quite acceptable. When I bumped that up to 200 rows the performance was more than 2x worse, and by the time I got to 300 rows, performance was unusable. And by that I mean, it took dozens of seconds for the initial display. Once the window appeared, however, the performance was acceptable.
Drawing text items directly on the canvas, performance was considerably better. I could display 300 rows by 10 columns and the initial display was almost instantaneous. Performance was still acceptable when I had 1000 rows with 100 columns, taking maybe 2-3 seconds to start up.
So, for a large number of cells you're better off drawing them directly on the canvas. This means you'll need to calculate the height of a row yourself, and also do a little math for the columns -- either use fixed width columns or keep track of the widest and then adjust the coordinates accordingly.
随着事物变大，网格几何管理器会遇到问题；它不是为处理大量子窗口而设计的（即，任何您想要扩展到超出您无需滚动即可轻松拥有的范围的子窗口）。相反，您正在寻找 TkTable。这可以扩展到处理非常大的表格数据。
The grid geometry manager runs into problems as things get larger; it's not designed for dealing with very large numbers of subwindows (i.e., anything where you'd want to scale beyond what you can comfortably have without scrolling). Instead, you're looking for TkTable. That can scale up to handling very large tabular data.