サンプルコード:
package require Tk
menu .mymenu
. configure -menu .mymenu
puts [winfo children .]
Tcl 8.6 を使用すると、次のように出力されます。
.mymenu .#mymenu
.#mymenu識別子がどこから来たのか混乱しています。
.明示的に作成されたトップレベル ウィンドウ ( Tk では暗黙的に生成されたウィンドウであるため) でこの同じコードを使用すると、結果が異なることに注意してください。
package require Tk
toplevel .win
menu .win.mymenu
. configure -menu .win.mymenu
puts [winfo children .win]
これは以下を出力します:
.win.mymenu
これは適切な動作のようです。では、最初のサンプル コードで暗黙的に生成されたウィンドウの結果が異なるのはなぜでしょうか?
簡単な答え: メニューバーは実際には指定したメニューのクローンであり、そのクローンには奇妙な名前が付いています。
完全に理解するのに時間をかけたことがない理由により、メニューバーは、clone指定したメニューから (メソッドを使用して — 自分で呼び出さないでください!) 複製されます。同じメニューを複数のウィンドウに配置できるようにし、正しいネスト階層を確保することと関係があると私は信じています。また、同じメカニズムが引き裂かれたメニュー (最近ではほとんど支持されていない対話パラダイム) にも使用されます。このクローンは、クローン元のメニューとほぼすべてのプロパティを共有しますが、独自のウィジェットです。クローンは、ソース メニュー ウィジェットと、クローンが挿入されるトップレベルから派生した名前で作成されます。ターゲットのトップレベルがで、オプションに.foo.bar渡されたメニューがだった場合、クローンは-menu.grill.menu.foo.bar.#grill#menu(メニュー名のドットが#文字になります); 近くのウィジェット名の構成.は、しばしば少し特殊です。
メニューのクローン作成メカニズムを深く掘り下げすぎないことをお勧めします。それらの奇妙な名前のウィジェットは存在しないふりをします。これは、ほとんどすべての場合に非常にうまく機能します (また、プラットフォーム間の移植性も高くなります。メニュー メカニズムはプラットフォーム間で大きく異なります)。唯一の例外は、メニュー エントリに基づいてツールチップ/ステータス バーを表示する場合です。その機能を実行する自然な方法 (メニューへのバインド) は、クローンの名前をコールバックに配信することになります。回避するのは難しくありませんが、この種のことを行う場合は注意が必要です。