“wait_window"是什么意思?方法呢?

问题描述

似乎调用这个方法的对象等待作为参数传递的窗口被销毁，然后继续它自己的循环...

从Misc类的文档字符串中，我们可以观察到:

<块引用>

def wait_window(self, window=None):"""等到一个WIDGET被销毁.如果没有给出参数，则使用 self."""

乍一看，这个方法似乎可以制作一个 Toplevel 模态，但事实并非如此.要制作 Toplevel 模态，我们必须使用 grab_set() 方法.

我看到了其他解释:

<块引用>

wait_window 似乎在给定的小部件作为参数传递之前不会返回不会被破坏.

从另一个地方:

<块引用>

wait_window(widget) - 创建一个等待给定的本地事件要销毁的小部件.此循环不会影响应用程序的主循环.

根据 effbot 文档，我们有:

<块引用>

wait_window 进入本地事件循环，直到给定的窗口被销毁(通过 destroy 方法，或显式地通过窗口管理器):

widget.wait_window(window)

window 等待 window(本身)究竟意味着什么?

似乎在调用 wait_window 之后的代码不会执行，直到传递给同一方法的窗口没有被破坏.在下面的工作示例中，我们可以看到刚才所说的证明:

从 tkinter 导入 *def on_win_request(父):对话框 = 顶层()parent.wait_window(对话框)# 只有在对话框"被销毁时才执行print("小事件循环完成！")r = Tk()b = Button(r, text='New Window', command=lambda: on_win_request(r))b.pack()b2 = Button(r, text='Hello!', command=lambda: print("hello"))b2.pack()r.mainloop()

"Mini-event loop finished!" 只会在名为 dialog 的本地 Toplevel 小部件被销毁时打印.

那么，究竟应该在什么实际情况下使用这种方法呢?

解决方案

就像文档中所说的，它一直等到给定的窗口被销毁.它主要用于模式弹出窗口，尽管它本身并不构成窗口模式.在目标窗口被销毁之前，对该函数的调用不会返回.要创建模态窗口，您还必须进行抓取.

最常见的用途是创建一个 Toplevel 的实例，用小部件填充该窗口，然后等待窗口关闭，然后再执行其他操作.在等待期间，tkinter 能够继续正常处理事件.

例如，您可以禁用(或推迟创建)主 GUI，弹出服务条款"通知，并等待用户确认服务条款、版权、许可等.一旦窗口被销毁后，您可以完成初始化，或启用一些小部件等.

标准文件对话框就是一个很好的例子:你弹出对话框，然后你的代码等待用户选择一个文件，然后它使用返回的文件名.在内部，对话框的实现使用 wait_window 以便在对话框关闭之前它不会返回.

It seems that the object that calls this method waits for the window passed as parameter to be destroyed before continue with its own loop...

From the doc strings of the Misc class, we can observe:

def wait_window(self, window=None):
    """Wait until a WIDGET is destroyed.
    If no parameter is given self is used."""

At first glance, it seems like this method can make a Toplevel modal, but this is not true. To make a Toplevel modal, we have to use the grab_set() method.

I have see around other explanations:

wait_window seems to not return until the given widget passed as parameter is not destroyed.

From another place:

wait_window(widget) - Creates a local event that waits for the given widget to be destroyed. This loop doesn't affect the application's mainloop.

From the effbot documentation, we have:

The wait_window enters a local event loop, and doesn’t return until the given window is destroyed (either via the destroy method, or explicitly via the window manager):

widget.wait_window(window)

What exactly means for a window to wait for window (itself)?

It seems that the code that comes after the call to wait_window is not executed until the window passed to the same method is not destroyed. In the following working example, we can see a proof on what just said:

from tkinter import *

def on_win_request(parent):
    dialog = Toplevel()
    parent.wait_window(dialog)
    # executed only when "dialog" is destroyed
    print("Mini-event loop finished!")

r = Tk()
b = Button(r, text='New Window', command=lambda: on_win_request(r))
b.pack()
b2 = Button(r, text='Hello!', command=lambda: print("hello"))
b2.pack()
r.mainloop()

"Mini-event loop finished!" will be printed only when the local Toplevel widget called dialog is destroyed.

So, in exactly what real circumstances should I use this method?

解决方案

Like the documentation states, it waits until the given window is destroyed. It is mostly used for modal popups, though it doesn't itself make a window modal. The call to the function simply doesn't return until the target window is destroyed To make a modal window you have to do a grab as well.

The most common use is to create an instance of Toplevel, populate that window with widgets, then wait for the window to be dismissed before doing some other action. While it is waiting, tkinter is able to continue to process events as normal.

For instance, you can disable (or defer creation of) the main GUI, pop up a "terms of service" notice, and wait for the user to acknowledge the terms of service, copyright, license, etc. Once the window is destroyed you can then finish initialization, or enable some widgets, etc.

The standard file dialog is a perfect example: you pop up the dialog, then your code waits for the user to pick a file, then it uses the filename that was returned. Internally, the implementation of the dialog uses wait_window so that it doesn't return until the dialog is dismissed.