[Tcl-bugs] [Bug #123112] tkMenuFind doesn't locate cloned menubars

[<no...@so...>]

Bug #123112, was updated on 2000-Nov-21 15:14
Here is a current snapshot of the bug.

Project: Tk Toolkit
Category: Docs
Status: Open
Resolution: None
Bug Group: 8.2.2
Priority: 7
Summary: tkMenuFind doesn't locate cloned menubars

Details: [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...."



Follow-Ups:

Date: 2000-Nov-21 15:41
By: welch

Comment:
Add the following line to your test script to ensure that the canvas gets the keyboard events:

focus .c

-------------------------------------------------------

Date: 2000-Nov-28 09:36
By: brownrigg

Comment:
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.


-------------------------------------------------------

Date: 2000-Nov-29 01:39
By: dkf

Comment:
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.)
-------------------------------------------------------

Date: 2000-Nov-29 10:23
By: brownrigg

Comment:
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.

-------------------------------------------------------

Date: 2000-Nov-30 05:56
By: dkf

Comment:
So this is really a documentation bug?  OK, will mark it as such...
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=123112&group_id=12997