Skip to main content
R
richardleggettmk
Inspiring
February 19, 2009
Answered

CharacterFormat fails to take values

  • February 19, 2009
  • 1 reply
  • 490 views
I'm finding that CharacterFormat (soon ITextLayoutFormat) fails to take a value of "regular" for fontStyle. This code illustrates the case (attached)

On the first run the traces are as expected, setting the text to italic:

"existing fontWeight: normal"
"existing fontStyle: regular"
"new fontStyle: italic"
"should be: italic"

But when I click my italic button again it fails to reset the text to regular because the "italic" CharacterFormat will not take a value of FontStyle.REGULAR when using a conditional assignment (ternary or if-else), the final trace shows the outcome of this conditional assignment, it just never actually gets assigned (it remains null). So the traces for when the text is already italic are:

"existing fontWeight: normal"
"existing fontStyle: italic"
"new fontStyle: null"
"should be: regular"

I'm not using bold here so there's nothing running through the BOLD_ITALIC stuff.
This topic has been closed for replies.
Correct answer richardleggettmk
I guess this is where I should:

a) read the docs in minute detail
b) not rely on naming conventions when string assignment is involved

The problem was fontStyle does not take a string found in FontStyle, it takes a string in FontPosture, so "luckily" FontStyle.ITALIC married up with the string for FontPosture.ITALIC, but of course FontStyle.REGULAR was not suitable in place of the FontPosture.NORMAL string.

It's a shame we don't have real enums because this naming convention really threw me where other properties like fontWeight do use a class that matches name-wise (FontWeight). I imagine this won't be such a problem when the ASDoc hints the class types instead of just String.

1 reply

R
richardleggettmkAuthorCorrect answer
Inspiring
February 19, 2009
I guess this is where I should:

a) read the docs in minute detail
b) not rely on naming conventions when string assignment is involved

The problem was fontStyle does not take a string found in FontStyle, it takes a string in FontPosture, so "luckily" FontStyle.ITALIC married up with the string for FontPosture.ITALIC, but of course FontStyle.REGULAR was not suitable in place of the FontPosture.NORMAL string.

It's a shame we don't have real enums because this naming convention really threw me where other properties like fontWeight do use a class that matches name-wise (FontWeight). I imagine this won't be such a problem when the ASDoc hints the class types instead of just String.
Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices