From: Michael K. <mi...@mu...> - 2008-07-19 19:57:37
|
I tracked down this small bug this morning, but I'm not sure whether it should be considered a TreeCtrl bug or a Tk bug: Under Aqua, the header for the column that's active for sorting is normally shown with a blue background. TreeCtrl uses the isActive field in the TreeCtrl struct to determine whether to use the kThemeStateActive or kThemeStateInactive state to get this effect when appropriate. isActive is initialized to 0 at creation time and set to 1 or 0 in response to ActivateNotify and DeactivateNotify events. However, Tk only sends such events to windows that are mapped. If you stick a TreeCtrl inside a Tile notebook page that's not the first page in the notebook, the TreeCtrl won't be mapped until the page is raised, and so the TreeCtrl will never receive the ActivateNotify event until the toplevel it's in is deactivated and then reactivated by switching windows, thus until you do so the column header won't display with the correct blue background. The culprit is TkQueueEventForAllChildren() (generic/tkEvent.c), which returns if the window isn't mapped. If ActivateNotify/DeactivateNotify events are allowed through there to unmapped windows, then it works. I'm not sure if there are any unintended consequences of doing so (of the "other code/packages only expect to receive these events if mapped" variety), though. It may be that what TreeCtrl should do instead is not rely on getting an ActivateNotify event to set the state initially, but rather check to see if it's being created in the active toplevel. I don't know if that's possible or feasible, however. Since I'm not sure whether this would be considered TreeCtrl's bug or Tk's bug, I'm not sure which to open a bug against. Any thoughts? -- Michael Kirkham President & CEO Muonics, Inc. http://www.muonics.com/ |