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
  • Bug should be fixed, There is no place for any discussions in this case.

    Every new developer meet the same bugs for years and and waste his time to looking for bugs in his code. Let's wait for next trying using spo2 history, webreq with context, group in settings and dozens others bugged stuffs 

    It's shows no respect for developers.

    Solution is simple 

    - fixing bugs or

    - cleary highlight in doc: THIS FUNCTIONALITY IS BUGGED, IT Will BE FIXED NEVER AND WORKAROUND IS... it will be honest

Comment
  • Bug should be fixed, There is no place for any discussions in this case.

    Every new developer meet the same bugs for years and and waste his time to looking for bugs in his code. Let's wait for next trying using spo2 history, webreq with context, group in settings and dozens others bugged stuffs 

    It's shows no respect for developers.

    Solution is simple 

    - fixing bugs or

    - cleary highlight in doc: THIS FUNCTIONALITY IS BUGGED, IT Will BE FIXED NEVER AND WORKAROUND IS... it will be honest

Children
No Data