Under Review
over 1 year ago

BUG : String resource with a double quote character renders as escaped

If a string resource includes a double quote character (ASCII code 34), then the string is rendered incorrectly with a backslash escape character. For example, consider this string resource for a lat/lon position format that will be used as an option in a setting.

<strings>
    <string id="IncorrectString">hddd°mm'ss"</string>
</strings>

When that resource is retrieved and displayed, the result is displayed with an extraneous backslash character as such:

hddd°mm'ss.s\"

This happens regardless of how I try to escape or replace the quote character. CIQ is able to handle other replacements (eg. &apos; or &#176;) so it seems to only be an issue with the double quote character. For reference, I've tried:

  • hddd°mm'ss.s"
  • hddd°mm'ss.s\"
  • hddd°;mm'ss.s&quot;
  • hddd°mm'ss.s&#34;
  • hddd°;mm'ss.s&#x22;
  • hddd°;mm&apos;ss.s&quot;

All of those tries above return the same string with the backlash character: hddd°mm'ss.s\"

This happens in both the simulator and on various actual/physical devices.

I don't know if this is a holdover/bug related to this *old* issue -- https://forums.garmin.com/developer/connect-iq/f/discussion/126/cannot-escape-quotation-marks-in-strings/596 -- but I don't see how to accomplish this. And I looked at the Strings example code in case there was a weird way/workaround but none of the strings in that sample code include a quote character.

This occurs with SDK 4.1.6 but I don't know how long it's been like this.

Parents
  • I can write my own function on condition doc says truth and I decide to support older device.

    Yeah, my point was a dev reported a bug that the SDK's toLongWithBase() method doesn't work and somebody else assumed that the bug reported just imagined the existence of toLongWithBase(). In other words, the first thing they assume is user/dev error.

Comment
  • I can write my own function on condition doc says truth and I decide to support older device.

    Yeah, my point was a dev reported a bug that the SDK's toLongWithBase() method doesn't work and somebody else assumed that the bug reported just imagined the existence of toLongWithBase(). In other words, the first thing they assume is user/dev error.

Children
  • Yes and I don't know why as developers reports a lot of bugs.

    We've had a patch to the docs for quite a while, 
    but it won't make it to production for a little while.

    1. a little while for 5s fix

    2. and as usually when you don't make short action quickly it changes into ,,, 2 years