Menu
▾
▴
[Tcl-bugs] [ tktoolkit-Bugs-223112 ] tkMenuFind doesn't locate cloned menubars
|
From: SourceForge.net <no...@so...> - 2003-11-12 23:35:20
|
Bugs item #223112, was opened at 2000-11-21 18:14 Message generated for change (Settings changed) made by dgp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=223112&group_id=12997 Category: 10. Generic Menus Group: obsolete: 8.2.2 Status: Open Resolution: None Priority: 7 Submitted By: Rick Brownrigg (brownrigg) >Assigned to: Donal K. Fellows (dkf) Summary: tkMenuFind doesn't locate cloned menubars Initial Comment: [I hesitate to report this, but I'll be damned if I can make it work. Nor can I find a related bug report]. Consider the following simple example: % wish canvas .c -width 256 -height 256 pack .c bind .c <KeyPress-a> {puts "Is RB out of line here?"} Pressing the "a" key does not invoke the callback script, under RH 6.2, Tcl/Tk 8.2.2. More elaborate keyboard bindings also fail. I have been unable to make *any* keyboard-oriented events work under this environment, to include "underlined" menu items, menu accelerator commands, etc. Could be indicative of a larger problem. Have been unable to verify other platforms; same phenomena occurs on an IRIX 6.5 client, but the constant is still the stock RH 6.2 X server (XFree86 3.3.??). I appreciate any feedback, even if it goes something like: "Look nimrod, you're obviously confused, and the proper way to accomplish this is...." ---------------------------------------------------------------------- Comment By: Rick Brownrigg (brownrigg) Date: 2000-12-01 12:06 Message: I don't want to beat this into oblivion, but I feel I should make one final comment... I wouldn't characterize this as a documentation bug. Afterall, "menubar" is a valid value to the -type clause on the menu command. Minimally, it should be removed, in addition to being reflected in the docs. On the otherhand, the whole verbage on clones makes it sound like "menubar" is entirely appropriate, if not necessary. As I mentioned previously, the usage "-type menubar" is widely documented (all my texts are in the other office, but if anyone cares, I can provide citations). Removing the option potentially breaks existing code. Keeping it potentially causes other people to stumble over the same problem I've reported here, causing them grief, lost time, possibly re-reporting, etc. I'm clearly not the one to say, but I would recommend the patch I suggested previously to the library script "menu.tcl". Its simple, and consistent with other procs in that script. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2000-11-30 08:56 Message: So this is really a documentation bug? OK, will mark it as such... ---------------------------------------------------------------------- Comment By: Rick Brownrigg (brownrigg) Date: 2000-11-29 13:23 Message: I *think* I have the appropriate fix... tkMenuFind is indeed finding the original menu, not the clone. In fact, it simply finds the first child of the toplevel that has class=Menu and type=menubar, which happens to be the original. I studied the menu creation and cloning codes in quite some detail. They are spread out across tkMenu.c and tearoff.tcl. The clone in fact gets created when the menu is installed as the menu-bar: e.g.: . configure -menu $myMenuBar The code ensures that the clone of $myMenuBar is of type menubar, regardless of what $myMenuBar's type is. As to how/why $myMenuBar gets the wrong type? In my script, there's the line: set mbar [menu .m -type menubar] I discovered (knowing what I know now), that if I leave the "-type" clause off, things work as expected! Unfortunately, I'm not sure that's the end of it. I've seen in several different books declaring that the so-called "new" method of creating menus is exactly as my test script does, specifically using the "-type menubar" clause. Presuming that this bit of ill-advise is wide spread, then others are sure to stumble across this problem too, etc. I'm not sure what problems the whole cloning mechanisms were designed to solve, aside from tear-off menus, but I have to believe the problems were real. The "menu.tcl" library script has numerous tests for "viewable" spread throughout it, no doubt a result of cloning issues. I would humbly suggest the following patch to that script, to avoid widespread problems resulting from the sort of bad-usage in my example. In proc tkMenuFind, I'd recommend adding the following lines into the script: proc tkMenuFind {w char} { ... if {[string equal [winfo class $child] "Menu"] && [string equal [$child cget -type] "menubar"]} { #### BEGIN PATCH #### if {![winfo viewable $child]} { continue } #### END PATCH #### if {[string equal $char ""]} { return $child ... This of course causes the search to skip the original menu, and the visible clone is later found. It is consistent with other places in the code, and not a terribly gross hack. I've tested this patch locally, and my original script works as expected, including fixing the "F10" problem (posting the first menu). Finally, to add one more comment to this already long note, my original postings have mentioned an inability to get accelerators to work. I now believe that was due to a misunderstanding on my part. I had (mistakenly) thought the -accelerator mechanism took care of creating the approp. bindings, but I now see that it only modifies the "appearance" of the menu item, and the bindings must be created explicitly by the programmer. Hope this has been helpful. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2000-11-29 04:39 Message: It seems that the problem is that tkMenuFind selects the window that the menubar was cloned from, and not the window that forms the actual menu bar. You can work around this by making the menu you are generating the menubar from not a (direct) child of any toplevel that it is serving as a menubar for, but this is a grotty way to do it. It would be more productive to try to find out why the non-menubar is getting its type set to "menubar" (which is what is causing the problems in the first place.) ---------------------------------------------------------------------- Comment By: Rick Brownrigg (brownrigg) Date: 2000-11-28 12:36 Message: Indeed, the focus command takes care of the problem exemplified here. Thanks, and apologies for what turned out to be my oversight. In the larger context, I still have been unable to make keyboard menu accelerators and shortcuts work, and believe this to be a persistent problem (referenced at least in #120377, which is marked closed). This problem is present in 8.2.2 and 8.3.2. Here's a modified version of original testscript: set mbar [menu .m -type menubar] set m [menu $mbar.m1 ] $m add command -label "Open..." -underline 0 -command {puts "Open..."} -accelerator "Ctrl-O" $mbar add cascade -label "File" -menu $m -underline 0 set m [menu $mbar.m2 -type tearoff] $m add command -label "Foo..." -underline 0 -command {puts "Foo..."} -accelerator "Ctrl-F" $mbar add cascade -label "Edit" -menu $m -underline 0 . configure -menu $mbar canvas .c -width 256 -height 256 pack .c bind .c <KeyPress-a> {puts "Is RB out of line here?"} focus .c The Keypress-A is now detected. With or without the canvas present, the "Alt-F" (or Alt-E), which should post the File (Edit) menu, produces the following error: grab failed: window not viewable while executing "grab -global $w" (procedure "tkTraverseToMenu" line 21) invoked from within "tkTraverseToMenu .c f" (command bound to event) The accelerators "Ctrl-O", etc. are never detected either. Note the following results at this point: % winfo children . .m .#m .c % winfo viewable .m 0 % winfo viewable .#m 1 This suggest to me that the problem is the viewable property of the clone is not propogated to the original menu. In the proposed fix for bug #120377, it is suggested that the problem is "unguarded grabs", and thus several places are wrapped with something like "if {[winfo viewable $w]...} {... ; grab -global $w; ...}" I have to wonder if the menu properly reflected the state of its clone, then *all* of these sorts of grab problems would be resolved. Alas, I was unable to understand the cloning mechanisms enough to produce a patch, assuming this analysis is correct. ---------------------------------------------------------------------- Comment By: Brent B. Welch (welch) Date: 2000-11-21 18:41 Message: Add the following line to your test script to ensure that the canvas gets the keyboard events: focus .c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=223112&group_id=12997 |