MAK: Tk menus support tearoff by default. This can be configured either through the menu's configure command or via the option database prior to the menu's creation:
menu .m .m add cascade -label "Foo" -menu .m.foo menu .m.foo -tearoff 0 menu .m.foo add cascade -label "Bar" menu .m.foo add cascade -label "Baz"Or:
option add *Menu.tearOff 0 menu .m ...Tearoff menus can be a minor annoyance when it comes to menu entryconfigure, which can reference entries in a menu either by label or by numeric index -- the reason being that the dotted line at the top of the menu counts as an entry, and the first entry is always index 0, except for the torn-off version of the menu. There the index of the first entry is 1, unless you disable the tearoff after the fact, in which case it becomes 0. What this means is that if you reference entries by numeric index, then they will be off by 1 depending on whether or not the menu allows being torn off. It's generally safer, therefore, to reference entries by their label instead.Why would you need to reference entries at all once they're created? For starters, to disable or enable the entries based on an application's current state (disabling commands that can't safely be used until some currently running process finishes, for example) or to provide additional detail depending on other things (instead of "Save" showing "Save <filename>" when <filename> is selected in another area of the GUI, for another example). Tk provides some flexibility in referencing entries by label by using glob-style pattern matching. That is, when you say...
.m.file entryconfig Save* -state disabled...it doesn't require the label to be exact. Rather, the first entry whose label starts with "Save" will match. Even still, personally, I rather dislike the look of tearoff menus (particularly on platforms where it's not a standard appearance), so I generally disable them across the board with option add, sometimes (but not often, since inconsistency is also a pet peeve) enabling it specifically for the most frequently used menus that someone's really going to want to tearoff. In those cases, though, I usually make those functions available via toolbar buttons so that they don't need to tear the menu off.
The -tearoffcommand option complements the -tearoff option by providing control over the resulting top-level window. On the Windows platform, for example, the toplevel window should be styled as a toolwindow (see wm attributes). One might also like to make the window topmost or a transient window (see wm transient) working on behalf of its parent.Some code for this was posted in Ask, and it shall be given.
proc style_tearoff {w t} {
# Style top-level window t containing menu torn-off from w
set x [expr {[winfo pointerx $t] - [winfo width $t]/2}]
# Subtract 8 so the mouse is over the titlebar
set y [expr {[winfo pointery $t] - 8}]
wm geometry $t +$x+$y
global tcl_platform
switch -- $tcl_platform(platform) {
windows {
wm attributes $t -toolwindow true
}
}
# Put the focus on the torn-off palette, so the user can move it
focus -force $t
}When creating or configuring the tear-off menu include the option -tearoffcommand style_tearoff as well as -tearoff true.Larry Smith Menus Even Easier Incorporates control of tear-offs. As your main menu entries are enabled or disabled, tkMenuMgr insures that tear-offs - if any - are always kept in sync. Alastair Davies -- 1 March 2007
