HIToolbar Crash Situation
By Thom McGrath on
One of my users of HIToolbar has brought a crash to my attention, forwarded from one of his users. I'm at a loss for the reason, and the developer himself has been unable to replicate the crash. However, we do have a crash log from the user. If anything, this article should be to make other users of HIToolbar aware of the situation, if not solve the problem.
The developer in question is Tom (no last name provided) of Thermo Global Nuclear War . I asked his permission to post the situation to this blog, and he agreed. You can contact him using his contact form.
The original message I received was this:
I'm using HIToolbar 1.1.1 and I'm having a few problems with it.
Firstly, in my application, my preferences file is called com.thermoglobalnuclearwar.friendz.com. But when I add the toolbar classes to the window (everything works perfectly) and then quit, HIToolbar creates another preference file called com.thermglobalnuclearwar.friendz.com. the "o" is missing from thermo. I can't find anywhere in my application where I have spelt it wrong. I've gone over it many times. What's going on.
My second problem is that, while I'm on a G5, people using Intel machines cannot get the toolbar to work. It displays, but the items just don't do anything. The site says it's universal.. Is it?
I told him that I have tested this using both my PPC Mac Mini and Intel MacBook. Both work flawlessly, and I have never heard of any issue from my users. So he kindly sent me the following crash log, which I have truncated:
Thread 0 Crashed: 0 com.apple.HIToolbox 0x93080389 HIToolbar::CopySelectableItemIdentifiers() + 23 1 com.apple.HIToolbox 0x930832fb _HIToolbarCopySelectableIdentifiers + 31 2 com.apple.HIToolbox 0x92ea2fd5 HIToolbarItemView::ControlHitSelf(OpaqueControlRef*, short, unsigned long) + 103 3 com.apple.HIToolbox 0x92e010b8 HIView::EventHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 9144 4 com.apple.HIToolbox 0x92ddb537 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1093 5 com.apple.HIToolbox 0x92ddabdc SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 304 6 com.apple.HIToolbox 0x92de1fbc SendEventToEventTarget + 56 7 com.apple.HIToolbox 0x92e956a5 SendControlHit(HIView*, short, unsigned long) + 187 8 com.apple.HIToolbox 0x92e95596 HIView::NotifyControlHit(short, unsigned long) + 34 9 com.apple.HIToolbox 0x92e9ee38 HIView::ClickInternal(CGPoint const&, unsigned long, void (*)(OpaqueControlRef*, short), OpaqueEventRef*, bool) + 270 10 com.apple.HIToolbox 0x92e7a045 HIView::ClickSelf(OpaqueEventRef*) + 371 11 com.apple.HIToolbox 0x92dff652 HIView::EventHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 2386 12 com.apple.HIToolbox 0x92ddb537 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1093 13 com.apple.HIToolbox 0x92ddabdc SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 304 14 com.apple.HIToolbox 0x92de1fbc SendEventToEventTarget + 56 15 com.apple.HIToolbox 0x92e79d6f HIView::Click(OpaqueEventRef*) + 329
Not being an expert on crash logs, I simply looked at line 0, and noticed the call to HIToolbar::CopySelectableItemIdentifiers. I asked wether or not he was trying to use an empty identifier in this event, and although received no definitive yes or no, I believe he would have checked that and said something like "oh, of course, thanks" if that were the issue.
So we're at a loss now. I'm not quite sure what the problem could be. If anybody has an idea, feel free to get in touch with me, either through comments or using my email address listed with the author name of this entry.