Cannot escape quotation marks in strings

A quick glance indicates there's an error with the language grammar. We'll look into this. Thanks for the report.

Number symbol aka hash sign "#" and forward slash "\" are also impacted it appears.

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.

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

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.

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?

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