• Replies 8 replies
  • Subscribers 15 subscribers
  • Views 1292 views
  • Users 0 members are here
Options
Related

Cannot escape quotation marks in strings

travis.vitek
over 10 years ago
Eclipse seems to accept escaping quotation marks, but the MonkeyC compiler does not. I don't really have plans to use quotes in my strings, but it seems that it should work.

Here is a simple test case.

function main()
{
var s = "\"";
}


And here is the compile error.

line 4:15 token recognition error at: '";\n}\n'


Travis
  • Former Member
    Former Member over 9 years ago
    A quick glance indicates there's an error with the language grammar. We'll look into this. Thanks for the report.
  • over 9 years ago
    Number symbol aka hash sign "#" and forward slash "\" are also impacted it appears.
  • over 9 years ago
    And procent (%) is also mapped somehow...
  • over 9 years ago
    No, no, and no. None of the issues either of you have mentioned are the same as the original. The original test case didn't compile. Each of the issues you guys have mentioned compile just fine. As a matter of fact, I have no problem at all using or displaying any of the characters you mention. There is a small caveat for displaying a backslash[/i]. As with most other programming languages, you have to escape special characters, and the escape character is often the backslash character. To get a backslash, you have to escape it as well.

    using Toybox.Application as App;
    using Toybox.WatchUi as Ui;
    using Toybox.Graphics as Gfx;
    using Toybox.System as Sys;

    class TestView extends Ui.View
    {
    function initialize() {
    }

    function onShow() {
    }

    function onUpdate(dc) {
    dc.setColor(Gfx.COLOR_WHITE, Gfx.COLOR_BLACK);
    dc.clear();

    var b = "#";
    var c = "\\"; // escape the backslash with a backslash
    var d = "%";

    dc.drawText(2, 17, Gfx.FONT_SMALL, b, Gfx.TEXT_JUSTIFY_LEFT);
    dc.drawText(2, 34, Gfx.FONT_SMALL, c, Gfx.TEXT_JUSTIFY_LEFT);
    dc.drawText(2, 51, Gfx.FONT_SMALL, d, Gfx.TEXT_JUSTIFY_LEFT);
    }

    function onHide() {
    }
    }

    class TestApp extends App.AppBase
    {
    function initialize() {
    }

    function onStart() {
    }

    function getInitialView() {
    return [ new TestView() ];
    }

    function onStop() {
    }
    }


    If you are having problems displaying any of those characters, it is likely because of the font you are using.
  • over 9 years ago
    Ohh.. we are talking about different things.

    I have a problem with System.println(...) which currently seems to be the only way to debug anything on the simulator.

    From the manual (p.17): "The println function should be familiar to Java programmers - it prints a string and automatically adds a new line." So I would expect no interpretation of the string... Yet

    function testProcent() {
    Sys.println(">>>%<<<");
    Sys.println("111%111");
    Sys.println("aaa%aaa");
    }


    outputs

    >>><<<
    111
    aaa0x1.fffd7eff546p-1028aa
  • over 9 years ago
    Yes, Sys.print() and Sys.println() both seem to interpret the % symbol as the start of a format specifier. If you want to print a literal % symbol, you have to escape it with a %.

    Sys.println(">>>%%<<<");
    Sys.println("111%%111");
    Sys.println("aaa%%aaa");


    Yes, I consider this a bug. print() and println() are documented to behave like the java functions, and they do not. I'd be very happy if they'd add support for printf and format to behave like the java functions, but I'm guessing we're stuck with Lang.format() in combination with the format() methods on the primitive types.

    That said, this is an entirely different bug than the original one that started this thread. I don't know how the folks at Garmin want to handle these, but it would seem best that if we are going to make bug reports in these forums that each bug be filed as a separate thread (ideally with a test case). That way when they link to the thread from their bug tracking software there is no confusion which bug their issue refers to.
  • over 9 years ago
    That said, this is an entirely different bug than the original one that started this thread. I don't know how the folks at Garmin want to handle these, but it would seem best that if we are going to make bug reports in these forums that each bug be filed as a separate thread (ideally with a test case). That way when they link to the thread from their bug tracking software there is no confusion which bug their issue refers to.


    I agree completely! I only added by report here as I originally though this was the same/a related issue.

    It would be even better if the Garmin Connect IQ had a public accessible issue system, so we could follow up on the issue and also see how the team look at the issues. But... given Garmins track story on openness, I guess this is too much to hope for :-)

    Maybe we can agree on adding a common tag to all issues/bugs so they are relatively easy to find?
  • over 9 years ago
    I want to get to the day where CIQ has the manpower to handle the management of an external ticket system, but the truth is we aren't there yet. The team is monitoring the forums and filing them, and we're addressing them in priority order, but that also has to balance with product needs and new API needs.

    For now I like Tonny's suggestion of adding a "CIQBUG" tag to any thread containing an open bug. I think then we can edit the tag when we think it's been addressed. Does that sound like a good first step?

    Also