http://helpdesk.appcelerator.net/tickets/1474
\nblain, let's discuss this one.
This could be related to this too:
\n\nhttps://appcelerator.lighthouseapp.com/projects/32238/tickets/563-i...
Possible solution is a boolean property on the imageView class,\n'stretchImage'.
\nWhen true, we'll have the imageView\nloadStretchableImmediateImage instead.
That would be great. Can you also include properties for the\nleftCapWidth and topCapHeight so they can be customized (very\nuseful in my case).
Currently image views do not use stretchable images so this does\nnot affect them. Stretchable image views should be considered a new\nfeature and a separate ticket should be made for them (and they\nshould be easy to implement with the new infrastructure).
\nHowever as per the original ticket, backgrounds are now\nstretchable. The 'backgroundLeftCap' and 'backgroundTopCap' are\nTiDimensions, where 'auto' and '0' mean the same thing (the image\nstretches in the middle only). Otherwise, PLEASE be careful when\nusing capping: Keep in mind that the left end cap == right end cap\nand similarly for top/bottom. This means that if the source image\nyou're capping isn't symmetrical in terms of pixels, there may be\nissues such as where a stretched out pixel leads suddenly into a\nsmooth bump at the very end of the image on the right cap. One\nexample of this is the 'chat' image contained in KitchenSink. You\ncan view this behavior by uncommenting the relevant lines in\ntextfield_therest.js and playing around with the values a\nlittle.
(from [acbf58ff82857ec52dea89fb771d70d078f166fe])\nCloses #578: Stretchable images (backgrounds) are now\ncappable. \nhttp://github.com/appcelerator/titanium_mobile/commit/acbf58ff82857...
Excellent, thanks guys!
Stephen, should this also work with labels? Have a demo working\nwith a textfield, but not a label.
Unfortunately, it appears not. Backgrounds on labels and most\nother UI elements are set via a method which does not preserve\ncapping. Currently only text fields and buttons allow capping;\nlabels appear not to. One way you may wish to get around the label\nissue is to create an inactive text field if it's important for\nlook & feel.
\nThis is an important documentation issue, and should be noted.\nThere is lots of infrastructure in place to allow capping, but (on\na technical note) CGImages are pure bitmap content, not\ninstructions on how that content is to be interpreted. Keeping all\nthe code in place for now so that if an eventual solution is\ndetermined or an API change is made, we can take advantage of\nit.
Appreciate the explanation and insight. Thanks again for\ntackling this ticket, it's very helpful.
backgroundPadding* renders unexpectedly with 1.3. Has this\nfunctionality changed?
Some things may have changed in the last update to fix how\npadding presents itself, and avoid issues with resetting background\nbounds.
It's now a documented feature visible in the KitchenSink\nControls -> Labels test, so you can see if things have changed\nfor yourself. Please let me know if you have any more questions, or\nsample code you want me to look at.
I modified the LabelTest project I shared previously to mimic\nthe KitchenSink demo. Where, the label is created first, then then\nthe backgroundImage and padding are set. I launched the app 3 times\nin succession and got 3 different results (see image).
\nWhen I modified the label constructor to include the\nbackgroundImage and padding, I repeatedly got result #3.
Reopening and prioritizing this, since it could be a serious\nissue.
(from [1fba03bb40a13c3ae4ac0d4346526d062f2d8a90])\nCloses #578: padding fixed (again). Because padding\nbreaks easily and doesn't respect 'auto', it will be removed when\nstretchable image views are implemented (since labels can just be\nembedded in views then). \nhttp://github.com/appcelerator/titanium_mobile/commit/1fba03bb40a13...