From: Kevin W. <kw...@co...> - 2014-07-31 03:33:38
|
Hi all, I could really use some help with a bug fix. I know what the problem is, and I have a possible fix, but it's not optimal. Last year Zbigniew Diaczyszyn reported that running "font configure" caused "bad access" crash in Tk Cocoa. The bug report is at http://sourceforge.net/p/tktoolkit/bugs/3093/, along with a sample script and a stack trace. Essentially, running "font configure TkDefaultFont -size 12" causes the crash--and it's routed, of all places, through the menu code, specifically TkpConfigureMenuEntry. After running Tk in a debugger, I found the offending line in tkMacOSXMenu.c, around line 688 or so, which was committed a couple of years ago: [item setEnabled: !(submePtr->state == ENTRY_DISABLED)]; This line is part of a loop that steps through each menu item in a submenu and determines whether to set it as enabled or grayed out. If Tk has not set the item as disabled, Cocoa is supposed to enable the menu item. This code works just fine with regular menu configuration. My guess is, however, is that configuring a font somehow causes a side effect of trying to configure the menu font as well, and the pointer to the menu state struct ("submePtr->state ") is somehow clobbered. One fix is easy: remove the reference to the pointer and just run [item setEnabled: YES]. That seems to avoid all the crashes associated with font configuration. However, the unfortunate side effect is that this also means that menu items, at least sub-menu items, will ignore state flags and will always be enabled. Alas, I haven't been able to find an actual fix to the font configuration side effect other than simply punting and setting submenu items as enabled. If anyone has any other ideas where to look, or can provide a patch, I would be mighty grateful. If not, any comments on the merits of leaving entries enabled all the time are also appreciated. Thanks, Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com |