[TIMOB-23324] iOS parity issue : TextArea with AttributedString and font style
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Medium |
Status | Closed |
Resolution | Not Our Bug |
Resolution Date | 2016-05-12T22:26:08.000+0000 |
Affected Version/s | Release 5.2.2 |
Fix Version/s | n/a |
Components | iOS |
Labels | parity |
Reporter | Jong Eun Lee |
Assignee | Angel Petkov |
Created | 2016-05-05T12:38:11.000+0000 |
Updated | 2017-05-31T22:25:39.000+0000 |
Description
When TextArea or TextField has a "font" property, it should work as default font.
But TextArea or TextField has a "font" and "attributedString" property, TextArea on iOS works differently.
Expected result is a android screen shoot
!https://media.giphy.com/media/l396JakyRYcHWoq8E/giphy.gif!
<Alloy>
<Window>
<Label>\n TextArea</Label>
<TextArea class="customFont" value="TextArea">
</TextArea>
<TextArea class="customFont">
<AttributedString class="as">
TextArea with attributedString in tss
</AttributedString>
</TextArea>
<TextArea id="ta" class="customFont">
</TextArea>
<Label>\n TextField</Label>
<TextField class="customFont" value="TextField">
</TextField>
<TextField class="customFont">
<AttributedString class="as">
TextField with attributedString in tss
</AttributedString>
</TextField>
<TextField id="tf" class="customFont">
</TextField>
</Window>
</Alloy>
$.index.open();
$.ta.value = 'TextArea with attributedString in JS';
$.tf.value = 'TextField with attributedString in JS';
var attr = Titanium.UI.createAttributedString({
text: $.ta.value,
attributes: [
{
type: Ti.UI.ATTRIBUTE_UNDERLINES_STYLE,
value: Ti.UI.ATTRIBUTE_UNDERLINE_STYLE_SINGLE,
range: [0, 2]
}
]
});
$.ta.attributedString = attr;
$.tf.attributedString = attr;
"Window":{
backgroundColor: "white",
layout: "vertical"
}
"TextArea":{
borderColor: "gray",
borderWidth: 1,
width: Ti.UI.FILL,
}
"TextField":{
borderColor: "gray",
borderWidth: 1,
width: Ti.UI.FILL,
}
".customFont" : {
font: {
fontSize: 20,
},
color : "#ff0000"
}
".as": {
attributes: [
{
type: Ti.UI.ATTRIBUTE_UNDERLINES_STYLE,
value: Ti.UI.ATTRIBUTE_UNDERLINE_STYLE_SINGLE,
range: [0, 2]
}
]
}
Hello [~yomybaby], when you add a font property it manipulates the value in the specified way, however when you add an attributedString after the creation it overwrite the value property. To put in other words the attributedString takes precedence, if you look at the apple [docs](https://developer.apple.com/library/ios/documentation/UIKit/Reference/UITextView_Class/#//apple_ref/occ/instp/UITextView/attributedText) it states that the attributedString replaces the value property. To give a quick example run the code provided, if you specify the attributedString upon creation the font will be applied to the value which is the attributed string. However if you do it after creation the font has already been applied to the value,which then gets replaced by the attributed string.
Thanks for detail reply with example code. :) Code Strong~
You're very welcome, glad it helped :). Code Strong!
@apetkov I have a question. TextField and TextArea are using
UITextView
, aren't? I was wondering why TextField work as my expectation, but why TextArea isn't.It works for TextField ? If so thats a very good point, I will investigate. Very good catch, thank you!
Hi, when setting the attributedString property its actually the same method inherited by a parent class for both textArea and textField. However the main difference is textArea is calling the native method "setAttributedText" on "UITextView", however textField is calling the native method on 'UITextField" . This seems to be a known bug after doing some searching through stack [seText](http://stackoverflow.com/questions/19049917/uitextview-font-is-being-reset-after-settext) [setAttributed](http://stackoverflow.com/questions/27499798/calling-setattributedtext-on-uitextview-resets-the-font-size-and-i-cant-figure). I tried to implement the proposed "work-around" using the selectable property however it didn't seem to work, either way it's a workaround so it wouldn't be best practice to add it.
Closing issue as this is not our bug.