I wouldn't say that I was using it incorrectly since the user also can change the segmented control, but when the form fails to validate, it shifts to the unfinished section programmatically.
I wondered if someone would call me on the fact that they all fall under the UIControlEvents which are all essentially touch related. Whenever I write custom controls, I elect to sent actions for the value changed control event (where the control has a value, obviously) on programmatic changes. I understand that it might not be reasonable to expect that from UIKit. I've never had an issue with needing to be concerned about infinite loops since the desired behavior was always to eliminate code duplication by using the same function for both touch and programmatic changes.. There's not really an issue with just calling the function I registered, but it feels wrong to call a method set up specifically to be called by the system. It triggers the same mental red flags as calling layoutSubviews (rather than layoutIfNeeded) or something else that is reserved for the system to call. Thanks for the feedback. -- Daniel Blakemore Pixio Software On Wed, Oct 15, 2014 at 10:12 AM, Scott Ribe <scott_r...@elevated-dev.com> wrote: > On Oct 15, 2014, at 10:00 AM, Keary Suska <cocoa-...@esoteritech.com> > wrote: > > > It is also useful to know that "event" handling almost exclusively > relate to device input, not to programmatic changes. I.e., setting the > value of a control is not an "event" so no event handling will get > involved. You certainly could cause an event to programmatically fire… > > Also, in general, there's a good reason for this behavior. If events were > to fire on programmatic changes, then you'd have ALL SORTS of infinite > loops triggered when responding to input events, each one of which would > require you to set some flag before changing a control's state, so that the > event handler for that event would know *not* to propagate changes. > > It would be an absolute nightmare to code to begin with, and even worse to > maintain... > > -- > Scott Ribe > scott_r...@elevated-dev.com > http://www.elevated-dev.com/ > (303) 722-0567 voice > > > > > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
