[Tcl-bugs] [ tktoolkit-Bugs-1068293 ] TkAqua: CompleteIdlers() is never called for menu

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

bar menus
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"

Bugs item #1068293, was opened at 2004-11-17 13:54
Message generated for change (Comment added) made by reowen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1068293&group_id=12997

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 11. Aqua Menus
Group: obsolete: 8.4.7
Status: Open
Resolution: None
Priority: 7
Submitted By: Michael Kirkham (muonics)
Assigned to: Jim Ingham (wolfsuit)
Summary: TkAqua: CompleteIdlers() is never called for menu
bar menus

Initial Comment:
It appears that a menu's -postcommand on Aqua is not
called until after the menu is posted, or else if it
makes changes to the menu they are not reflected until
the next time the menu is posted.  A short example:

menu .m
.m add cascade -label Foo -menu .m.f
menu .m.f -postcommand Foo
.m.f add command -label "(Empty)"

set i 1

proc Foo {} {
        .m.f delete 0 end
        .m.f add command -label "$::i - Foo1"
        .m.f add command -label "$::i - Foo2"
        .m.f add command -label "$::i - Foo3"
        .m.f add command -label "$::i - Foo4"
        incr ::i
}

. config -menu .m

Each time the menu is posted, its contents will change
to some so the number indicates how many times it's
been posted.  It's expected that the -first- time it's
posted it will show "1 - Foo1" etc.  Instead it shows
"(Empty)".  It's expected that the second time it's
posted it will show "2 - Foo1" etc.  Instead it shows
"1 - Foo1" etc.

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

Comment By: Russell Owen (reowen)
Date: 2005-09-22 16:28

Message:
Logged In: YES 
user_id=431773

A presumably-related issue:
If a pull-down menu contains submenus and if postcommand is used to 
update the submenus (at least if it's used to delete all entries from the 
submenu and add new ones) then the submenus stop working. The 
submenu entries exist and are not grayed out, but they do nothing.

The only way I've found to make the pull-down menu work again is to 
bring a different toplevel to the top or bring a different application to the 
top. Then all is well. But it's a bizarre hackaround and not something one 
wants to ask users to do.

A variant of this hack that sort of works in code is:
Whenever a submenu is changed, do the following:
- create a toplevel
- update idletasks
- destroy the toplevel
the submenus will fail the first time the pull-down menu is used, but the 
pull-down menu will work after that.

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

Comment By: Michael Kirkham (muonics)
Date: 2004-11-17 19:05

Message:
Logged In: YES 
user_id=498198

After noticing that the problem doesn't appear for tk_popup
posted menus and sprinkling printf()s here and there to see
what's going on, I've isolated the problem and have a
workaround, but I'm not sure about a proper fix.

It turns out that CompleteIdlers() is never called for menu
bar menus.  The reconfiguration is done in the postcommand
and a couple idle callbacks are set up to reconfigure the
menus via Tcl_DoWhenIdle(ReconfigureMacintoshMenu, ..), in
this case in TkpDestroyMenuEntry(), but are not called until
the menu unposted.  

Adding an "update idletasks" to the end of the postcommand
proc that reconfigures the menu works around the problem. 
It would seem that a call to CompleteIdlers() needs to be
made some time after TkPreprocessMenu() is called; I tried
doing it there before returning and it only catches the
first of the two ReconfigureMacintoshMenu() callbacks; the
other seems to get added some time after TkPreprocessMenu()
returns.

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

Comment By: Michael Kirkham (muonics)
Date: 2004-11-17 16:21

Message:
Logged In: YES 
user_id=498198

Okay, it turns out the post command actually *is* getting
called, but the changes to the menus aren't getting applied
until the next post.  Adding to the top of the post command:

puts "POSTED - $::i"

Shows that the command is indeed called, but the number
printed is one less than what's displayed in the actual menu
entries.  So maybe an issue with CompleteIdlers()?

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

Comment By: Michael Kirkham (muonics)
Date: 2004-11-17 15:18

Message:
Logged In: YES 
user_id=498198

Possibly related or partly responsible: in trying to track
down the source of the problem, I tried the following script
that periodically switches the state of a menu entry:

menu .m
.m add cascade -label Foo -menu .m.f
menu .m.f
.m.f add command -label Bar

set i 0
proc toggle {} {
    if {($::i % 2) == 0} {
         set state normal
    } else {
         set state disabled
    }

    .m.f entryconfig Bar -state $state
    puts $state
    after 1000 toggle
}

. config -menu .m.f
after 1000 toggle

I run this and click on the Foo menu.  On Unix (X/Windows)
and Windows, the Bar entry periodically switches back and
forth between states and "normal" and "disabled" are written
to the console.  Under Aqua, "normal" and "disabled" are
periodically written to the console only while the menu is
unposted.  As soon as I click on the menu the output stops
and the entry does not toggle.  It resumes once the menu is
unposted.

I'm almost led to believe that the post command is getting
triggered when the menu is posted but actually gets blocked
until the menu is unposted, but as far as I can tell so far
in reading the source code it's not called as a n idle task
or anything, so I don't see why that would be the case.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=1068293&group_id=12997