From: Michael Kirkham <mikek@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
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"
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?
President & CEO