Reported fenix3 bug with minutes showing 5 instead of 05 when less than 10

Hi,

I just got feedback on my Philips Test Pattern watchface for the fenix3 / d2bravo.

Apparently the minutes shows single digit instead of being padded with a leading 0 when the minutes < 10.

Unfortunately I cannot reproduce this with the simulator, and I don't have an actual fenix3 to test this on.

The simulator shows it correctly like 05 instead of the reported 5 being shown.
I use the following line of code to format the minutes correctly:

View.findDrawableById("mins").setText(clockTime.min.format("%.2d"));

I compiled it with SDK 1.1.2.

Is it possible that this is a bug on an older firmware on the watch?

Was reported by Hoy Pak kwai. Could this be an issue with APAC watches? I am just taking a wild guess based on the name of the user who reported this.

Please advise.

Regards,

H
  • Your problem:
    View.findDrawableById("mins").setText(clockTime.min.format("%.2d")

    should be:

    View.findDrawableById("mins").setText(clockTime.min.format("%2d")

    NO period before the "2d" in the format.

    It's been seen before. The simulator makes it ok, but not so much on real devices....
  • Your problem:
    View.findDrawableById("mins").setText(clockTime.min.format("%.2d")

    should be:

    View.findDrawableById("mins").setText(clockTime.min.format("%2d")

    NO period before the "2d" in the format.

    It's been seen before. The simulator makes it ok, but not so much on real devices....


    I have tested this, now I get the reverse behaviour:

    Without the period, the simulator displays just a single digit instead of padded with 0.
    Unfortunately I do not have a fenix3 to test it on.

    So is this just blind trust? Will it work on the actual device even if the simulator shows just one digit?
    Can anybody else also confirm please?
  • Yes, if you don't have a device to test on, you must trust us. That said the format you want is %02d, not %2d. If you look at the documentation, it says it follows the rules for the C sprintf function. The format specifier %02d means you want the output to be zero-padded and at least two digits wide.

    There are a few posts about this in this forum already. Try searching for sprintf if you'd like to read them.
  • Yes, if you don't have a device to test on, you must trust us. That said the format you want is %02d, not %2d. If you look at the documentation, it says it follows the rules for the C sprintf function. The format specifier %02d means you want the output to be zero-padded and at least two digits wide.

    There are a few posts about this in this forum already. Try searching for sprintf if you'd like to read them.


    Hi TRAVIS.VITEK and jim_m_58,

    Thank you so much! Such an embarassing oversight on my side!
    Got the 0 and period all mixed up and misunderstood that the period should be replaced with 0, and not just removed without replacing!

    Thanks guys!
  • Like Travis said "%02d" is "at least two digits, zero filled"
    "%2d" is "at least two digits, space filled"

    and when you use a decimal point, it's actually for the number of digits after the decimal point. So "%.3f" would be to display 3 digits after the decimal point.

    Other things are "%+d", where you are always showing a + or - in front of the number, "%x" to display a number in hex. ("%o" for octal?)

    Seems that "%c" doesn't work for displaying an int as a character, and I've not tried things like "%10s" to format a string (string is space padded to be a min of 10 characters long)
  • Hmm... for some reason, I thought we had fixed this in the simulator. I'll double-check it and see if we can't get it squeezed into our next sprint.
  • Hmm... for some reason, I thought we had fixed this in the simulator. I'll double-check it and see if we can't get it squeezed into our next sprint.


    Thanks!!
  • This has been reported (we've known about it for a while), but it hasn't been addressed in the sim. I was thinking it was thrown in with all of the other 1.1.2 simulator fixes, but I guess not. I think we've got a larger issue to ensure that our string formatting fits the larger standard of printf, but I've added a note to see if we can at least match the simulator to the devices now. That way, even if it's not working the way you'd expect, you can at least count on consistency on devices when you only have the sim available for development.
  • This has been reported (we've known about it for a while), but it hasn't been addressed in the sim. I was thinking it was thrown in with all of the other 1.1.2 simulator fixes, but I guess not. I think we've got a larger issue to ensure that our string formatting fits the larger standard of printf, but I've added a note to see if we can at least match the simulator to the devices now. That way, even if it's not working the way you'd expect, you can at least count on consistency on devices when you only have the sim available for development.


    Thanks again!
    Although a stupid mistake on my part, it will help a great deal forward for simulator to point out real issues.