Re: comboBoxSelectionDidChange not called
Re: comboBoxSelectionDidChange not called
- Subject: Re: comboBoxSelectionDidChange not called
- From: Scott Ribe <email@hidden>
- Date: Tue, 31 Dec 2013 14:39:17 -0700
On Dec 30, 2013, at 2:39 PM, Quincey Morris <email@hidden> wrote:
> On Dec 30, 2013, at 13:06 , Scott Ribe <email@hidden> wrote:
>
>> Does anyone have any further suggestion for me???
>
> The release notes for 10.6 say this:
>
>> For apps linked on or after SnowLeopard, if a combo box is configured to send action on enter only, then it will not send its action when a selection is made from the drop down, either with the mouse or the keyboard. Only enter in the text field part of the combo box will send the action.
>
> One of your previous posts said:
>
>> The target action for a selection change *is* called.
>
> which suggests to me that your combo box is *not* configured to send its action on enter only.
Correct. And anyway, this thing was linked on and working on Snow Leopard for multiple years now.
> That doesn’t lead anything directly, but it makes me wonder (if the missing delegate method isn't just a 10.9 bug) whether there’s an intent to send the action or the delegate method but not both, for apps linked on 10.9 or later. Yes, that’s a lame suggestion, I know, but it’s all I can come up with.
>
> Does ‘comboBoxSelectionIsChanging:’ get called?
>
> If you can’t work around this (e.g. your action method can check if the selected item is the same as the text field string, and do whatever the missing delegate call was supposed to do), and it’s a small headache to you, then submit a bug report and see what comes back. If it’s a big headache to you, sounds like a good candidate for a TSI.
>
Thanks for the thoughtful response. Unfortunately, "been there done that". It's always a question of balance how much to post when I'm days into debugging this kind of mystery--I try to avoid the novel-length version unless necessary ;-)
Anyway, here's things I tried which did not work:
- Notice that NSComboBoxDelegate is now a formal protocol, declare my class to implement it.
- Implement the rest of the protocol: comboBoxSelectionIsChanging, comboBoxWillDismiss & comboBoxWillPopUp (comboBoxSelectionIsChanging was not called either).
- Having the same thought as you about maybe it will only "do 1 thing", get rid of the target/action.
- Register to listen for notifications from the combo box (neither NSComboBoxSelectionIsChangingNotification nor NSComboBoxSelectionDidChangeNotification were sent).
After all that, I implemented a workaround that was really pretty easy because of the way these particular controls and delegates are set up: add awakeFromNib to the delegate to get the combo box's target/action, save them, and substitute itself; add the target method to do what the didChange should have done, then call the original target/action. Boom, problem solved.
Subsequent to that, I switched the base SDK from 10.6 to 10.7, took care of eliminating some obsolete code, switched back to 10.6 as the base SDK, and also did some testing in different OS versions. And I noticed that now the code was running twice, once via the normal didChange delegate method, and once via my redirected target hack. So I assumed, incorrectly, that switching the SDK back and forth had fixed it--forgetting about rebuilding on 10.8.
So I took out the workaround code. Then noticed it was broken again. And finally proved that it works in 10.7-10.9 if built on 10.8, but fails on 10.7 & 10.8 if built on 10.9 (regardless of whether the base SDK is 10.6 or 10.7 or even 10.8).
Since then I have tried:
- De-selecting "Link With Standard Libraries" and specifying the libraries individually.
- Re-building the project from scratch in Xcode 5.0.2. (This project started life in XCode 2.)
- Separating the data source & delegate into two separate objects.
None of that made a difference.
Between this and the "cannot successfully code sign an app that links the security framework" problem, I'm really fed up with developing on 10.9!
--
Scott Ribe
email@hidden
http://www.elevated-dev.com/
(303) 722-0567 voice
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden