today's AppKit gymnastics:
as i discovered yesterday, removing the border or bezel of the NSSearchField leads to the search text covering the cancel/clear button.
so, i dutifully hid the internal button, created my own and positioned it correctly. fine.
but telling the searchField that it's new value an empty string (even with KVO or using the built-in stringValue method) superficially works -- but leads to inconsistent values between the controllers and views. yuck.
why, you ask?
1/…
=> More informations about this toot | More toots from isaiah@mastodon.social
if you programatically change the text in an NSSearchField, the search field will bafflingly not update the stringValue binding.
i don't know why, it seems like it would actually take work to do.
after hunting around i could not find any way to nudge it into updating things.
but the search field relies on an NSTextView field editor, and I know how to kick that into gear and it works. yeah!
just call the textDidChange: method manually it will trigger the binding to do the expected stuff.
2/…
=> More informations about this toot | More toots from isaiah@mastodon.social
the textDidChange: needs be called with the notification from the NSTextView's NSText object
the notification should have the text did change notification name, the field editor object, and according to the docs, no userInfo dict.
in practice however, the NSText object always adds itself to the userInfo dictionary with the key "NSFieldEdiotr" -- furthermore leaving out this value will lead to an unknown selector exception.
3/3
=> More informations about this toot | More toots from isaiah@mastodon.social
one last thing…
if you happen to know about AppKit and NSSearchField or why NSTextField's don't update their bindings please let me know.
i would love love LOVE to delete this hack and eliminate the NSSearchField subclass from this little Open Quickly UI.
i have zero qualms about eating crow here and finding out i'm doing everything wrong.
=> More informations about this toot | More toots from isaiah@mastodon.social
@isaiah It’s been a long time since I’ve used bindings, but I believe it’s by design that programmatically setting the value doesn’t fire the binding. It’s like without bindings, where changing the state of a control doesn’t fire the action. Probably you want to set the value on the model object and have the view update via KVO?
=> More informations about this toot | More toots from mjtsai@mastodon.social
@mjtsai that's interesting. i hadn't even considered that possibility. thanks! i will have to test out the theory.
i must admit to not using bindings very often anymore either. it seemed like a clean way to have a bidirectional update without risking a retain cycle.
but perhaps it's time to just move on from bindings now for good.
=> More informations about this toot | More toots from isaiah@mastodon.social
@mjtsai confirmed. you were exactly right about the binding.
updating a view's value programmatically -- even via KVO -- does not necessarily trigger the binding.
i can't believe i've never noticed that before now. never stop learning, i guess. :-)
you don't happen to have any secret info on how to remove the border of an NSSearchField do you. 😜
=> More informations about this toot | More toots from isaiah@mastodon.social
@isaiah @mjtsai Is there a particular reason you want to start with NSSearchField? I think you could avoid those issues starting with a NSTextField subclass.
=> More informations about this toot | More toots from agiletortoise@mastodon.social
@agiletortoise @mjtsai no. not especially.
i guess it is kinda nice that i can link saved searches in this field with others via the built-in behaviors.
and as a rule of thumb i usually try to use the obvious control whenever possible just in case there's some underlying accessibility stuff -- there usually is.
but not really. no.
when showing someone else yesterday i mentioned that if i did it again, i'd just build up the view from basic components. i kind of had to anyway.
=> More informations about this toot | More toots from isaiah@mastodon.social
@isaiah @mjtsai I’ve been down the same road with NSTokenField, and ending up building my own because the tradeoff got too weird.
=> More informations about this toot | More toots from agiletortoise@mastodon.social
@isaiah It’s hard to customize controls with bindings because they don’t expose the binder classes. Like, if you were writing your own search field, the view would be able to see what it was bound to, so you could make it update the model to clear the string (no need to go through the field editor). Maybe you can override -bind:toObject:withKeyPath:options: and stash the binding info so that you can call it later?
=> More informations about this toot | More toots from mjtsai@mastodon.social
@isaiah Actually, it’s coming back to me, I think you can just call infoForBinding: to get the model info from within the view if you are trying to keep all the logic isolated within your subclass.
=> More informations about this toot | More toots from mjtsai@mastodon.social
@mjtsai oh… i think i've used that before to get access to the model from the view.
i'll give it a shot.
=> More informations about this toot | More toots from isaiah@mastodon.social
@isaiah No, but have you tried overriding -searchTextBounds to fix the text position, if that’s the core problem that you’re trying to solve? Then maybe you could use the standard button.
=> More informations about this toot | More toots from mjtsai@mastodon.social
@mjtsai yes. searchTextBounds works great so long as the border is there -- but seems to be ignored once the border or bezel are removed.
you can see it happen to the default layout just by unchecking the "Bordered" box in IB.
the result is that all the cells just pile up on top of each other.
https://yourhead.com/appcast/video/searchfieldbug.gif
=> More informations about this toot | More toots from isaiah@mastodon.social This content has been proxied by September (ba2dc).Proxy Information
text/gemini