Hi, Using the cap approach sounds good, but it's way to much work for these 5 apps I have to modify. It's all a bit mute now anyway. since I've just come out of a meeting and, because of all this Button nonsense (as well as other UI issues) we are not going to support iOS 7 for these Apps for a while if ever. They work find on iOS 6 and the Users won't be upgrading their pads to iOS 7, so it really doesn't matter. I'm pleased because I was dreading having to change a *lot* of "Button" code just to get back what we already had a few days ago under iOS 6!
Thanks a lot for everyone's time and at least I know how to do it now if we ever need to. All the Best Dave On 4 Oct 2013, at 00:52, Alex Zavatone <z...@mac.com> wrote: > The cap approach is something that's supported with a standard button and it > works really well. > > FWIW, I've been using it since 1998 with PNGs. Basically, the approach is > that you have a PNG graphic that is nicely antialiased and alpha channeled. > It consists of a button's left and right caps and a middle region that is a > stretchable column of pixels. When making the button, and assigning the > graphic, you define how many pixels are used in the left and right caps and > the middle is taken from the middle column of pixels. > > Make sure to have a graphic that consists of the left, right and middle for > each state of the button, such as active and clickable/tappable, active/over, > down, selected, disabled. > > It works like a charm. I've even got some of these PNGs if you need to try > it out on a UIButton. > > There are more advanced ways to make buttons with gradients by creating the > image in code, but just creating a set of capped images for the button > graphics is a pretty easy way to go. > > Lots of how some frameworks are implemented might not make sense and might > suck to you. You'll find that the frameworks are how the frameworks are, > like it or not. > > I'm sure that there are loads of custom button classes out there that you can > find on Github or StackExchange that create buttons in code the way you > expect. Whether something like this should be in the UIButton class or not, > well - it probably should be, but it isn't and it's up to us to see how to > deal with that. > > Might be a good little project for a class extension category for you to > build out. > > > On Oct 3, 2013, at 5:39 PM, Dave wrote: > >> >> On 3 Oct 2013, at 21:13, Fritz Anderson <fri...@manoverboard.org> wrote: >> >>> On 3 Oct 2013, at 2:09 PM, Dave <d...@looktowindward.com> wrote: >>> >>>> Sorry, should have said, without using an Image. >>> >>> Why? Images are how this sort of thing gets done. Anything else is a stunt, >>> unless you have some constraint you're not telling us about. >>> >>> (You're familiar with -[UIImage resizableImageWithCapInsets:] and related >>> API?) >>> >>> I suppose (off the top of my head, not even "written in Mail"), you could >>> have a UIButton subclass that returns a CALayer subclass of your devising >>> from +layerClass, and have your layer set borders and corner-rounding. >> >> I really don't want to make lots of images just for this and to be honest, >> if a Framework doesn't support an Industry Standard "Button" out of the box, >> then, it sucks! >> >> Thanks >> Dave >> >> >> _______________________________________________ >> >> 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/zav%40mac.com >> >> This email sent to z...@mac.com > _______________________________________________ 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
