I’ve got an NSTabView and I need to detect when the tab view is changed (not just clicked), so I can run some handlers. At first, I thought I’d connect an action to the tab view, but IB won’t let me do that. Then I bound a property to the tab views labels and thought I would just detect when the property is updated, but then I realized that I don’t know how to do, or if it’s even possible. So I’m hoping for some help with two questions.
A more general question - Is it possible to detect when a bound property is updated via a gui element update, and if so how? Maybe I’m trying to do too much with bindings, but I think that I’ve fallen in love, and this seems like it could be handy in many different situations.
More specifically, Is there a better way to do what I need to do with detecting tabs changing?
I feel like I’m overlooking something real obvious. Thanks in advance for any help.
Now I’m a bit confused as to what is going on with setters and getters in ASOC. I tried the program on page 100 of your book with a couple of alternate statements thrown in:
property parent : class "NSObject"
property someProperty : missing value
log "setSomeProperty_ has been called with " & (someValue as text)
set someProperty to someValue
--set my someProperty to someValue
log "Between calls"
If I run it as above, I get this in the log:
If I run it with the statement with the “my” added, nothing changes, but if I use the cocoa like statement, setSomeProperty_(someValue) with or without a “my” in front of it, I get “setSomeProperty_ has been called with Hello” over and over until I get a stack overflow. The discussion on page 99 of your book seems to say that those 2 commented out statements should be equivalent. What gives, am I not reading this right?
After Edit: Actually, I see that I changed the two set statements in the applicationWillFinishLaunching handler to the cocoa like ones too --if I run the program exactly as it is in the book, I only get “Between calls” in the log.
If you use the Cocoa set_ calls, you are really just calling the handler, so doing that inside a handler of the same name is going to start an infinite loop.
The real question is why the code in the book doesn’t work, and that has me baffled. I’m sure I copied it from a sample project, but it’s certainly not doing what I thought it was. So it looks like using “set my…” results in willChangeValueForKey: and didChangeValueForKey: being called instead of set:. The setter is called if you change the value in a bound UI item, so it still works for mekronk.